To Estimate or Not to Estimate a Large Product Backlog?
Get over the dilemma on estimating a quite large Product Backlog
A Product Backlog with a long list of Product Backlog Items (PBIs) is just an idle queue of ideas that has a non-zero cost to just keep around. Those PBIs are just sitting there idle adding no value.
If your program/portfolio has a culture of measuring lead time, then all these PBIs do help to increase the same considerably.
Let us not get into finding the reason behind why a large Product Backlog exists in the first place. (That can come as part of another article 😊)
Time to take a closer look at the Alternates
Assuming a large Product Backlog is what we already have in place. What are the possible factors we have in favor / against when it comes to deciding to estimate them?
Decision 1: Not Estimating a large Product Backlog
There are a whole lot of opinions out there in the industry for not deciding to estimate a large Product Backlog. Pulling a few factors and taking a closer look around why not estimate in this post:
- Pay now for realizing value later
Estimating a large Product Backlog takes time. To be very specific, a lot of time. Spending time now to estimate something that we may benefit from much later is an investment worth a debate. And in particular, if our attention and energy now are required for a high priority business outcome, performing an estimation at this scale becomes quite expensive.
- Understand and learn how to re-learn and Implement later
Performing an act of assigning estimates is not a simple task similar to buying sweet potatoes. Often we forget the intent behind those old and large items in the Product Backlog when it is time to start working on them. Investing time now to just learn and get familiar with the PBIs might force a lot of re-learning later. This rush to estimate the entire Product Backlog in one go can be seen as rework and waste.
- Well-refined Product Backlog Items
Few Scrum Teams are mature enough to refine and decompose Product Backlog Items (PBIs) to a granular level. This is done to relatively ease forecasting and time taken to pull work items for implementation. In this scenario, the same large Product Backlog is not made of few but might have several hundred items lined up to size in one go. The intent behind refining is to make sizing easier but definitely not sizing in one go easier.
Note: Remember the previous two factors along with this one to understand the rationale behind why not to estimate a large Product Backlog.
- Estimates turning out to be promissory notes
Estimates are forecasts made at a time when we know very little about the stuff we are planning to deal with. Unknowns in an uncertain world make life much harder and difficult to manage. What we arrive at as estimates for the large Product Backlog, creates a lead for managing cost, effort, schedule, and even the scope. Estimates in this scenario may turn out to be promissory notes by the Developers* eventually turning against them when not expected for. Early estimates are not promises made.
Had a chance to look at why it is a wise thing not to estimate a large Product Backlog. Now let us move to another side of the table and look at some of the merits in estimating a large Product Backlog in one go.
Decision 2: Estimating a large Product Backlog
- What if there is no other choice than to bite the bullet
Replacing critical and monolith systems cannot be done in fragments. The customers who are enjoying the real benefits from those monolith systems may not get convinced with smaller increments in the meanwhile till we move the existing system to a new technology stack. We are left with no better choice than to bite the bullet and envision an MVP that is quite large and hence a Product Backlog with several important PBIs. A high-level estimate might come in handy instilling confidence in starting the migration but can never replace working software and measuring progress using the same.
- Start communicating early on expectations
Plans that we come up with a need to be based on real outcomes and should be aligned with actual trends. If not, expectations can easily be mismanaged. When this happens trust that remains fundamental to the work getting done might go down. The larger the work scale the higher the impact of such trust failure. To set the right expectations on realistic forecasts, estimation of a large Product Backlog is typically needed.
- Help plan to synchronization and highlight dependencies
It is always better to give the ‘bad news early’ rather than late. The difficulty in estimating the entire large Product Backlog help the Developers* get vocal about their understanding, implementation challenges, and associated dependencies. Calling out dependencies early and timely promotes better decision making as a team together. I completely agree that not all dependencies do get to the surface in one go with this approach nevertheless a considerable level to come out to stay in sync and give early smells.
- Sensitize the business urgency and order the Backlog
Driving urgency on solving the most important customer problem is felt only when the Product Owner appreciates providing a single ranked list of PBIs for the Scrum Team to iteratively and incrementally work towards. The act of providing an ordered list of PBIs cannot be replaced with spaghetti in abundance. Wishful thinking may not be enough to create a wake-up call always. What if, we need to run the whole 9 yards to say it’s quite long or need better managing the Product Backlog? Then tactically there is not much choice left other than to size it at a high level and help sensitize the nature and volume of work lined up ahead to tackle.
Wrap Up!
I can understand how disappointing it looks from a readers’ standpoint to surf the entire content to finally hear from me stating ‘This is for you to decide’.
I can only hold up the mirror by providing insights on the pros and cons of estimating a large Product Backlog in one go.
Now it’s up to you as a practitioner to figure out what works best given the context in which you operate. But remember any time to inspect and adapt by being transparent.
*Developers — The term ‘Development Team’ mentioned in Scrum Guide 2017 changed to ‘Developers’ since Nov 18th, 2020 with the recent Scrum Guide changes.
Refer to the latest Scrum Guide here: https://www.scrumguides.org/scrum-guide.html
