Another day, another interesting discussion at work.
This time, I guess you got that, we talked about the data teams’ Sprint Burndowns should be based on. Should teams have their Sprint Burndown based on Story Points or on the sum of all remaining estimated tasks in hours?
To answer this question, it’s important to understand what the goal/role of a Sprint Burndown is. The Sprint Burndown is a tool that:
* shows the team’s progress of a running Sprint
* indicates the team’s performance during the Sprint
* should show whether a team is on a good way to meet its commitment or not
* shows where blocks in the development process may happen
Let’s do a small comparison of 2 approaches…
1. Sprint burndown based on story points
* doesn’t require the team to estimate tasks
* might be considered as less overhead by the team
* may not explicitely show bottlenecks in the development process
* may have the tendency to create burndowns like this
2. Sprint burndown based on time
* requires initial tasks to be created and estimated at Sprint start
* may put negative pressure on the team by introducing another level of estimations (and measuring against these estimates)
* may be considered as too much overhead by the team
* may show bottlenecks/blocks more explicitely than with Story Points
* will have the tendency to create burndowns like this
In summary, the purpose alone of the Burndown should already give a good idea in which direction to go. The team/company’s culture and how deep you are in your implementation of Scrum may be 2 other aspects to take into account when making that decision.
Now Jeff Sutherland recently wrote “The best teams I work with burn down story points. They only burn down when a story is done.” (Source) - Are you there yet?
To me it makes more sense for a burn down to be based on time remaining and not story points. The reason is simple, the story points and time remaining are both estimates, however as the story points are a one-off estimation done before a user story is started it is generally a less accurate measure. The time remaining on the other hand is a daily updated estimate on what is remaining to do for a user story. So assuming the purpose of the burn down is to give an indication on how the team is proceeding with the sprint and whether expectations are being met, the time remaining burn down should be the more accurate one. I find it hard to believe that the overhead would be so great as to not be practical within most projects. If the task isn’t started the the value doesn’t change, if the story is being worked on then the estimate of a task should be simple.
Hi Przemek!
Thanks for your comment. I have to agree with you: Story points are not accurate enough to give any valuable information during a Sprint.
We’ve done it that way until now but I think we will change things – despite Jeff Sutherland’s experience ;-)