Planning poker, also known as Scrum poker, is a method of estimating effort in software development and project management.
Its main objective is to assess the complexity of tasks and User Stories. It’s a collaborative, consensus-based approach to work, fostering a common understanding within the team of the effort required for each specific job.
Planning poker is frequently used in agile methodologies such as Scrum and Kanban.
Key points
In this article, we’ll explore the objectives of Planning Poker, the main participants, estimating techniques, the distinction between Story Points and Man Days, the methodology for conducting this ritual, and finally, we’ll conclude with some tips and tricks to remember.
Why Planning Poker?
The main aims of a poker schedule are:
Reliable estimates
Improve the accuracy of estimates by encouraging group estimates rather than relying on a single expert.
Involving developers
Estimating is a collaborative process in which each member actively participates and shares responsibility for estimatation.
Sharing knowledge
Collective discussions, whether functional or technical, offer the whole team the opportunity to strengthen their skills and expertise.
Full commitment
It’s not just an estimate, but a meeting combining functional and technical design. We analyze, slice and dice, understand, confront the constraints, and make a collective commitment to the reliability of the estimate.
When to conduct a planning poker?
Planning Poker is a common practice in Agile methodology. Here’s when it’s usually used:
Sprint Planning
sprint planning
Before the start of each Sprint, the development team meets to carry out Sprint planning. This usually includes a Planning Poker session to estimate the User Stories or the Product Backlog Items (PBI) that will be included in the Sprint.
Backlog Refinement
Backlog Refinement
During the backlog refinement the team can use Planning Poker to refine estimates of backlog items, particularly when new information becomes available.
Prioritization
prioritization
The key element needed to start a sprint planning is the ‘Product Backlog‘. It must be prioritized by the Product Owner. During sprint planning the team selects items from this backlog for inclusion in the sprint.
Risk Management
Risks
In the case of potential risks linked to complex or uncertain tasks, a Planning Poker session can be organized to better understand the implications and efforts required.
In the Agile framework, Planning Poker is a key tool for estimating effort, fostering collaboration and maintaining transparency in the development process. It is used to ensure that the team shares a common understanding of the tasks and functionalities to be carried out.
Agility: More Reading
Who participates in Planning Poker?
Scrum Master
Facilitateur
The Scrum Master is responsible for facilitating the Sprint Planning Meeting and plays an active role in the Planning Poker session, ensuring that the process runs smoothly.
Product Owner
Sponsor
The Product Owner is responsible for managing the product backlog, and may participate in providing information on functional requirements and priorities.
Scrum Team
Réalisateurs
These are the people who work directly on tasks and User Stories. They are essential for providing estimates based on their understanding of requirements and technical complexity.
Does the Product Owner estimate ?
- It’s possible to do this, and it can sometimes clear up ambiguities and make it easier to understand the estimate.
Does the Scrum Master estimate?
- It’s possible if it doesn’t influence the team.
Frequently asked questions about Planning Poker
In which unit do you estimate?
No matter: Story Points, men’s days, ideal days, T-shirt sizes… the method remains applicable.
Generally speaking, User Stories are estimated as Story Points and Tasks (after the team has broken them down into Sprint Planning for example) in hours.
What estimation scale should be used?
The larger the item to be estimated, the less reliable the estimate.
We therefore use an estimation scale that reflects this uncertainty:
- Adapted Fibonacci sequence: 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 → Recommended
- Garment sizes : XS, S, M, L, XL, XXL
What to do if you disagree with an estimate?
In the event of disagreement, team members hold discussions to clarify points of divergence and seek consensus. Discussion is encouraged to arrive at a common estimate.
Can online tools be used for Planning Poker?
Yes, there are many online tools designed specifically for Planning Poker, enabling remote teams to participate effectively as:
How do you estimate?
By analogy : the element has the same “size” as a “similar” element already estimated
By comparison : one element is larger than a less complex element
From experience : an item we’ve already delivered was similar
Which estimating support to use?
There are several ways of representing the selected estimation scale:
- A physical deck of playing cards.
- A Smartphone application such as:
- Scrum Time for iOs
- Scrum Poker Cards for Android
- His fingers
- The most important thing is that everyone involved has their own support.
Is Planning Poker suitable for all Agile methodologies?
Planning Poker is mainly associated with Scrum, but it can be adapted to other Agile or project management methodologies, depending on the team’s needs.
What are estimation points for?
Estimate points are a relative measure of the complexity or effort required to complete a task or User Story. They help plan the team’s capacity for a Sprint.
Estimation in “Man Days” VS “Story Points”?
Estimating in “Story Points” and “Man Days” represents two distinct approaches to project management, each with its own objective.
Story Points
Intrinsic measure of effort.
The “Story Points” estimate gives the true complexity of the work to be done. This allows backlog items to be compared with each other to determine their order of priority, without specifying a fixed unit of time.
The story point is relative, as each team uses a different reference.
Man Days
Related to individual performance.
The “Man Days” estimate is based on the actual time each task or User Story will take to complete. It’s all about individual performance.
A technical expert will be able to get the job done in less time than a junior developer.
To better understand the difference between the two, let’s take the example of the Marathon(estimation of this length in distance or time):
The length of a marathon is 42.195 km, or 26.219 miles. Fabien completed the marathon in 4 hours, while Karim did it in just 3 hours and 30 minutes.
In this illustration, distance is evaluated in terms of units of measurement, whether “Kilometer” or “Mile”. Similarly, Story Points are used to estimate the intrinsic complexity of a task, although their unit/value can vary from one team to another, demonstrating the relativity of Story Points.
The variation in journey times between Karim and Fabien reflects the differences in their individual abilities, and this can be compared to the equivalent of man-days in the estimates.
How do I plan a Planning Poker?
Planning Poker estimation follows an iterative process that continues until a consensus is reached. Here is a detailed description of each step:
Card distribution
At the start of the Planning Poker session, each team member receives a deck of cards, usually called a “Deck”. This deck contains numbered cards or cards containing other values, corresponding to the scale chosen for the estimates, for example, the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or the T-shirt scale (XS, S, M, L, XL).
Description of User Need
The Product Owner presents the item in the Product Backlog to estimate.
He describes the user need, clarifies requirements and answers questions from team members to ensure that everyone has a common understanding of the task or User Story.
Individual Evaluation
Each team member evaluates the element by selecting the card corresponding to their personal assessment. Everyone does this independently, without sharing their choice with the other team members.
Simultaneous Revelation
Under the direction of the Scrum Master, all team members simultaneously reveal their cards, showing them to the other participants. This avoids the mutual influence of estimates.
Discussion of Deviations
If the estimates do not converge and there is no clear consensus, team members engage in a discussion to understand the reasons for the differences between the estimates. Members share their perspectives on the complexity, risks or uncertainties associated with the task.
Process repetition
After the discussion, team members repeat the process, again selecting an estimation card. This step is repeated until a consensus is reached, i.e. when the majority of the team agrees on a common estimate.
The fundamental idea of Planning Poker is to reach the most accurate estimation possible without members influencing each other.
If there is a large discrepancy between two estimates, the team discusses the differences and tries to reach a common vision of the work involved in the item:
- Or by discussing extreme values: why did you estimate 13 and I estimated 2?
- Either by eliminating extreme values and focusing on “reasonable” ones.
So the aim is to bring out any misunderstandings if the estimates are very different, and everyone expresses themselves freely.
Special cards
- Display a “?“if the request is not clear enough to estimate, or if you don’t know how to estimate.
- Avoid giving an estimate if you don’t know: this influences the team and risks distorting the final estimate.
- Post a “Coffee Break” if you’re tired and less focused.
Why is it the best estimating technique?
Planning Poker is widely considered to be one of the best estimation techniques due to several significant advantages:
Fun
Planning Poker adds a fun element to the often dry task of estimating. Team members select cards and actively participate in the discussion, making the process more engaging and enjoyable.
Developers will carry out the tasks they deem appropriate
Planning Poker directly involves the members of the development team who will be responsible for carrying out the tasks. They therefore gain valuable insight into the challenges and nuances associated with each element, improving the quality of estimates.
Expert opinions and discussions
Planning Poker encourages open discussion of differences in estimates. These discussions enable team members to justify their estimates based on their expertise, which improves the overall accuracy of the estimates.
Time-saving
Planning Poker makes it possible to explain requirements to all stakeholders just once, saving time and avoiding repetition. Team members have a better understanding of requirements, which facilitates planning and subsequent execution of tasks.
Avoid the influence of others while estimating
By allowing each team member to estimate independently, and revealing the estimates at the same time, Planning Poker considerably reduces the risk of influence between participants. This ensures that estimates are based on individual knowledge rather than group pressure.
Involvement of all
Each member of the team has the opportunity to contribute and give his or her opinion during the estimate. This promotes inclusion and encourages a diversity of perspectives.
Reduced calibration
The deck of cards used in Planning Poker, such as the Fibonacci sequence, limits the values available for estimation. This avoids excessively detailed estimates and encourages the breakdown of items into smaller tasks if they are too large, thus promoting agile task management.
Tips and tricks
Consistency of Estimates
To guarantee the consistency of estimates between the beginning and the end of the project, it is advisable to maintain a reference estimate standard that is challenged at each Planning Poker.
Example In Sprint 1, we estimated the User Story US1 to 8 points. We integrate it into our standard. In Sprint 2, a User Story US2 is also estimated to 8 points. It is then compared with US1.
Avoiding Debate
Use a stopwatch to control the time allocated to User Stories discussions. This will encourage more focused deliberations based on common understanding.
Control overestimation
To reduce risk, it may be tempting to systematically retain the estimate with the highest value. This practice not only leads to a loss of confidence on the part of the customer, but also does not encourage junior devs to make their estimates more reliable. When estimates diverge, it’s best to open the debate to allow convergence towards a team consensus.
Encourage everyone to participate
Ensure that every member of the Scrum or Agile team has an equal opportunity to contribute to the estimate. This encourages a diversity of perspectives.
Don't mix scales
Maintaining consistency is essential in Agile estimating. Estimate points are a relative measure of complexity, while man-days are a unit of time. Converting them can cause confusion and uncertainty. It’s best to stick with the estimation points for clearer, more reliable assessments.
Avoiding influence
The Scrum Master acts as a facilitator during Planning Poker, not intervening in the decision-making process. His / Her main objective is to stimulate discussion within the team, encouraging the emergence of a consensus. It encourages team members to express their points of view, debate differences of opinion, and make informed decisions.
0 Comments