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?
Add a comment
|
6 Answers
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.
Story points are used to estimate the relative size of stories (i.e. "Story A is about twice as big as Story B"), but this intentionally doesn't tell anything about the absolute size of stories (i.e. "Story A takes about 6 hours to finish, while Story B 3 hours").
Planning poker is a way to optimize time spent on estimation, and to make team members discuss stories, to get to a common understanding of the tasks, open questions and risks included in them.
Not all Scrum teams use story point estimation and planning poker, although both are recommended by most experts I know of. Some level of estimation is always required in any kind of project planning; Scrum's point is to make only the absolute minimum necessary effort to get good enough estimates, and then to refine and adjust these during the project as needed. (As opposed to other, traditional methods which may put a greater emphasis on detail and accuracy of estimation, while the end results in practice hardly justify the effort spent, and give only a false sense of security to management.)
So if you want to make any plans regarding when can you deliver the next release or get to an important milestone, you must estimate your team's velocity, i.e. how fast they can complete stories on average, or how many stories they can complete in a given time frame (sprint). And for that to be meaningful, you also need to know the relative size of stories. This is why it is recommended for Scrum teams to estimate story points.
Then during sprint planning, the team commits to complete a certain number of stories within the upcoming sprint. This is hard especially for inexperienced teams who don't have a feeling for their velocity yet, aren't good at story point estimation and/or have a fluctuating performance. This is where it may help to go through a second round of estimation, where each individual task belonging to a story is estimated in hours/days. This requires the team to have a deeper discussion about the details of the story, giving them more chance to even out estimation errors and to take into account all factors. And in the end, they can double check their estimation by adding up the total time required to complete the stories selected for that sprint. It may easily happen for a novice team that the estimated time is significantly more (or less) than the time they have available in the coming sprint, requiring an adjustment (dropping stories from or adding more to the sprint).
The back side of estimating for hours is of course that it requires more time, slowing the team down, and it may not bring enough value to justify that. Experienced teams therefore may decide to estimate only story points, not time. But at the early phases of adopting Scrum, or when forming a new team, it may be useful to estimate hours as well as story points.
In Scrum, only two things are mandatory: (1) ship something every month that you think you can sell and (2) look at how you did it and try to improve at it.
The "story points or hours?" question has been hotly debated for 15 years. Many people report that merely counting the number of stories (neither story points nor hours) correlated better with long-term capacity than any other estimating technique or scale they'd used.
Still other people recommend throwing away cost estimates of stories, and instead focusing on completing the most valuable stories as soon as possible. When you get good at that, it matters much less whether Story 128 was a 2 or a 3.
Your question makes it sound like you'd prefer not estimating the cost of each story in hours before putting it in the sprint. So don't do it. I bet you it'll be fine.
Simple answer: No. Scrum does not require that you provide an estimate of hours needed to finish every product backlog item, before putting it in the Sprint.
In fact, scrum simply invites you to provide an estimate. How you do that, is up to you.
The most common technique I come across is estimating product backlog items in story points and tasks in hours.
answered Aug 4, 2014 at 7:32
No, Scrum does not require hours at the Story level. In fact this would be considered an antipattern. If you want to use hours they are applicable only at the Task level, where tasks are considered to be the "steps" needed to complete a story based on your team's Definition of Done.
My advice is to skip tasks and hours altogether. Hours are often estimated by individuals and are subject to a wide range of uncertainty. Story Points (or just points) are estimated by the team and subject to refinement and improvement over time as the team gets better at estimating.
Just like @Péter Török already explained, Scrum uses points to estimate user stories.
There are different techniques for estimations (Fibonacci, Planning Poker, Powers of two, etc.) and they relate to how important, big and complex is the story. When combined all those point result in velocity of the Sprint (how much work the team is capable of doing in future sprints).
It's recommended that developers are the ones who estimates each story as they know best how much effort and time they are going to take.
