I was at a company that switched us over from Hours to Story Points for our estimations. I remember it being difficult to understand it, and we all chaffed against the idea. However, once we figured out how to do it and started doing it, I think our estimations became much more accurate. We were much better able to complete our sprints on time and to better be able to estimate duration of remaining work. Once a couple weeks had passed, we had a good idea of our individual teams’ velocities and could then translate the story points into days and weeks of work. We then used that to know what we could complete within a given time-span.

I guess the same could work if estimating in hours, as long as it is understood that each team will have a different number of hours per week in their velocity. One team may do 200 hours, while another may do 150 hours on average. This doesn't mean one team is working any harder than the other, it just means that they estimate hours differently, or that some team members may not have as much time available to work on the project, for instance, they may always be pulled into bug fixes, or help on other projects, which reduces their available time for this project.

Anyway, what do you think? And why? Which is best? Hours, or Story Points?

closed as primarily opinion-based by Eric King, sleske, Justin Cave, user40980, gnat Oct 2 '13 at 3:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    a) sounds like you already have the answer and now polling opinions which typically on this site gets closed; b) there's a reason why so much literature talks about story points and why story points is a very well-known concept even outside of pure agile shops. I'd guess it's probably because they tend to work better than pure numbers. They are definitely my choice for all the reasons sited in just about any book or blog on agile development – DXM Oct 1 '13 at 14:50
  • 1
    Of course you should use hours which are a totally different thing than hours and spent hours (or hours?) confusing people with that. – Patrick Oct 1 '13 at 14:54
  • 2
    Using "hours" to mean something subtly different from actual hours is a horrible idea that will cause no ends of confusion. No advantage can possibly be worth that, not even luring another team into agile practices. – Kilian Foth Oct 1 '13 at 14:57

Story points and hour estimates don't serve the same purpose. Story points apply to user stories, they are used for broad brush forecasts of what amount of business value a team is able to produce on the long run (via velocity). Hours are generally put on tasks, they are mostly useful inside iterations for day-to-day steering and to determine if the team is going to make it for the end of the sprint.

This is a traditional approach - some teams don't break down user stories into tasks, some use coarser grained units than story points and others don't even estimate in the usual sense of the word so YMMV.

I guess you should first ask yourself why you need estimates and then infer which type of measure you need. Might be points, might be hours, might be both. Or none.

Not the answer you're looking for? Browse other questions tagged or ask your own question.