I spoke with a Scrum Master recently who told me his team had nearly doubled their velocity in only two months. Rather than be happy about this, though, he was concerned.
He knew the team had not suddenly become twice as productive. In fact, he doubted they'd actually sped up at all. Yet their velocity showed they had.
The cause of this sudden and dramatic increase was story point inflation. Or, more generally, estimate inflation, because the problem can happen with estimating units other than just story points.
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.
Why Does Estimate Inflation Happen?
There are a few possible causes of estimate inflation. One of the most common, though, 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.
Velocity becomes a really tempting (but bad) metric in these cases and teams are pushed to demonstrate that they’re going faster by increasing velocity.
When a team is under pressure to increase velocity, team members will often start to round estimates up during story point estimate meetings (often done with Planning Poker). For example, consider a team that is debating whether a particular story is three or five points. They’re having a legitimate debate about this.
At some time during that discussion, one or more people will remember the team is under pressure to increase velocity. And some might shift in favor of calling the story five points instead of three.
I want to be clear this isn’t lying. It’s not blatant padding. The team was truly debating three versus five. And when someone remembers the team is under pressure, that person switches to favor five.
And so that story is called a five.
Now consider 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.
How to Prevent Estimate Inflation
I’ve found the best way to prevent estimate inflation from occurring is to always compare the item being estimated against two (or more) previously estimated product backlog items. In my “Agile Estimating and Planning” book, I referred to this as triangulation, borrowing the old nautical term for fixing a ship’s location.
So, 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. These comparisons are shown in Figure 1.
Triangulating a 5-point story by comparing it with 3-point and 13-point stories.
Each story, A-F, has been compared with two or three other stories.