Introducing Super Planning Poker
If you have worked on agile teams, you’ve probably heard of planning poker, a technique for making project estimates. This method aims to gain team consensus on estimates for each user story in an agile project by easily combining the shared knowledge within the whole team.
Super planning poker is a new variation that accounts for uncertainty in ways that planning poker struggles with. Super planning poker is easy to use and provides more information.
In the end, super planning poker can gives you better estimates with less work.
Planning Poker
A typical planning poker session begins with a brief discussion of a story for the sprint, and team members discuss questions with the product owner. This doesn’t last more than a few minutes. Then, using their knowledge and past experiences, each team member simultaneously puts down their planning poker card (real or electronic) to give their estimate of the level of effort of the story, in units called story points. Rarely do all of the numbers match. Some players might make lower estimates, while others might make much higher estimates. The team members discuss their reasons for the estimates, especially the team members with widely varied estimates. Then, they re-vote and discuss until they are able to build consensus and determine one final estimate. Then, the team repeats the process for the next story of the sprint.
The rate at which teams can complete story points is called the velocity. Estimating team velocity will be covered in a follow-up blog.
When this Goes Wrong
Planning poker becomes difficult in two ways:
- Reaching consensus on a single value doesn’t always work.
- Risky stories don’t have any one good answer.
While the discussions leading to the estimates are useful to a team gaining understanding, insisting on coming to a single, consensual value has significant drawbacks.
Risky stories are another source of struggle. The team may truly think that the item is “probably” a 5-point item . . . but there is real concern that it could be a 13-pointer. In this case, the team is conflicted between assuming extra risk or padding their estimate to protect themselves. Neither the 5 nor the 13 adequately reflect what the team thinks is true, and one single answer loses this knowledge in the process. When the team only gets a single number and is struggling to reach consensus, it’s easy to waste time and emotional energy trying to agree on that single number.
Estimating with Uncertainty
When narrowing down estimates with a high degree of uncertainty, the scrum master might use the technique described in Douglas Hubbard’s book, How to Measure Anything: Finding the Value of Intangibles in Business. The conversation might go something like this:
Scrum Master: How long will it take us to complete this feature?
Developer: I don’t know. We haven’t done anything like this before.
Scrum Master: Could we get it done within ten sprints?
Developer: Definitely.
Scrum Master: Can we get this done in the next sprint?
Developer: No way.
Scrum Master: OK. Let’s get realistic. In the worst case where none of your dependencies were met, how long would it take you to finish?
Developer: Maybe eight sprints.
Scrum Master: If you had no obstacles, what’s the soonest we could complete the task?
Developer: Three sprints.
Scrum Master: Given those two numbers, what’s your gut feel?
Developer: Six sprints.
In this conversation, the scrum master and developer agreed there is little or no probability that the epic is more than 8 sprints or less than 3 sprints, and the most likely estimate is 6 sprints This is an example of a three-point estimate: 3 is the low, 6 is the expected, and 8 is the high.
Super Planning Poker
Super planning poker follows a similar process to planning poker, but it allows for three-point estimates. Rather than a settling on a single estimate, the team agrees on an expected estimate, a low estimate, and a high estimate. For example, a vote on User Story A might result in one 3, one 5, five 8’s, and two 13’s. Some of this variance is due to differences in understanding the scope, but some is due to the variability in the work itself. The team could then decide to capture the range as a three-point estimate (3, 8, 13) or go into further discussion and collectively agree on each of the three points.
In the end, the triangular distribution is a good representation of the team’s judgement and knowledge. The team doesn’t know exactly how big the story is, but the probabilities given by this distribution are the best known.
Note the following cases. (These are especially true if the team is using Fibonacci numbers.)
Everyone agrees on a single value. Then, you have single-point estimate. Most people think it is one value, but some think it a higher value. For example, the three-point estimate could be (5, 5, 8).
Most people think it is one value, but some think it a lower value. In this case, the three-point estimate could be (3, 5, 5). The team decides a three different values, e.g. (3, 5, 8). Cases 2, 3, and 4 are shown in Figure 1.
Figure 1 Triangular Estimates for Story Points
A risky story might end up getting an estimate of 5, 5, 13; indicating that the best case is a 5-point story and exposing the risk that it’s going to turn out to be a 13. A low-risk story might be estimated as 3, 8, 8; indicating that, optimistically, it could be only 3 points of effort, but probably 8 points with no more effort expected at all.
How Aptage Can Help
Projects always have some uncertainty; the key is to capture it and use it to provide a more accurate estimate for the overall project. People are good at triangular distributions, but, in general, they are not as adept at combining probabilities (Hubbard). That takes a tool.
With the Aptage Sprint Planner tool (Figure 2), your team can play super planning poker and include triangular distribution in its estimates. The tool can help estimate what the probabilities are, and the estimates will be closer to reality.
Figure 2 Sprint Plan, Triangular Estimates, and Likelihood of Finishing in Sprint
The team can measure the likelihood of completing the work in the sprint, and the risk of work going long. For example, you might predict an 80% probability that you will complete the sprint work on time and 20% that you will not. Knowing the risks, the team can change its behavior and alter the priorities as needed. For example, to reduce uncertainty, a team might prioritize the riskier user stories first.
Without tools, it is difficult to assess the uncertainty of delivery or how that uncertainty evolves over the lifecycle of a project. See how Aptage can help today!
Leave A Comment