In the part three of this series, I argued that we should stop estimating time and/or effort of work on agile projects. Instead, we should focus on the value delivered by working software. The question posed, cribbed from the Agile Manifesto itself, was, “How do we make sure to continuously deliver value?” I’d like to offer a new agile methodology for doing just that, estimating value.
The Pareto Principle
But before we answer that question about value, let’s look at another economist’s theory:
For many outcomes, roughly 80% of consequences come from 20% of causes.
— Vilfredo Pareto
Stated more simply as the 80/20 rule, the Pareto Principle takes many forms. In software, 20% of the coding creates 80% of the value of the project. Basically, the value from effort concentrates in the top fifth of the work, and everything after that is a long tail.
Just because something takes a long time to implement doesn’t inherently make it valuable, and vice versa. Just because you can pack a bunch of one-point stories into the next sprint doesn’t mean that you should.
This suggests we should focus our effort on the most impactful work first. That is the 20% that will bring the 80% value. Working this way is just a common productivity tip: do the most important thing first. It is also not much different from some principles of XP or Lean. In both, you identify the biggest constraint and address that first, then move on to the next biggest constraint, etc.
As long as you continue to work in an agile fashion and stay aligned as a team, then working next on the most valuable remaining task means you’ll always maximize the value generated for your project.
Explicitly Estimating Value
In part three, I noted that the thing everyone is already doing is attempting to estimate value. When executives lay out a product roadmap, they are codifying the relative value of features. When you attempt to order stories in a backlog by their “priority,” you are making an estimate of their individual relative values.
To really be agile, I propose we stop measuring throughput or velocity and start measuring value. To do this effectively, companies should empower software teams to make value estimates on individual work items. They should do this by working closely with other business stakeholders to understand the product being developed.
Of course, this is just another principle from the Agile Manifesto:
Business people and developers must work together daily throughout the project.
So I’m not proposing teams do something they’ve never done before. I just want it to be explicit.
Value Estimates in Practice
What does this look like in practice? It’s relatively simple: the team should regularly assign value estimates to stories in a backlog.
You can use any arbitrary scale (integers, a Fibonacci sequence, U.S. dollars!), as long as that scale is sortable. That means you can put the highest valued items next up in the queue. The scale must also be unbounded to allow for arbitrarily large estimates.
In a Scrum-like environment, making these estimates would take the place of effort-size estimates during sprint planning. However, the scale now flips. Traditionally in Scrum, stories with very high estimates indicate ill-defined work the team might need to break down. When estimating value, very high estimates indicate the work the team must absolutely do next.
If you use a Kanban-like form of agile, you’re probably already doing something close to this, just without the explicit relative estimates. However, I believe Lean teams should make these estimates explicit as well. If you continue to track cycle/lead times, you can now further dissect the data to see if higher-valued work moves through the pipeline differently than lower-valued work.
Don’t change horses change mid-stream with a new method, but any team starting a new project together could make the switch.
The Value in Value Estimates
No matter the form of agile, teams must share an understanding of why work priorities are ordered the way they are. Having discussions about relative value will help surface disagreements and misunderstandings around ill-defined stories. Then, the team can clarify and estimate them.
From a business perspective, it’s possible to tie some trailing metrics (new customers, sales, clicks, etc.) to the release of features. This can test how well a team is estimating value. We’re getting into dangerous Goodhart territory here. But, overall alignment at an organization on what constitutes “value” and if it’s being delivered is a good target!
This also prevents someone from moving something out of order in the next up queue of work, something that regular effort estimates can’t do. If you want to change the order, everyone needs to agree that the value estimation effort is off and fix it.
The real beauty of this approach, though, is that we no longer care how long a particular story/feature will take! (Caveat: this assumes that they are still broken down into reasonably-sized items of work so as to be well-defined.) If all of a project’s stakeholders are aligned on which item is the most valuable, then whether that item takes an hour, a day, or a whole sprint to complete is irrelevant. Time is no longer the target measurement.
Additionally, an “unbounded” scale allows flexibility for a team to easily update their collective understanding of value. If priorities change and a new story becomes the “most important,” just give it a higher estimate than any existing story. It’s okay to have some lower-value work items with the same value estimates. But, ideally the most important stories in the backlog all have unique estimates.
Alternatives to Estimating Time
I also mentioned in the beginning of the previous post that attempting to estimate the “completion” of a project is a fool’s errand. This is due to two primary reasons:
- Software projects are never truly “complete.” There is always more to be done, technical debt to address, etc.
- When we practice Agile, we are constantly learning and adapting, and shifting the goalposts as we go. An accurate estimate today may be wildly off tomorrow.
There are obvious business implications making it desirable to estimate when a team might complete a project. Primarily, you need to know if the time-domain of completing the most important part of a project is greater than the available working budget or reasonable time to market (i.e., you can’t make the thing you need to make before it’s too late). These are usually big-picture questions to answer before a team really dives into a project, though. They’re not the kind of thing an agile team should worry about once work is underway.
If you do find yourself in need of estimating time, you might look to the #NoEstimates movement within agile, which has gained some traction in recent years. I’ll note that I’m advocating for estimation here, just a different kind, so I’m kind of #NoEstimates adjacent. This talk by Allen Holub is a great place to start and provides compelling alternatives for making business time estimates without “estimating.”
At Atomic Object, we somewhat circumvent this issue in the way we structure our projects. One of our managing partners, Jeff Williams, does a much better job describing this Fixed-Budget, Scope-Controlled model better than I ever could. In essence, the project is “completed” when the budget runs out at a predictable point, and our teams aim to maximize the value delivered within that window.
That said, we still practice a version of Scrum on most of our client projects and provide measures like velocity and burn-down charts. Maybe after reading this post, you could hire us and ask your team to estimate value instead!
The Case for Estimating Value
Hopefully, by this point I’ve made a compelling case for replacing effort/time estimates of work items with value estimates on your agile team. If you’re still not convinced, I’d love to hear why!
Read the complete series:
Rethinking Agile, Part 1 – Deload Periods
Rethinking Agile, Part 2 – The Stand Down Meeting
Rethinking Agile, Part 3: Stop Estimating Effort