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?
Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!