Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Sunday, April 05, 2009

Sprint Burndown: by hours or by story points?

The best teams I work with burn down story points. They only burn down when a story is done.

To do this, the team needs to have small stories. They will need to work with the product owner to make this happen. In disciplined teams this saves a lot of overhead and makes them go faster.

For new teams, breaking down the Sprint Backlog into tasks and estimating in hours is normally recommended as the teams need to learn to manage resource loading. However, Intronis, one of my venture group portfolio companies, started their first Scrum with burning down story points and has never looked back. They tripled their velocity in a few months and have one of the best implementations of Scrum in our 12 portfolio companies.

This strategy is recommended only for teams that can deliver working software at the end of each Sprint. This means tested at the feature level, i.e. potentially shippable code.



Blogger Peter said...

Thanks for giving this practice some credibility!

I gave up having even new teams estimate task hours in 2006. After that I had them burn down tasks using a simple count of remaining tasks. A year ago I proposed burning down story points only.

In CSM classes I discuss all three ways and have participants consider value vs. waste.

I had a discussion with Roman in Orlando. He feels new teams benefit from estimating tasks until they can deliver. This seem to gel with your post.

On my next new coaching engagement I may suggest trying hours on one team and points on another, for the opportunity to inspect and adapt once more...

Peter Hundermark

7:04 AM  
Blogger jmckenna said...

I agree as well. I see teams going to story point burndown more lately. The maturity level of the team matters. My experience is that often new teams actually do not know all the work that must be done to deliver. Especially the non-coding work. Tasking helps get the knowledge known.

I find that I trust task burndowns more with new teams. They seem to just guess as to how much work is remaining. With tasks there is no guessing. After the team gets a feel for how much work it really takes then the burndown feels less like a guess.

3:26 PM  
Blogger csterwa said...

This has been my experience, as well. If I work with a team who is doing Scrum or have a fairly well defined method of delivery then burning down points is just fine. Since I am a consultant we are usually looking for ways to help teams get more interaction amongst it's members and figure out their load so task hours works well to start with. I am sure they will switch over to burning down points when it makes sense to them.

8:05 PM  

Post a Comment

<< Home