Wednesday, March 30, 2011

4 reasons Agile Story Points > Hours

  1. Velocity
    1. Normal velocity = d/t. Wouldn't make much sense to measure distance in hours. You'd get t/t.
    2. You need a measurement of work (which corresponds to the measurement of distance) to divide by time and get a measurement of Work per Time.
  2. Time estimates are relative (to the engineer)
    1. Measurement of work is empirical. Doesn't matter who's doing it. 
    2. It's a measure of the work to be done, not the time it takes to complete.
  3. When estimates go bad
    1. If you've been estimating Stories in hours, the response to underestimating is too often:
      1. Work more hours (which increases the numerator in the t/t ratio, right?), or
      2. Work faster (which decreases the denominator in the t/t ratio, right?)
    2. If you're properly estimating by Story points, the response is:
      1. Adjusting your estimates or
      2. Adjust your velocity.
    3. The net result of all this is the subtle creation of the assumption that the engineers are in fact motivated and talented to work to their capacity without strict oversight. The option to mandate more work in order to correct team product output is quietly removed.
  4. Story points are the only work type that is measured in story points. Story points are also, not coincidentally, the only unit which is counted as progress toward project completion. Since, as an agile team, we agree to deliver a functional product, rather than to work a set number of hours, the amount of time we work is of no relevance. It doesn't count to project completion. But story points measure the amount of functionality added to the project.
    1. My measuring stories in points, and other issues in hours, you ensure that those other issues (like bugs, or improvements) do *not* count toward project completion. 
    2. This is critical in calculating your velocity. If you spend half your iteration fixing bugs introduced from the previous iteration, you will have only the remaining time to work on stories. This will reflect in your velocity, and you will therefore be correctly informed that your poor quality is affecting your forward progress.
    3. By contrast, a team which writes quality code the first time (and therefore does not use up their time with bugs) will have more time to add forward progress (story points) to the project.
Posted by at

2 comments:

  1. UnknownMarch 31, 2011 at 12:45 PM

    From Curtiss Murphy:

    We tried using the time-independent points for tasks. We did it for a few months, but what happened over time is that the time-independeing estimates for tasks slowly became time DEpendent. After all, if this story is 4 points, but this story was 2 points, what does a 1 point mean? Or a 3? Is it linear or exponential? No matter what we tried, the engineer in each of us slowly started to interpolate in our head.
    If that last task was a 2, then this is a 1. Being smart engineers, everyone figured out, over time, that if a 1 took about 2 hours, then a 2 is probably about 4.... etc... And, in the end, the estimates just became arbitrary re-representations of actual time. So, we said the heck with it and started using hours on our tasks. We estimate our tasks and then put time on when we complete them. Our tasks can be bugs or new features or sometimes (not usually) special meetings. Even traveling to a conference or going to a seminar can be a task (those estimates are really easy .

    ReplyDelete
  2. UnknownMarch 31, 2011 at 12:46 PM

    Yeah, it's hard for us to estimate in other than hours, since no reasonable matrix of code-work-quantification has ever been in wide practice.
    In physics, work = force * distance.
    That helps break down work into two more easily quantifiable values.
    The same principle can be applied to code-work.

    ReplyDelete

Subscribe to: Post Comments (Atom)