Before starting a planning poker session, distribute a full sequence of cards to every person who is participating in the estimation exercise, and you’re ready to get going. In planning Poker team members will have a set of cards with different integer numbers. Fibonacci sequence of numbering i.e. 0, 1, 2, 3, 5, 8, 13, 21, 40 and 100 is recommended. Each member will select a card and assign is preferred point to a story. If point doesn’t match between members for any story then highest point giver and lowest point giver will explain why they chose that point for that story. If after 5–6 rounds of play the estimation doesn’t meet then put it aside for revisit later.
Now that all of the items in your backlog have estimations, it’s much easier to accurately plan a sprint. Since your entire team has a consensus on how long each task will take, it’s much more likely that you’ll be able to fit the right amount of work into your sprints. Planning Poker helps team members estimate tasks relative to each other. Sometimes, it’s hard, if not impossible, to estimate how long a task will take, especially if you’ve never done it before.
What Is Program Increment Planning (PI Planning)?
When the team has thoroughly addressed the matter, each estimator discreetly chooses one card to represent their estimate. 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. 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. Additionally, studies have shown that independent estimates during agile estimating and planning leads to better results.
- It’s fun, exciting, possibly rewarding, and there are so many different types to choose from.
- Mountain Goat Software includes a free online Planning Poker tool as part of every Agile Mentors Membership.
- One of the critical activities for agile teams during a sprint planning session is estimating the amount of effort it will take to complete each user story in the sprint.
- What follows is a discussion of everyone’s estimates so teams can get on the same page about the effort required to complete pieces of work.
- Teams do this by playing cards with different values from a customized deck.Everyone chooses their card anonymously, before they are all revealed simultaneously.
- In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud.
They give you an estimate, but two months later, you’re regretting your decision because the project is far past the original timeline and well over budget. Second, despite the egalitarian spirit of Poker tool, it’s still possible for an aggressive, dominating person to take control of the process. First, the consensus may still lack crucial information, resulting in people putting too much confidence in a flawed plan from the start. While this is certainly the most valuable benefit, there are other collateral benefits as well. Hidden numbers prevent anchoring — a cognitive bias where the first number sets a pattern for subsequent estimates. It’s like having six friends discussing where they want to eat, and one announces a clear choice.
Encourage lively discussion
It is an effective way to quickly reach a consensus on the effort required to complete a project. The process begins with the team identifying the task or feature to be estimated. Each team member is then asked to provide a private estimate of the work required to complete the task. All estimates are then discussed, and each team member is given the opportunity to explain the reasoning behind their estimate. Finally, a consensus is reached, and the team moves on to the next task.
It enables you to discover the thumb rules, success metrics, and pitfalls of real-world Agile implementation. By hiding the Poker tool values and showing them simultaneously, the team is more likely to get honest estimates. Team members can say what’s on their minds and offer unbiased opinions, rather than just saying what the customer wants to hear.
How to Run an Online Planning Poker Meeting
If a participant continues to agree with their last choice, then they will repeat the card or eventually choose a new one. Mountain Goat Software includes a free online Planning Poker tool as part of every Agile Mentors Membership. For complete integration, our platform also allows you to export and easily save your voting results back into JIRA in just one click.
The important thing is that you have an idea of what you can realistically do in the time available. Maybe the team member who scored the task a 13 thinks we’re building the work from scratch and therefore it carries a lot of risk and uncertainty. Maybe the team member who chose 2 knows that they had already built this function two planning poker years ago and it was just a matter of dusting it off and redeploying it. These are both things that may not have come up during the discussion. This sequence would indicate that there is a shared understanding — the piece of work isn’t too complex, the task is well-defined, and everyone knows what they’re expected to deliver.
If the team doesn’t come to a consensus, have a discussion to better understand the work, then estimate again until the team reaches an agreement. When you’re done, simply export your estimates and notes back to your favorite project management tool. Planning poker is applicable to any process that requires an estimation of effort involved in upcoming work, not just software development. You can use it to estimate the work required to redecorate your home, landscape your yard, organize an office move — the list of potential applications for planning poker is endless. To play planning poker, you start with a deck of cards, but not your standard playing cards. Online, virtual and co-located agile teams use this application during their planning/pointing sessions to effectively communicate points for stories.
Simon was approached by an agile coach at a well known ecommerce retailer whose team was not delivering on a predictable timetable. The team was actually practicing kanban, but rather than producing stories all the same size, they often accepted stories that blew up unexpectedly into huge epics or just took longer than usual. The problem was that the team were just too nice and too keen to get started as soon as possible. Enforcing standards, even to make life simpler for themselves, was unappealing for them.