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. We might deem this task a 1; if we were to add two lines, we might see it as a 2 because it requires a little bit more work. When it gets to the point where we’re adding five lines, the planning poker score might jump to an 8 because it would involve redesigning the basket itself to allow for all the extra lines.

Once the customer finishes the reading, the estimators discuss the presentation, asking the customer questions as needed. When the team has thoroughly addressed the matter, each estimator discreetly chooses one card to represent their estimate. 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. 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.

The high and low estimators, especially, should share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time. It is most commonly used in agile software development, in particular in Scrum and Extreme Programming.

Vote on each user story

In 2002, James Grenning created planning poker as an alternative to the popular project estimation processes of the day because he didn’t think they solved these problems particularly well. His idea became popular when it was included by Mike Cohn of Mountain Goat Software in his immensely popular book, Agile Estimating and Planning. As soon as the estimators are done assessing the user story, they reveal their cards at the same time. If the estimators choose the same number, a consensus is reached, and they can move on to the next story point.

• As soon as the estimators are done assessing the user story, they reveal their cards at the same time.
• Arriving at a consensus can give the team a false sense of confidence.
• In this way, the discussion portion of a planning poker meeting can lead to a team talking itself into believing it can accomplish more with less time than they actually can.
• Items are added to the product backlog incrementally throughout the project’s lifespan.
• But don’t underestimate the impact this gamified ritual can have on your ability to estimate the work required to achieve your sprint goals (and plan accordingly).
• You ask a contractor for an estimate on how long the remodel will take and approximately how much it will cost.

Several projects fail or get interrupted due to a lack of team collaboration or having a different mindset. The most challenging is the estimation process, where all the project managers, testers, and developers get stuck. They find it difficult to estimate how much effort is required to complete a specific task. One of these benefits is the ability to play planning poker remotely, which is great for hybrid work teams. And since it’s completely digital, you’ll get richer insights and faster play times, making the entire process more productive. In planning poker, each member of the team is given a number of cards.

What Is Program Increment Planning (PI Planning)?

It gained widespread popularity after being included in Mike Cohn’s book, “Agile Estimating and Planning,” published in 2005. The technique was inspired by the Wideband Delphi method and was adapted to fit the agile principles of collaboration, iterative development, and continuous improvement. Over the years, Planning Poker has become a staple in the agile community and is now used by thousands of software development teams worldwide. Second, a lively dialogue ensues during poker planning, and estimators are called upon by their peers to justify their estimates. Researchers have found that this improves estimate accuracy, especially on items with a lot of uncertainty as we find on most software projects. Team can use planning poker anytime they need to estimate product backlog items.

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. Research suggests a group estimate tends to be more optimistic than the forecast that the group’s members would come up with in isolation.

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. 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).

So instead of looking at every new work item separately, why not compare it to previously finished work items? It’s easier for humans to relate to similar items than to guess the actual size of things anyway. Over time, teams sometimes tend to shift their frame of reference.

In this way, the discussion portion of a planning poker meeting can lead to a team talking itself into believing it can accomplish more with less time than they actually can. If you can provide prereading for the team and an agenda of the stories that will be covered, that is highly valuable to a smooth and productive estimation session. It helps if team members come prepared with questions and an idea of what will be covered in the meeting.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done. When we start on this path, it’s difficult to know how much work we might get through. But over time, the team builds up a track record of performance and understanding as a group. Eventually, you develop a shared understanding of roughly how many points you can get through in a given period.

This is important on an agile project because the user stories being estimated are often intentionally vague. Teams also use Planning Poker as new product backlog items are added. https://www.globalcloudteam.com/ This activity, called product backlog refinement, typically happens about once per iteration. If all estimators all selected the same value, that becomes the estimate.

Now that everyone has heard the story, the group will discuss it. The group will also use this time to ask questions about the story. The decks are limited, with significant number-jumps, because the goal is for all participants to reach a consensus number for each story. Giving participants too many options—say, each number from 1 to 50—would make the process inefficient. The feature list, often a list of user stories, describes some software that needs to be developed. This Q and A is a valuable way to engage the team with requirements and to refine the backlog.

Planning poker (also called Scrum poker) helps agile teams estimate the time and effort needed to complete each initiative on their product backlog. The name from this gamified technique is planning poker because participants use physical cards. These cards, which look like playing cards, estimate the number of story points for each backlog story or task up for discussion. 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.

We can use this estimation of potential capacity (30 points) to focus on determining which of our 10 work items we can actually complete during the next period of time. Maybe these are the work items represented by the scores 2, 2, 5, 5, 13, 3, but they could also plausibly be 5, 5, 13, 8. The important thing is that you have an idea of what you can realistically do in the time available. The objective of this stage is to discuss any differences and reach a consensus on a single score for a given piece of work to represent the team’s collective effort estimation. For example, no work is required if the thing being asked for already exists. On the other hand, you can’t build something for which the technology doesn’t yet exist.