Agile Software Estimation With Scrum Planning Poker

Years ago I struggled with a dilemma: should I sit down to figure out how long it will take to create the software product, or just start writing code? Often it felt like a waste of time to be estimating when I could just be doing it.

The problem was I really needed to create an estimate. The business needed to know. We needed to set customer expectations, plan marketing programs, and prepare for trade shows.

I tried a bunch of different software estimating techniques and the only approaches that seemed to work took way too much time. Only by breaking down each feature into individual tasks, then assigning hour estimates to each did I come up with any solid results.

Then I discovered planning poker, and my life changed. Weeks of estimating turned into hours, and the results were far more accurate than anything I had ever done before.

In this article I answer the most common questions about this software estimation technique.

Question #1: What is Scrum Planning Poker?

Scrum poker is a technique that allows a team to work together to rapidly create an accurate estimate. Unlike what I described above, the team doesn’t break features down into individual tasks with hour estimates. Instead they use their experience to estimate how big each feature is compared to each of the other features in the list.

The first step is for the team to create a list of user stories representing the scope of the project. Once the list is created, the team gets together and assigns estimates.

Estimates are assigned using story points, which represent an abstract measurement of size. This is not an hour estimate. It’s a way to understand the relative level of effort of a specific story as compared to other stories in the list.

For a step-by-step illustration of the entire agile estimation process, including sample stories and story points, see: Why We Love Agile Estimation (And You Should Too!)

To facilitate the story point estimation process, every team member is handed a deck of cards, each with a different story point value. The values on the cards are 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 100. There’s also a question mark card and inifinity card, which I explain later in this article.

Here’s how it works:

1. A user story title is read aloud or, ideally, put up on a projection screen or TV on the wall.
2. The acceptance criteria of the story are discussed, questions asked, and clarifications are made.
3. Each team member, not including the product owner, decides on a story point value and selects a card from their deck of cards.
4. Once each team member has selected a card, everyone turns over their cards.
5. Any differences are discussed, typically with those with the highest and lowest estimates explaining their thinking.
6. The team re-votes based on that discussion until a consensus is reached.

Question #2: Why Use Story Points Instead ofHours or Days?

Estimating in hours and days have a few different problems.

The first issue is that business stakeholders have a difficult time understanding the concept of “ideal hours” or “ideal days.” If you say “The team estimates that it will take 30 ideal days to complete the project,” business stakeholders tend to forget the “ideal” part. They think, “Great! The project will be done in six weeks!”

The next problem is the disparity between how fast certain team members can complete work. A senior engineer who has worked on the project for years will think, “I can do that in about an hour.” The junior engineer might take a day to accomplish the same thing.

The final problem is the high degree of optimism present in most technical team members. It’s easy to think “It’s a day,” when it’s really three days’ worth of work.

Story points eliminates these problems by disconnecting the size of a user story from the time it will take. When time is taken off the table, teams tend to be much more effective at estimating relative size.

Question #3: Who Came Up With the Story Point Values on the Cards?

The story point values on the agile planning poker planning cards were created by Mike Cohn, and the range of values is often referred to as the “Cohn Scale” in his honor.

The scale is similar to the Fibonacci sequence, where each number is generated by taking the sum of the previous two numbers. The benefit is as the numbers grow larger, the gaps between them increase. This accounts for the higher level of uncertainty for larger-sized stories.

Question #4: When Should the Team Do Planning Poker?

There are two different times the team should use this technique.

• Initial Estimate. At the start of a project, the team should estimate the list of user stories, in order to form the initial estimate of the size of the project. This typically takes one to three meetings of approximately one to three hours each.
• Once per Sprint. As new user stories are identified throughout the course of the project, the team needs to estimate them so they can be factored into the schedule. This can typically be done in less than an hour.

Our teams run a “backlog grooming” ceremony in the second week of the sprint if there are any new stories to estimate, or if any stories have changed since they were initially estimated. If there haven’t been any changes, the team doesn’t hold the ceremony.

Question #5: How do You Do Scrum Poker with a Distributed Team?

The process I described above depends on having the team members face-to-face. Many teams today are distributed–how do you use this process in that case?

The most successful way we’ve done this is by combining a conferencing tool such as Zoom with PlanningPoker.com. Here’s how we do it:

1. Start the Zoom and discuss the first story in the list.
2. Copy the story into Planningpoker
3. The team enters their story point vote. The “cards” are revealed only after everyone has voted.
4. The team discusses any discrepancies, re-votes as necessary, and records the final estimate.
5. The team moves to the next story and repeats until all the stories are estimated

Question #6: Where Can we Get Poker Cards?

Mike Cohn’s Mountain Goat Software sells poker cards online. I highly recommend them; they are inexpensive and high-quality. Each deck contains four sets of cards.

You can also use a mobile app on your phone in lieu of cards. The one we prefer is Scrum Poker Cards, available on both Android and Apple iOS.

Question #7: I Bought Poker Cards – What’s With the Zero, Question Mark, and Infinity Cards?

If you purchase poker cards from Mountain Goat Software, or you use the Scrum Poker Cards mobile app, you’ll notice that the decks contain three “special” cards: 0, ? and ∞ (the infinity symbol).

Here’s how they’re used:

The Zero Card

Sometimes the list of stories will include one that’s very straightforward, where the team believes it will only be a few minutes of work, or perhaps an hour or two. The story feels too small to be a 0.5.

For example, there may be some feedback from the sales team that they want to highlight products that have free shipping. The app already shows “$0” for shipping, so the team just needs to add code that shows “FREE!” instead of $0.

They decide it’s a really easy story to implement, and they don’t want to throw off their velocity (how much work they can complete during a sprint). They’ll assign it a 0 instead of a 0.5.

The Question Mark Card

The team should discuss each story before voting, but sometimes a team member really has no idea what to estimate. By using the question mark card they’re saying, “I have absolutely no clue what I should use for an estimate.” In this case the team should discuss the story further and re-vote.

As a general rule, if this card is used often it means the team needs to discuss the stories more so every team member understands enough to be able to vote with a story point value.

The Infinity Card

Sometimes a story is so large that it won’t fit into even the max “100” value. This may be a story so large and undefined or risky that the team member doesn’t feel comfortable placing any sort of story point value on it.

For example, “As a CAD user I want a new rendering engine so my drawings will appear more quickly.” One or more team members understand that to mean,”Re-write the entire core framework of the application that we just spent the last 5 years creating.”

This type of story either needs clarification (“I didn’t mean re-write the whole core of the app!”) or the story needs to be scaled down into smaller pieces.

Conclusion

Scrum poker is a way to address the challenge of needing to come up with estimates without tying up the team for weeks on end. It delivers results very rapidly, but with a high degree of accuracy.

A side benefit of this process is encouraging discussion of each user story. This helps lay the foundation of understanding for the entire team, speeding implementation because everyone is on the same page.

Finally, a group discussion of estimates leads to better accuracy than depending upon the background, perception, and opinion of a single individuals.

Have more questions that I didn’t address? Add a comment and I’ll provide an answer.