The card game that makes estimation simple and collaborative for software teams.
A common roadblock that project managers, product managers, scrum masters, and software developers all face is the estimation process, where they have to predict the level of effort or story points needed to finish a development task.
Often, management pressures product development teams to improve the accuracy of their predictions – but it’s easier said than done. These teams not only have to put effort into determining how to estimate, but they also have to pick the right timing to do it. One technique that can simplify estimation in agile is scrum poker. Let’s discuss this approach in depth.
Where did scrum (planning) poker come from?
In 2002, James Grenning created planning poker commonly referred to as “scrum poker”. He believed that the then-popular estimation approach, Wideband Delphi – a method from the 1950s – took too much time, among other limitations. For Grenning, planning poker was initially about “solving the problem of people in agreement talking too much and dominating the effort.” Later, Mike Cohn, co-founder of Agile Alliance and Scrum Alliance, popularized the technique in his book Agile Estimating and Planning.
What is scrum poker?
Scrum poker, also known as “planning poker” and “pointing poker”, is a gamified technique that development teams use to guess the effort of project management tasks. These estimations are based on the entire group’s input and consensus, making them more engaging and accurate than other methods. To help gauge the number of story points for the relevant tasks, teams use planning poker cards, which are similar to poker cards.
How does planning poker work?
At the beginning of a poker planning session, the product owner or customer reviews an agile user story and reads it aloud. A user story is a general and informal explanation of a software feature that describes how it will offer value to the end-user (i.e. the customer).
Step 1: Hand out the cards to participants
Distribute an identical deck of cards to everybody. Each one has a number that the team has agreed to use as their estimate. Each player should have a deck consisting of different numbers. Cohn recommended a sequence of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
Other common sequences include doubling the next number (e.g. 1, 2, 4, 8, and so on). These values can represent a number of things: the number of story points, ideal days, or other units that the team uses for estimation.
The decks are intentionally kept minimal with considerable number-jumps. Doing this ensures that for each story, everyone can reach a consensus number. Otherwise, if they have a card for each number from one to 50, the process would be painfully slow.
Step 2: Read the story out loud
The moderator (either the product owner or product manager) narrates the story to the group. If participants have any questions, the moderator answers them.
Step 3: Discuss the story
Once the group finishes listening to the story, everyone shares their views on it. Some of these discussion points will likely include:
- How should we handle the work?
- How many people are expected to get involved?
- What skills will be needed to work on the story?
- How should we tackle any roadblocks that delay progress?
The group will also try to learn more about the story and ask questions to understand it better.
Step 4: Select and share
After the discussion, each person will privately select a card from the deck. Usually, it’s used to show an estimate of story points (but can also be used to represent the number of ideal days). Once everyone selects a card, they show them at the same time.
If a player shows a higher card, it conveys that the story will be completed with greater difficulty and take a longer period to complete. Keep in mind that it’s common for estimates to vary a lot.
Step 5: Reach a consensus
When team members show the same card, that number turns into a consensus. Now, the group can move forward and work on the next story.
However, if the cards continue to vary, then further discussions on the story will follow. Participants with higher or lower estimates than others will communicate their points of view. Then, they’ll attempt to convince their teammates to understand their differing numbers.
Once this new deliberation ends, everyone will go through their deck and show them again. If a participant continues to agree with their last choice, then they will repeat the card or eventually choose a new one.
Usually, the estimates start to converge after the second round. If not, then the process repeats itself until the team agrees on a single number.
The benefits of scrum poker
According to one study, estimates from planning poker are statistically higher than individual ones. It was also noted that for the same tasks, planning poker estimates were more accurate than individual ones.
Other benefits include:
- Estimating tasks relative to each other. Often, it can be tricky to gauge the time required to complete a project, especially when it’s your first time. Planning poker familiarizes teams with assessing them. After playing the game for a while, you end up building a series of tasks that act as a future reference for comparison.
- Lending an equal voice to everyone on the team. It can encourage newer employees to speak up by playing a card and explaining their logic. For example, imagine making a food reservation app. You and your colleague might give a smaller estimate, like 10 or 15. However, a new employee might give one of 100. Maybe they had experience with creating a similar app at their last job and knows that such an app takes a lot of time, especially compared to other ones.
- Identifying gaps in requirement and implementation. When participants disclose their estimates, they will have to back them up with reasoning on why they are high or low. This can open up questions on the requirement and implementation – a feedback loop that can detect the gaps.
Who to include in scrum poker meetings
The right people should join the meeting or it becomes difficult to reap the benefits outlined above. These crucial roles include:
- Scrum team members: scrum members deliver the items from the product backlog – a list of deliverables (e.g. new features). They will also provide their input for the discussions of story points.
- Scrum master: a scrum leader is the facilitator in agile meetings. They should take part in all standard meetings.
- Product owner: the owner or manager will describe all user stories to the team and answer their questions.
When to hold a planning poker session
Usually, teams arrange a session after creating the initial backlog. Although sessions can sometimes take more than one day, it leads to the development of initial estimates that are helpful in sizing or scoping the project.
Items are added to the product backlog incrementally throughout the project’s lifespan. That’s why it’s usually more convenient for teams to conduct sessions once per iteration. In most cases, this happens some days after the iteration ends. Similarly, it also occurs right after a daily standup (a type of agile meeting) because the entire team is present.
Improve your estimation with apps
You can improve your estimates by using scrum poker apps. Over time, these applications will refine estimates and make your planning more accurate. For starters, take a look at the following applications from the Atlassian Marketplace: