Sprint Planning: Hours or Story Points (?) – that is the question!
There is a lot of debate about whether to estimate sprint requirements in hours or to leave them in Story Points.
Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours. Mike discusses this in his post: Why I don’t use story points for sprint planning.
Jeff Sutherland claims that “the best teams [he works] with burn down story points. They only burn down when a story is done.”
Personally, I see pros and cons of both approaches but would use Story Points over hours where/whenever possible.
Mike Cohn claims that he doesn’t use story points for sprint planning because “story points are a useful long-term measure. They are not useful in the short-term.”
I don’t agree with this statement as a whole. Story Points are indeed a useful long-term measure, however I believe they can also be useful in the short-term.
When writing user stories, you should aim for each story to comply with the ‘INVEST’ acronym – Independent, Negotiable, Valuable, Estimatable, Small and Testable.
If each story is Small enough to be ‘accurately’ estimated, and Testable enough for one to create Test Confirmations then there may be little benefit achieved through breaking it down into smaller composite parts or re-estimating them in hours.
In fact, back in the days when we were ’Doing Agile’, one of our teams used to create task cards with the words “just do it” written on them… In this particular situation, the team were not benefiting from the time spent re-writing task cards and re-estimating the stories – each story was taking no longer than 1-2 days to complete.
The main concerns I had when we initially discussed the idea of burning down in hours was that we’d not benefit from the early warning signs provided by the burndown and that we would only discover a story was taking longer than expected when it was too late.
The reality of the situation is that the team soon discovered their ‘Agile Heartbeat’ - in order to stay ‘on track’, they need to burn down +/- one story per day. Also, the team members generally know when something is taking longer than expected – their communication is strong and they raise any concerns at the Daily Scrum.
With that said, if the team is less established, AND/OR if the stories are much larger AND/OR if the sprint duration is +/- 1 week or less then I’d be inclined to estimate in hours as they have the potential to provide a more granular progress snapshot.
Mike Cohn suggests:
It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.”
I do agree with this point, in the sense that nothing is definite- you can’t be 100% certain that you’ll finish everything you commit to.
With that said if a team has a velocity of 20 story points, aren’t they likely to commit to delivering +/-20 story points worth of stories in the next sprint? AND if they are true to their velocity, then surely they’ll deliver them – will they not?
On the other hand, it is still important for the team to be comfortable and confident that they can deliver their commitments – if they only accept 15 points one sprint then so be it. This discussion is about whether or not you can achieve the same end result burning down on story points vs. hours – I think you can.
What do you think? Hours or Story Points?
Read more about Agile Estimation
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
I actually was able in my SDLC processes to marry the Waterfall with Scrum and Agile and it is working ...
I experienced that using story points based on complexity has brought the team disagreement in assigning points. We still ...
Hi, in addition to your article, you can view this list as well on my website in a more clear ...
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce's earlier response. Andy has nailed the often missed point ...
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly ...
I personally prefer burning the whole stories estimated in points so I like the Jeff Sutherland’s approach to consider the story done when it’s really done. This of course works better with smaller stories.
Reestimating stories in hours usually comes down to estimating tasks that were identified for each story and as such they become at some point incomparable. So we loose the ability to use relative estimates as tasks fall into different types of activities. This way we need to think about hours required for each task individually and maybe comparing them to other tasks of the same type (like designing UI, writing javascript code, etc.) may help in estimating them.
I wrote about it some time ago in Are you brave enough not to estimate your tasks? which was followed by quite vibrant and interesting discussion at
When burning down the whole stories it may be helpful to use some cumulative charts that show stories in different states during the iteration (PENDING, IN PROGRESS, COMPLETED, etc.). This way even if they actually burn down late in the iteration you will get a view on what’s going on with the flow during the iteration.
Regards,
Marcin
(http://blog.goyello.com) We are currently estimating our project in two phases. Firstly we are breaking it into requests/user stories with stories points (we are estimating it using estimation poker approach). Then, we are checking the previous velocity of the sprint and we are multiplying the story points with the calculated hour from the used hours/velocity.
I would strongly recommend such approach because this way you can notice where your estimations are more guessing than really touching the true value (if the story point is very big it means that you have to break it into smaller ones).
We estimate in hours, not in story points. Its is something everyone in the orgainization understands.
Hi Dennis,
It’s interesting you see it that way. I rather like the abstract nature of Story Points.
When we were estimating in hours, our Stakeholders/Product Owners/Senior Management often over-analysed the situation – the fact we were using a more precise measurement lead them to believe that we were being accurate!
The reality of the situation is we never actually booked a sprint at 100% capacity. In fact, I remember one occasion where a team of four entered into a two week sprint with 60 hours of work. This raised all sorts of questions…
e.g.
“why did Bob only work 20 hours last sprint?”
“but they’ve only committed to a fraction of their capacity?!”
“that team’s not working hard enough”
We no longer have these types of conversations.
Just a thought.
Tara
Yes, but I don’t think that we should confuse tracking progress on a sprint and time tracking. Estimating is a hard job. I think historic results of our hourly estimates help us improve the estimation process for future sprints.
[...] a set of user stories) or a range of stories to be delivered (given a fixed release date). Several people have written extensively on agile estimating and planning and the importance of hours and story [...]
“one of our teams used to create task cards with the words ‘just do it’ written on them” – if you’re referring to what I think you are that was my team
Anyway, I’m firmly of the belief that you estimate in Story Points and then task out and burn down in hours. I ran a session on this at London Scrum User Group and that seemed to be the consensus there as well. For me Story Points are more for the business and during the sprint the development team are the people looking at the burndown and this graph is for them, at the end of the sprint we deliver a number of Story Points to the business but they’re only interested in this after the sprint finishes, not during it.
That’s my 2c anyway!
Tom
Actually, I was referring to Black Team when I wrote that.
I stand corrected – TWO of our teams used to create task cards with the words ‘just do it’ written on them! :p
[...] Ли Вайтакер не согласна, что “пункты” не годятся для краткосрочных оценок. Она пишет: Если каждая история достаточно маленькая [...]
[...] https://agile101.net/2009/08/24/sprint-planning-hours-or-story-points-that-is-the-question/ [...]
Hi,this is Lyndsey Jacquot,just discovered your web-site on google and i must say this blog is great.may I share some of the writing found in this weblog to my local buddies?i’m not sure and what you think?in any case,Thank you!
I experienced tasking out in hours, issues liked Tara mentioned in her post above. developers were reluctant to give in hours, and felt as if they were being micromanaged.
daily scrum meeting upto the point of 3 qs and briefing team on work/ issue was fine.
Logically, I feel story points make more sense, if you break it down to +/- one story per day; you would have a realistic sprint burn down chart and not run the risk of incomparable.
time spent does not equal Work completed. thus this is not inline with scrum.
Tan
I experienced that using story points based on complexity has brought the team disagreement in assigning points. We still use points but based on ideal days. One ideal day is equivalent to 6 development time, 2 hours is used for meetings, daily scrum, sprint planning, collaboration within the team, TEM, etc. This practice is widely accepted within the organizations I’ve coached. The stakeholders found it easier (using ideal days) than using points based on complexity and they can relay to what points are used for.