Although a lot went well with this “re-adoption” of scrum, the biggest issue has been estimation, and that the entire team feels that story points are not sufficient for actual work planning on sprints. This post on the role of story points and task hours, and the two burndown charts you use, come at the perfect time for us as we’re relooking our estimation techniques before we start our next major release cycle.

1) It is analogous to taking the scoring average of the players on a basketball team, adding those up and saying “This basketball team will score 92.5 points tonight.” No. That may be their average to-date and it may be their average over the next 10 games but it is very unlikely to be their exact score tonight.

2) When I worked at the car wash as a kid, we each had a quota of four cars per hour. No one expected me to get exactly four cars per hour. Maybe not even 32 cars in an 8 hour day. But the quota was a useful measure over longer periods.

So, velocity is a useful long-term measure but not a particularly useful measure in the short term as in planning a single sprint.

Try defining a measure for velocity. For example: lets say 1 velocity point is 1 story point of work per person per day (1 vp = 1 sp / 1 person * 1 day). Once you know the velocity points for your team, calculating the amount of work that can be accomplished in an iteration should just be a matter of plugging in the numbers and doing the math.

Augment that with with another really simple graph that you can update once a day at the same day. This graph should also have days across the horizontal axis but on the vertical axis, graph the number of completed user stories or product backlog items. Unless a team is used to trying to finish one or two stories before moving on to the next few, the line will start out flat for many days. It will then magically surge upward as all user stories are “finished” on the last two days. Well, except testers find a ton of bugs in them, so they aren’t really done. Have the whole team agree at the standup whether a particular story is “done.” If it is, that story is counted in the day’s progress. Here’s an example:

This article is a really big help. At the moment I am the ScrumMaster for a team that has two burndown charts for each sprint. One for story points over the sprint and one for task hours. I agree with you that story points aren’t a useful short term metric during the sprint. I don’t feel that the separate task burndown in hours is adding much value. The developers like the feeling of completing tasks and updating the burndown, but we are getting into the situation where we have burnt nearly all of our task hours without burning any story points! Obviously this is wrong.

I would like to change so that we only have one burndown for stories, but estimated in hours as you propose. I have a few questions though:

* Should we sum the hours estimated for each task and call that the ‘hour estimate’ for the story?
* When do we award hours and update the graph? Shouldn’t this only happen after all tasks are complete and the customer acceptance tests for the story all pass? The story is *done*.
* If we only award hours when stories are *done*, then at any moment in time our burndown chart doesn’t reflect all the latest knowledge that we have. For instance how do we handle adding and claiming the points for a 5 hour ‘internal to the story’ bug fix task?
* Does all of this mean that our stories are too big? We are developing a complex Web interface and find it hard to get to very small stories without going into detail on the UI and even then we end up with stories that are not independent.

Thanks for your illuminating article.
–
James