Your project is late. Again. The reason why might surprise you. It's likely not because your team is bad at estimating with story points. And it's almost certainly not because your team is lazy. In my experience, the number one reason projects are late is simply because your product is bigger than you think it is.
You have a good idea of what the final product will look like, but the complete picture is impossible to visualize at the beginning.
4 Reasons Products Grow Beyond Initial Estimates
Let’s look at four reasons why products (and their product backlogs) end up being bigger than we think.
1. Products Evolve Over Time
The first is that needs evolve. What your users need today will not be what they need later. The longer it takes to go from learning their needs to delivering them, the more those needs will evolve.
2. Product Backlogs Have Emergent Requirements
Second, requirements emerge. Some features in a product can only be discovered after you start developing the product. As you do, you give early versions of the product to users. They play with it. They experiment. And they come up with new ideas.
These emergent requirements are features no one would have thought of until they experienced the partial product or system. They make your product larger than you thought because they were unanticipated.
3. All Teams Overlook Some Requirements Sometimes
Third, some requirements are overlooked. No matter how hard you try, it’s probably impossible to identify upfront everything your users will need. When interviewing users, you’ll forget to ask a question, you won’t follow through with something a user mentions, or you’ll run out of time. You’ll overlook something.
4. Some Objectives Are Harder-than-Expected to Achieve
Fourth, some objectives will be harder to achieve than expected. Teams add features, functions or capabilities to a product to achieve defined objectives.
For example, an airline may want to improve software used by its customer service representatives so that those reps can more quickly re-route passengers affected by flight cancellations. The airline’s developers plan to achieve that objective using a new AI system to suggest passenger re-routing.
After implementing that new capability, team members measure the impact and learn that it has only gotten the organization halfway to the desired outcome.
In that case, there will be additional work required to obtain the objective. And, so, the product has become larger than initially thought.
How to Account for Product Unknowns
First is to acknowledge that no matter how well team members do the job of understanding user needs, they will not think of everything.
Second, have a frank conversation with stakeholders (the product owner's second team) about the realities of product unknowns. Get them to acknowledge that they aren’t done thinking about what’s needed, that needs will evolve, and that it’s impossible to think of everything.
Third, avoid making promises about when a product’s full scope can be delivered without adding some amount of buffer to account for how much larger the full product may truly be. But how do we know how much buffer to add?
How to Calculate a Product Size Buffer
Here’s one technique I’ve used for deciding how much bigger a product will likely become.
- Ask team members what percentage of the ultimate solution they think they see (50 percent? 80 percent? 25 percent?).
- The project buffer is 1 divided by the percent known.
- Multiplying the size of the current product backlog by the buffer gives you an estimate of the true size of the product.
For example, if the team says they think that they see about half of the ultimate solution, that means that the unknown part of the product backlog is the same size as the known items on the backlog. If so, the full product is double the size you think it is right now.
The formula for this is just 1 divided by the percent the team thinks they know times the current size of the product backlog.
I just gave the example of a team thinking they currently see half of the ultimate solution. Substituting 50%, or 0.5, into the formula, you can see that the full size of that product is double the current size.
Looking at one more example, suppose the team has a series of conversations with users and stakeholders. Based on that extra data, team members believe they see about 80% of what users will ultimately need in this product. When we substitute 80% into the formula, we see that the full size of the backlog is 25% greater than the current size.
A rough calculation like this can give you an approximation of how much larger your product is than the team thinks it is presently. This larger size can be used in forming more accurate long-term forecasts when necessary.
What have you experienced that made your products bigger than anticipated? Please share your experience in the comments.
