There are wide verity of estimation techniques available. Some of the prominent examples are
- Counting
- Expert judgment (individual and/or group)
- Decomposition
- Analogy
- Proxy estimation
- Planning poker
- Triangulation
- Wall estimation
And the typical units of measurements are
- Hours
- Days
- Weeks
- Months
- Ideal Days
- T-shirt sizing
- Story Points
Typically, Scrum recommends use of Story Points measurement techniques.
Scrum Estimation Sizing – Story Points
Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work – Mike Cohn
Story points tell us how big a story is, relative to others, either in terms of size or complexity. Story points are relative values, not fixed. There is no direct correlation between hours and points. For example, try to use animals instead of, like “dog points” for a relative sizing:, then Chihuahua would suggest a 2 points estimate, Beagle would be 5 points, Labrador would be 8 points and Great Dane 13 points.
We use Fibonacci sequence (1, 2, 3, 5, 8, 13…) as its easy to visualize estimates as a base ten value. Also, it is advisable that each team establish a fixed comparison points for estimation. Teams choose a Story from the backlog that is small and another one that is huge to establish this comparative estimation.
Scrum Estimation Negotiation Practices:
Planning Poker:
- The Scrum Master presents the top item in the product backlog to the team.
- The team discusses the details related to the story
- The product owner clarifies questions, assumptions, and unknowns—as well as acceptance criteria.
- Each team member privately decides how big this story is relative to a reference story, a series of reference stories, or all of the stories on the product backlog
- At the count of three, everyone shows his or her chosen card simultaneously.
If everyone played the same card, the team can log the estimate and move on to the next story, else have the low bidder and the high bidder both explain their reason estimates then repeat steps 4 and 5.
This is mostly done in a couple of iterations, for example…
| Estimator | Round 1 | Round 2 |
| Team member 1 | 3 | 5 |
| Team member 2 | 8 | 5 |
| Team member 3 | 5 | 8 |
| Team member 4 | 2 | 5 |
Wall Estimation:
Designed to allow teams to eliminate discussions of 2 versus 3 and 5 versus 8 and instead group things in a purely relative manner along a continuum, at least initially. It also allows stakeholders to give a general prioritization to a large group of stories without getting hung up on whether one story is slightly more important than another. Good for a grooming session, so you can quickly estimate the raw backlog
- Print User Stories into cards
- Join the team and the stakeholders in a room with a big empty wall
- Explain the rules:
- Height determines priorities (top items are more critical)
- Width determines size (left items are smaller)
As with planning poker, we are using relative sizing, but instead of 2 reference stories for comparison, the wall becomes the constant:
Small story? Move to the left. Big story? Move to the right. Important story? Place it high. A story that we can live without for now? Place it low.
Ref: https://msdn.microsoft.com/en-us/library/hh765979(v=vs.120).aspx
