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.
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.
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).
Step 4: Estimate and share
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. This activity, called product backlog refinement, typically happens about once per iteration. If all estimators all selected the same value, that becomes the estimate.
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.
Planning poker
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.
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.
Arriving at a consensus can give the team a false sense of confidence. They might still be missing important pieces of information, and their estimate might still be off. The conversational format can uncover valuable insights from members of the team who might not otherwise have a forum to share their thoughts and experiences. If no stories have been estimated, your estimate cannot be compared to anything, so we need to baseline. Aashiya has worked as a freelancer for multiple online platforms and clients across the globe.
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.
Each team member should get the same number and sequence of cards. That might look like ten cards numbered one through ten, or ten staggered cards with values like one through five, ten, twenty, fifty, and one hundred. The purpose of planning or priority poker is to help teams using the agile development methodology to reach a consensus on how long each task in a development cycle will take. According to some study on the accuracy of estimation of effort between individual and group in an experiment for a software project. 20 software professionals from the same company individually estimated the work effort required to implement the same software development project.
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.
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.
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 https://www.globalcloudteam.com/ 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.
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.
- This process helps teams to plan out how much time they will need for the whole project.
- If there is still an estimate that is far different from the rest, this needs to be resolved with further discussion.
- This backlog keeps on increasing after the user adds some requirements.
- In 2002, Planning Poker came into the picture when James Grenning believed it might help eliminate the boredom of team members while discussing projects.
This consensus-based estimation is the basis of the Agile planning poker method. Conventional wisdom tells us that the best way to handle an overwhelming task is to split it up into sub-tasks and focus on one at a time. You repeat the process with each task until you run out of them. Planning Poker makes team members break a project down into such small pieces that it becomes easier to assess the amount of time necessary to do each part.
