Estimation Inflation - What should we do about it?

When a Product Backlog Item is estimated by a team with a relatively larger value than what they would have done for the same PBI in the past is called 'Estimation Inflation'.

A good example is to look at the increase in the price of a cup of coffee over time. The infographic from Investopedia shows the inflation price trend of a cup of coffee.

What is the root cause for Estimation Inflation?

Velocity Improvement Plans or Get-well plans for Consistent Velocity is the source of all the evil that happens in the name of ‘Estimation Inflation’ with Scrum Teams. Prima facie, this might look very cliché to put the blame on ‘Velocity’, but if we understand such initiatives – it is evident who does the maximum damage to the team’s forecasts.

Capturing Velocity becomes even easier with the whole suite of ALM tools coming with all possible ideas to represent these numbers in a graphically rich content driving management to go crazy asking to continuously spike up these figures.

A Scrum Team with pressure to increase Velocity naturally starts rounding up their Size (in terms of Story Points) to match the management expectations to show improvement.

What are the drawbacks of Estimation Inflation?

Inflating the estimates considering management campaigns like ‘Driving Consistent Velocity’ or ‘Improving Velocity’ brings down transparency and shared understanding the team might achieve otherwise with the size estimates.

Estimating size with Story points brings in abstraction promoting quick decisions collectively made by the team and help improve in subsequent Sprints empirically. Now with this pressure to get well on Velocity kills every above-mentioned brownie points the team enjoys otherwise.

How to overcome Estimation Inflation?

Tip 1: Comparing the PBI getting estimated with a couple of previously estimated PBIs

Start bringing in a mechanism to continuously compare and understand the rationale behind sizing two or more PBIs earlier with the PBI under discussion for Sizing. This helps to minimize estimation inflation. To put it short, the concept of triangulation where the PBI to be sized is compared with one smaller and another larger by size and draw decisions. This channelizes the team to focus and learn together avoiding inflation patterns creeping in.

Tip 2: Making the estimates visible across the board

Making estimates drawn by the team visible to the stakeholders apart from the Scrum Team members is one gesture through which inflating the estimates from both directions does get addressed.

Imagine the Product Owner taking the opportunity to present the refined (refined - top few ordered items only) Product Backlog to the Stakeholders with size estimates provided by the Developers. This sets the expectation straight and also eliminates multiple handovers of information between the Scrum Team and actual stakeholders fabricating the feedback and in turn skewing the numbers.

Tip 3: Avoid upfront estimating with PBIs making long term forecasts

Driving long-term forecasts from the Developers when the least information is made available naturally adds a protective cover in the form of a buffer to mitigate the risk of failing to meet delivery timelines. This is exactly where we go for inflating the size estimates without any guilt instead justifying this act as an outcome of proactively managing expectations.

Tip 4: Continuously refactor the forecasts with actual progress made

Forecasting and working to perfect the guesstimates without timely inspection and adaptation is classic mistake management and teams do without any clue of where they are messing up. Remembering Helmuth Von Moltke’s quote on planning into the future is a pearl of wisdom for practitioners from falling into the trap of inflating the estimates to overcome refactoring with emergent information.

Tip 5: Stop investing energy in predicting the exact delivery dates

Perfecting on the exact delivery dates gets no credits in particular when compared with delivering value. An obsessive focus by the Scrum Team towards ‘When things will be done?’ moves away from their focus from ‘What value are we delivering to the customer?’. This is one use case for naturally sugar-coating our forecasts with enough unwanted elements (buffer, spiking values, etc.,) holding an illusion to protect the team towards meeting such arbitrary timelines.

Wrap Up!

A mindset to stay more curious, giving more importance to feedback that comes from customers through early and often the delivery of value and inclination towards learning through feedback helps the team to stay focused meeting customer expectations.

Any other focus to sustain, improve, or get-well-soon for Velocity or other similar Vanity metrics only cultivates such anti-patterns to sneak through challenging the real intent of Scrum and having Scrum teams.