Use Relative Estimation for Iteration-Based Estimates
If you use an iteration-based agile approach, your team will want to estimate what it can deliver for the next iteration. It can commit to what it can fit into an iteration.
To use relative estimation for iteration-based estimates, the product owner first creates the ranked backlog as described in Plan the Backlog. The team then estimates each story as a team. Some teams use planning poker cards. Those cards have the Fibonacci series of 1, 2, 3, 5, 8, 13, and whatever larger numbers the team needs to estimate its work.
When teams create or use the Fibonacci sequence (or any other relative sizing technique), they can use planning poker.
Every person has a deck of cards with the sizes on the cards. If you use Fibonacci, every person would have eight cards, one each with 1, 2, 3, 5, 8, 13, 20, and 40. When the team estimates, someone, often the product owner, holds up a story and asks, “What’s your estimate for this story?” Each person takes his or her card showing the relative estimate of each story.
Planning poker is a Wideband Delphi estimation technique. It surfaces concerns and issues about a story so the team can resolve those issues or concerns, or know that the story might be troublesome. Planning poker is especially useful when team members disagree on the story’s relative size. Teams decide what to do: go with a larger estimate or a smaller one—or break the story down into smaller chunks of value.
If you have stories of size 1, planning poker is easy. You ask, “Does anyone think this is larger than a 1?” If so, the team has other choices: spike the story to timebox the work to one day to understand what else to do, or break up this story, which is really a feature set, into other stories.
Here’s the problem with relative estimation and deciding what a team can pull into an iteration: the larger the stories are (larger than a 1), the more uncertainty the team has about the work it can commit to for an iteration. Instead of more discussion around estimation, consider a workshop to create smaller stories or an additional backlog refinement meeting. See Create or Refine the Stories as Preparation for Future Work.
Large relative story sizes provide qualitative data: it’s possible the story is complex; the code might be cruft or this story might be an entire feature set. The team might need to explore if it can create a more accurate estimate. See what you can do to help the product owner create stories of size 1 before the team has to estimate the story.