BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Mike Cohn Explains How to Prevent Estimate Inflation

Mike Cohn Explains How to Prevent Estimate Inflation

This item in japanese

Bookmarks

Mike Cohn, Agile Alliance and Scrum Alliance founding member, consultant, book author and founder of Mountain Goat Software, recently wrote about how to prevent estimate inflation in his recent blog. He explained estimate inflation as

Estimate inflation is when the estimate assigned to a product backlog item (usually a user story) increases over time. For example, today the team estimates something will take five points, but previously they would have called it three points.

There are a few possible causes of estimate inflation. Mike mentioned one of the most common cause is excessive pressure on the team to improve or deliver more points per sprint. This often comes from bosses or possibly stakeholders outside the team who are pushing the team. He illustrates the scenario when another story being estimated perhaps a week or two later. In considering the new story, someone compares it to the five-point story and thinks, “Well, this new one is a little bigger than that five,” and proceeds to estimate it as perhaps an eight. And this is how estimate inflation happens.

Tom Smallwood, Agile Coach, Consultant at Smallwood Software Solutions, Inc explains the reason of estimate inflation in his blog on Velocity Preoccupation as

Putting too much emphasis and concern on velocity will often result in gaming the system through the use of velocity inflation.

Tom says that velocity is important and useful, but consider it mostly a planning tool.

Mike gives solution to prevent estimate inflation from occurring is to always compare the item being estimated against two (or more) previously estimated product backlog items. This technique is known as triangulation which is explained in his book “Agile Estimating and Planning”.

Mike explains the technique with an example as follows:

When a team thinks about estimating a story as five points, they would first compare that story to two other stories--ideally one smaller and one larger. In deciding if a story should be estimated as five points, they would compare the story to a three-point story and think, Will the effort to do this new story be a little more than this three-pointer?

They would next compare that story against an eight- or 13-point story. And they’d want to see if the story felt appropriately sized as five in comparison to one of those.

Mike says if we think about the stories as nodes in a graph, triangulating can be visualised by drawing lines between each of the nodes the team explicitly compared while estimating as shown in below figure:

Rate this Article

Adoption
Style

BT