How to Avoid Estimate Inflation
Mike Cohn recently wrote about preventing estimate inflation in Agile teams. I’m in agreement with Mike that estimate inflation commonly comes from a team being pressured to deliver more points per sprint (or greater velocity). And Mike’s counsel to triangulate, that is compare the relative size to two other items, is well-founded.
While this helps a team get more predictable at estimating, it steps over something significant: there’s always pressure to deliver more per sprint.
Story points are about effort. When I’ve checked, clients and customers don’t care about how hard we work. They do care about outcomes, about solving the problems they have.
Agile and Scrum are about increasing outcomes for our clients and customers. But how? By looking at all the attributes of a backlog item.
The Scrum Guide notes four attributes for a backlog item: description, order, estimate and value. Now, backlog items have to have at least description and order to exist in a backlog. And Development Teams get to set estimate / effort, sometimes called size, of an item. That’s part of their role of assessing what can be accomplished in a sprint.
Heck, value is even one of the elements in Bill Wake’s INVEST model for user stories (one way of forming product backlog items).
In my experience, it’s rare that a backlog item has value set as clearly as the attribute of estimate / effort. In comments to Mike’s original post on his blog, he notes there are challenges around value. (Fun fact, said Sheldon – It’s illuminating to parse the Scrum Guide. By my count “Effort” is used twice; “Estimate” is used 9 times; “Value” is used 12 times.)
So, how does a focus on value slip?
By conflating (blending) value with estimate and / or order of items in a backlog.
Consider that Agile and Scrum work very well in small, co-located teams. In these instances, the vision of a product and its goals are easily accessible to the Development Team. The team is intimate enough with objectives that even if value is not explicitly noted, it’s well and commonly recognized throughout the Scrum Team. Because of that implicit understanding, it’s easy to blend value with the attributes of estimate and / or order.
Over time, as the product gets more complex, or the organization grows into multiple teams, that vision for a product and its goals can get more remote from the Development Team. Distributed and dispersed teams are common, leading to a Product Owner being physically remote from some, if not all of a team.
Product Owners are always bridging between clients / stakeholders and teams. The tug of attention to stakeholders can lead to a Product Owner having the Development Team manage the backlog, including optimizing the value of their work (and that’s OK by the July 2013 version of The Scrum Guide). But wait: clients / stakeholders are now even further removed from a team than the Product Owner! Rather than setting value of backlog items, this challenge leads many Product Owners and teams to let it slip. And when I’ve asked, they clearly blend value with estimate and / or order.
I don’t think we (or our teams and Product Owners) should give in and skip setting value.
By switching management’s focus away from points per sprint and towards value delivered per sprint, we can avoid estimate inflation pressure AND increase outcomes.
More, by focusing on value, we promote at least two Agile Principles: Simplicity and Sustainable Pace. By deprioritizing low value work, we simplify what we’re creating, maximizing the (low value) work not done. In focusing on value delivered, a team doesn’t have to spend more effort (either in time or difficulty) to respond to that pressure for more in a sprint, and we maintain a constant pace of work.
Customers and clients care about early and continuous delivery of valuable products, more than about how hard we work. Improving the predictability of our estimates is worthwhile. And, while I agree with Mike that there are challenges in setting value, I think they can be addressed. In my upcoming entry I’ll share one of the remarkably effective techniques I coach & train Product Owners and Scrum Teams to use to set up explicit value for backlog items.