#1 Reason Your Projects Are Late

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.

  1. Ask team members what percentage of the ultimate solution they think they see (50 percent? 80 percent? 25 percent?). 
  2. The project buffer is 1 divided by the percent known.
  3. 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. 

Math equation for calculating product size buffer

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. 

Math equation for calculating product size buffer with example

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. 

Math equation for calculating product size buffer with example

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. 
 


Agile Estimating and Planning

Agile Estimating and Planning

This agile training shows you how to go about agile estimating and planning, and why it’s crucial even in a fluid and iterative process.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.