I used to think that hours burndown is better that story points for tracking sprint progress. However now I think that hours are not so good at all.
First problem with hours is that it is easy to start tracking only implementation time ignoring acceptance testing or functional testing done by testers. We could of course track remaining time for implementation and testing separately for each story but then we had to spend even more time keeping our estimates up to date. In addition it doesn't really matter if we think we are 60%, 80% or 90% done - story either is done or is not done according to the definition agreed by the team.
Of course it is harder to get the story points burndown to be as nice looking as hours. But story points burndown shows clearly when we have either too big stories or we are pushing acceptance testing too much to the end of the sprint.
Comments (2)
Aug 28, 2009
Anonymous says:
The problem with story point burndown that you do not see what is the current wo...The problem with story point burndown that you do not see what is the current work amount estimate left to do. For instance, if story was under estimated, the burndown will not show the increase of complexity and volume. In some sense it will loose its main value.
It is a good practice to have "testing" tasks inside initial story estimate making it the part of definition of done.
Aug 28, 2009
Ürgo Ringo says:
Good point. However I haven't seen it happen very often that hours burndown go...Good point.
However I haven't seen it happen very often that hours burndown goes up because some task was initially underestimated. It seems to me that in that case remaining estimate tends to remain the same or it will be decreased only by little. Also I think in most cases there isn't much difference if sprint burndown goes up or stays flat. Both show that we have a problem.