Estimate hours of work for every user story



  • In Scrum, is it mandatory to estimate the amount of hours needed to finish every user story before putting it in the Sprint? Or should we use planning poker and use points instead of hours?



  • Scrum does not mandate estimation of any kind, actually. It doesn't even mandate user stories to be honest. Jeff Sutherland and Ken Schwaber put together a quick guide with the essentials of Scrum here http://www.scrumguides.org/ - it's worth a read.

    That said, it is very hard for a team to consistently deliver on their sprint commitments AND be taking some risks to innovate and push their productivity incrementally without consistent measurement of all the work to be completed in that time-frame. If you don't estimate smaller stories, or tasks that you're not calling stories but are going to be working on, or a technical investigation (spike) that are being taken into a sprint, how do you know what level of effort you should be able to accept in subsequent sprints? How do you know if a particular kind of story (or task, or investigation, or whatever) is one that your team consistently has a good handle (i.e., accurate estimate) on or not?

    I ask my teams to estimate all the work they take into a sprint, usually with fibonacci story points. It has been very successful in helping to uncover problems with poorly written user stories, unknown technologies, insufficient communication, and many other problems that keep a team from being high functioning. It can be a pain, and you don't want to obsess about the accuracy of estimates or overweight their value, but estimation is a great tool for driving out development inefficiencies throughout the process.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2