How to Estimate a Product Backlog
Many challenges faced by Scrum teams can be traced back to poorly written and poorly maintained product backlogs. A key ingredient to product backlog health is that every user story is kept up-to-date with accurate estimates. For example, teams will be unable to fulfill their accountability of forecasting milestone completion dates until the full product backlog is estimated. Finding the time to estimate the full product backlog and keep those estimates current can be daunting for Scrum teams. Here are some tips on estimating your full product backlog like a pro.
“Product Backlog items have the attributes of a description, order, estimate, and value. ”
Start Estimating from the Bottom of Your Product Backlog
Try starting your next estimation session by talking about items at the bottom of the product backlog and then moving up. Most teams work the other way around, from top to bottom, to ensure they have stories ready for the next sprint. The problem with this approach is that conversations rarely move beyond the first few stories, causing the middle and bottom of the product backlog to atrophy and become further and further out of date. This creates a condition I call the graveyard backlog that reduces much of the value of the product backlog while making it next to impossible to update milestone forecasts.
Scrum teams rarely use their allotted maximum of eight hours per two-week sprint for product backlog refinement. Starting from the bottom of the product backlog can help teams gauge how much time is needed to keep their full product backlogs up to date because they’re not likely to stop until they have stories at the top ready for the next sprint.
Starting from the top of the product backlog can lead to long and detailed conversations about important tasks. Pulling conversations out of the weeds once they become finely detailed and design-oriented in this way is a notoriously difficult task for facilitators. It’s easiest for teams to start with high-level conversations about stories that are further down the product backlog first and then move into more detailed conversations and finer-grained estimates second. When facilitating both types of estimation in a single session, it can be helpful to form a clear boundary between the two approaches by taking a short break in between.
Stop using Planning Poker for High-Level Estimates
In the software world, there’s a principle called “You Ain’t Gonna Need It”, or YAGNI for short, which cautions us to minimize time spent on work that is likely to lead to waste later. YAGNI comes to mind when I see teams using Planning Poker to estimate items in the middle and bottom of their product backlog because Planning Poker is often a slow and expensive process. Items at the bottom of the product backlog often never reach the top, those that do reach the top can be very different when they arrive, not to mention that only 20% of those that do reach the top and get implemented are rarely or never used. For these reasons, spend less time estimating stories in the middle and bottom of your product backlog by using estimation techniques other than Planning Poker which are more suited to fast higher-level estimation. Since stories at the bottom are likely to change by the time they’re implemented, fast high-level estimation techniques are often as accurate as highly detailed estimation techniques. My favourite fast high-level estimation technique is called Blitz Estimation. Here’s how it works:
Setup
Place cards representing each number in the modified Fibonacci sequence in order from left to right across a large table (1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞) upside down so that no one can see the numbers.
Write the name of each user story on an index card, shuffle the cards and leave them on the table.
Designate one user story of known size as a reference point by placing it under one of the middle story point values.
Set context for the activity by telling the team that they'll be doing a fast high-level estimation activity to ensure every item on the product backlog has an initial estimate and these estimates will be used to forecast milestone completion dates. Remind the team that forecasts are not commitments, forecasts will change as more is learned and the team will have the opportunity to discuss each story in greater detail as it moves up the product backlog.
Give the team a timebox of 30 to 60 minutes to arrange the stories from left to right in order of smallest to largest. Items of similar size can be stacked vertically in columns. Ask the team to do this step in silence to encourage speed in estimation and to keep estimates at a high level.
When the team is done arranging the stories, turn over the Fibonacci cards to reveal the estimates.
At the end of the timebox, every user story will have been sized relative to one another and have an estimate in user story points.
Transfer the estimates to the product backlog and use them to forecast likely milestone completion dates.
If You’re Going to Use Planning Poker, Use It Correctly
Teams will naturally want to spend more time discussing and estimating User Stories at the top of their product backlog and Planning Poker can be an effective way to facilitate their lower-level conversations and estimates. Unfortunately, most teams use Planning Poker in their refinement sessions incorrectly and spend more time than necessary doing it. The intended outcome of Planning Poker is a common understanding across the Scrum team about the problem to be solved and a consensus on how big that problem might be (the estimate). Planning Poker is not intended to produce a solution to a problem or a design for how that solution will be implemented. Scrum intentionally defers those solution and design discussions to Sprint Planning Topic Three (The How) and to the sprint itself where there is a guarantee that the team will actually be implementing those stories - YAGNI. In my experience, most teams doing Planning Poker incorrectly by spending hours on solution design are seeking predictability in organizations that punish teams for missing sprint commitments.
Try this instead: Keep Planning Poker moving by focusing the conversation on the size of each story when compared to other stories and whether stories need to be broken down to fit within a sprint. Start a round of planning poker by voting instead of beginning with conversation. Starting with votes eliminates the groupthink that happens when loud or senior voices dominate the conversation. Starting with voting also allows teams to skip lengthy conversations altogether when everyone on the team has the same (or similar) vote - YAGNI. Planning Poker is based on research into the Wideband Delphi technique and works best when the process manages who speaks and when. So, stick tightly to the process of Planning Poker and don’t let the group devolve into an open conversation which can lead to wasted time talking about features and designs that may never be built - again, YAGNI. Here’s the proper process for Planning Poker:
Each Developer who will be doing the work is given a set of cards that are based on a modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞. Notice that the larger Fibonacci numbers have been intentionally rounded down to avoid a false sense of precision. Relative estimation with Planning Poker is intended to be accurate, and not precise. This is an important distinction that helps the team remember that estimates are not commitments, but forecasts that are expected to change as more is learned.
The Product Owner presents a user story to be estimated. No questions or discussion is allowed until estimates have been made.
Each team member privately selects a card representing his/her estimate. To avoid coercion and groupthink, all selected cards are revealed at the same time.
If all team members select the same card, then the estimate is set at that point value without further conversation.
When estimates diverge, the person with the highest estimate and the person with the lowest estimate describe to the team what work they believe is involved.
Repeat steps 4-7 until the estimates converge. To move more quickly, simply pick the higher card and move on when estimates are within one or two Fibonacci numbers.
Invite Stakeholders, but Only the Team Estimates
Invite customers, subject matter experts, and stakeholders to estimation sessions. Their presence can energize the group and create relationships between the team and the people who will benefit from the work of the team, leading to higher engagement for all. Perspectives from this group often lead to new insights and more accurate estimates. That said, only the people doing the work have final decision-making authority on the estimates. Outside experts may understand the problem space better than anyone but only the Scrum team can know about size relative to their other work.
Estimate the Full Product Backlog During Refinement Sessions
Start getting more from your product backlog refinement (PBR) sessions than just planning the next sprint’s work. PBR sessions are your golden opportunity to promote health across the full product backlog. If you want to see what a healthy product backlog looks like, check out my article on The Perfect Product Backlog. Here’s a sample agenda of a great product backlog refinement session:
Discuss the goal of the session and make a plan for your time together.
If there are a large number of unestimated user stories in the product backlog or just more than you have time to estimate using Planning Poker, use Blitz Estimation to create initial estimates.
Break down any stories at the top of the product backlog that may be too large to fit within a single sprint.
Use Planning Poker to estimate stories coming up in the next one or two sprints.
As you can see, a few small tweaks can make estimating a product backlog faster and less daunting. Try starting from the bottom or going back to the basics of Planning Poker to ensure that you’re using your refinement sessions effectively and still meeting the needs of your stakeholders.