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 done but no longer recommended. 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.

This strategy is recommended 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.


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

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.

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.

Michael B. said...

Hi Jeff,
I’ve been reading different views about story points vs hours. Our engineering group is new to scrum and we are on our first 9 month release with agile, and we have decided to go with story points already with our product backlog and burnup charts to see progress for the entire release. However the challenge I am seeing is what happens within our 2 weeks sprints. There has been confusion/debate on whether we should use hours within a sprint or stick with story points. I read Mike Cohn’s post on using points for the product backlog but hours for sprint planning. I saw your reply that you used to recommend this before as well, but now it seems you are recommending to also go with story points within a sprint. (?). In this April 2009 blog, your recommendation was to have new teams use hours within a sprint, but for experienced productive teams to go with points within a sprint. The mentality our team is having is if the goal is to go with story points in a sprint, then just start with it rather than going with hours then moving to sprints later in a future release.

With this post, you’re stating that the only burn down is when a story is done. I’m assuming what you mean by this is that the y-axis will use story points vs. hours, and there will not be a drop until the story is Done. I took CSM with SolutionsIQ with Bryan Stallings as an instructor. In this course, we were taught with burndown charts using hours, so you get a nice downward slope when progress is made. If a burndown uses points, then we would not see a slope, but more like huge drops. With our project team, most of those drops wouldn’t happen until near the end of the sprint. If this is the case, is there is any value to having a burndown chart within a sprint?

Our goal is to deliver working/potentially shippable software every sprint (2 weeks). But we do have stories that are started within a sprint, but would not finish until the next sprint (sometimes by design). So this gives us an odd status within a sprint because the burndown is never complete. But over the course of the release, we are burning up on our story. Any further thoughts or recommendations with using story points or hours within a sprint?

Chief said...

As a team we take the items in the sprint backlog, which have been estimated in story points and then break them down into individual tasks, and these are done in ideal hours.

This way every morning at the stand up it is possible to either burn up or burn down the time required on a task, and thus calculate the velocity.

How would burn up be captured if story points are only allocated to the user story?

Jeff Sutherland said...

We recommend spreading story points across tasks if doing tasking. We find hours give work estimates, take longer to estimate, confuse the product owner, and have other negative side effects. Try an experiment - get rid of hours! If you go slower, you can always go back to hours.

Ruslan Dzhabbarov said...

I'm sorry Jeff, but when I hearing sentences like "They tripled their velocity in a few months." I tend to smile. From my experience velocity increase at the very beginning of the project happens because team's simply forget to re estimate their stories when their estimation scale has been changed. This situation looks like: in sprint 1 team estimated 2 US for 3 and 5 point's, as a result their velocity is 8pt assuming successful sprint. After few sprint's team can realize that they have to change estimation scale, so that they start to assign 8pt for US's which were 5pt, so if in previous sprint they did 3 US for 5pt each, than in the next sprint, with the same amount of work, they will do 24pt. Velocity will increase from 15 to 24, but team won't actually deliver more.