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



  1. 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 LinkedIn Agile Group

    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.


  2. @GOYELLO (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).

  3. 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…


    “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.


  4. 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.

  5. “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!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s