May 5, 2024
Feature Spotlight - Planning Poker
Planning poker is a process used frequently by teams to aid in estimating the point values for tickets in their backlog. The goal of planning poker is to create an environment where team members can provide honest estimates for the given ticket and achieve a consensus amongst the team.
In practice teams frequently struggle to implement the process which can undermine the effectiveness of the process and slow down progress. This includes:
- The process of running a poker session can be very time-consuming with many sources of delays and distractions.
- The estimates and reasoning associated with them is important knowlege that is not often captured and retained when the process is conducted verbally or offline.
- Teams frequently struggle to give meaning to point values which can devolve into '1 point = 1 unit of time' styles of estimation.
- Approaches that do not preserve anonymity are vulnerable to various forms of peer pressure.
The latest release of MergeBack includes a built-in planning poker feature to allow teams to quickly jump into a planning session, share estimates and retain history for each ticket in their backlog.
Improving the Process
There is a lot of work that goes into setting up a planning session: assembling participants, explaining the process, coordinating which ticket is being looked at, soliciting responses and reviewing results.
Beyond that there are other pitfalls that teams can encounter during a session of planning poker. Participants can easily lose sight of the goal and focus too much on 'solving' the problem described in the ticket rather than estimating it. It is an easy trap to fall into since the process of estimation does usually involve some degree of brainstorming but this can quickly drag out the time-cost of estimating a single ticket.
Online tools for planning poker can be invaluable at cutting down the costs of a poker session and keeping the team on track. Unfortunately if these tools are not integrated into the backlog management software they will often fall short of being a complete solution.
With the latest release team members now have the option to start a new poker session when viewing a ticket in the project chat screen:
This will automatically inform the team that a poker session has been started which they can click and immediately open both the poker screen as well as the related ticket.
From there the organizer can wait for responses to arrive and complete the round to view those responses. They then have the option of either accepting the chosen estimate or starting a new round.
Participants will automatically have their screens updated as the organizer navigates between viewing round results and starting new rounds, eliminating the need for additional coordination and minimizing delays.
Poker rounds for a ticket can be later viewed as part of the ticket details in case they contain useful information about a ticket's cost.
Improving Points
Many teams new to agile and scrum will struggle with understanding what a 'point' means when estimating tickets. Even after being given a proper explanation of points it can still be difficult to apply them in practice. One common end-result of this is team members begin to view points as being equivalent to some unit of time.
This mistake is often derived from a misunderstanding of what is being 'estimated' during a poker session. In the context of backlog refinement we are more focused on estimating confidence levels in a ticket and not how long it will take to complete. We are trying to answer the questions 'Is this ticket ready for a sprint?' and 'What needs to be done to make it ready for a sprint?'. Time estimation comes later when the sprint is being planned.
The number of points assigned to a ticket can indicate issues with it such as:
- The problem is complex and requires a minimal level of expertise.
- The ticket involves an area of the product that is notoriously fragile or tedious.
- The amount of work in the ticket is high despite the difficulty being low.
In other words: higher point tickets indicate a lack of confidence that the work can be completed in a single sprint and gives us clues on what steps should be taken to regain that confidence.
In an attempt to promote the right mindset when choosing point values MergeBack offers suggested values based off the user's responses to two basic questions:
By framing the points in terms of confidence and complexity users will be less inclined to simply estimate based off of time. As team members adjust to looking at points this way they will be able to view the ticket's point estimate later and make more informed decisions around who should work on the ticket or what additional steps need to be performed to bring that point value down.
Examples of how to interpret point values include:
- One point tickets are ideal for any team member to complete in any sprint as they represent work items that are simple and low risk.
- A ticket with point value 3 would mean any team member should be able to complete it in a single sprint but a less-experienced individual could take more time to complete it than an experienced member.
- A ticket with point value 5 indicates that the ticket is simple in nature but requires a lot of work. The preferred way to bring down the point estimate would be to split it up into multiple tickets.
- A ticket with point value 13 might mean the ticket is more complex in nature and that it may need to be demystified by having an experienced member break down the problem better.
- Tickets with point values exceeding 13 would dictate the need for some combination of breaking into smaller tickets and demystifying details about the tickets. This would likely involve higher level participation in the form of design documents, dedicated releases and other forms of long-term planning.
For experienced teams or teams with established processes can skip this step and simply provide their chosen point value directly:
The Problem of Anonymity
When planning poker is performed in an environment where response identities are revealed (either intentionally or unintentionally) the dynamic is vulnerable to peer pressure driving the estimate to an artificial agreement.
This could take the form of an assertive senior developer taking a hard stance on an estimate or a shy junior developer afraid of making a 'mistake'.
The results of this can lead to participants that are no longer trying to honestly estimate the ticket but are merely trying to guess what the other participants choose based off previous tickets or previous rounds for the current ticket.
MergeBack assists in preserving anonymity by scrubbing identifying user details on the front-end. When the data is requested from the server the usernames and ids will be removed aside from the requesting user's. This is also true for the person running the poker session.
The end result is a simple graph showing the responses chosen, how many users picked that response and the individuals reasons for those responses.
While this feels like a seemingly insignificant detail it creates more breathing room for team members who may struggle with some of the social aspects of planning poker and create a space for them to learn how to estimate point values properly.