Using effort estimates as the only criteria for deciding whether work is undertaken could be leaving money on the table. Considering value—in particular, the effect of time on value, as in whether there is a cost of delay—makes for more intelligent conversations and better decisions.
A few years back I spoke with the head of business analysis in a division of a major US bank. “I don’t want BAs doing any analysis until the system architects have suggested a solution,” he said.
“But how do the architects know what is wanted?” I asked.
“Oh, they have a general idea from the requests,” he replied, “but I don’t have enough people to review every request; there are too many. If the architects look first, we can drop those that aren’t doable or take too long. Then after they put effort estimates against them, the project managers will rule some out so there is less work for my people.”
Naturally, the architects told me the same thing in reverse. Each side was attempting to limit its workload by making the other side take on the larger task. If every business worked this way, nothing would ever get done.
It’s important to attach business benefit—preferably a quantifiable value—to user stories, and I’ve made some suggestions on how you might go about doing this. Now, I want to turn our attention to how time affects our view of value.
Value before Estimates
Too often companies assign effort estimates to work before they ever consider value. (Unfortunately, many organizations never assign value to user stories at all.) Perhaps because effort estimates are relatively easy—“Just ask the developers”—it is common to find that effort estimates are the only criteria for deciding whether work is undertaken. Value takes a back seat because there is a constant demand for “quick wins” and getting the biggest bang for your buck.
Placing only effort estimates on stories means story selection is usually based of minimum effort, or what fits within the time or budget remaining. Without understanding value, that “biggest bang” might not end up being so lucrative after all.
Things get really factious when developers point out how difficult it is to come up with a realistic estimate. Even in the absence of value estimates, business representatives are quick to say, “But how can we do cost benefit analysis without the cost?” The bottom line is you can only do cost-benefit analysis if you have estimate for both the cost and the benefit.
Even if you do consider both factors for analysis, I have observed that those who make work requests always attribute a benefit to their work requests that is greater than the cost. The problem is, making effort estimates before value estimates creates an anchor; if a business representative knows a story will take ten days to complete, then they will—consciously or subconsciously—place a value on the story that is greater than the cost of ten days of work.
An assessment of value needs to precede effort estimation. Adding value first allows benefit to become an engineering constraint; estimating value second means it will be anchored in the effort estimate.
Engineer within Constraints
When benefit analysis happens before technical design and effort estimates, the expected benefit forms a constraint for the proposed work. Engineers can apply their skills and knowledge to suggest solutions proportionate to the expected benefit.
Imagine a potential customer walks into your software engineering shop and says, “I want to set up an online store to sell the widgets I make. I believe I can turn over ten million dollars a year within three years and make a profit of at least a million dollars by year four.”
Think of the solution you might suggest. Next, imagine another customer walks in and says, “I want to set up an online store to sell the widgets I make. I believe I can turn over one hundred thousand dollars a year within three years and make a small profit in year four. I hope to give up my day job eventually.”
These are very different problems to an engineer. The expected benefit is a constraint on the proposed solution.
The Cost of Delay
Having a quantifiable benefit allows us to consider the cost of delay—the change in value of delivering a solution later. Features and deadlines are normally presented as binary: “Feature x must be complete by December 1.” However, using value relative to time changes the request and adds context: “Delivering x by November 1 is worth some money; by December 1, a lot of money; and after January 1, no money.”
While some stories do indeed become worthless when delivered late, such as delivering a Santa Claus app on January 1, others do not. Indeed, there is probably little difference in value between a Santa Claus app being delivered on September 1 versus on October 1. Delivery on November 1 probably represents some lost value, but value falls faster with every passing day, as you can see in figure 1.
Attaching value to a story allows teams to discuss how that value might change over time. Adding that time dimension to value-based priotization leads to some interesting results. For instance, imagine you have a high-value item with a low cost of delay and a low-value item with a high cost of delay. In this case, it makes sense to do the low-value item first because the value of the more valuable higher story will remain unchanged over time, while the lower-value item has a shorter shelf life. Completing the low-value item first allows you to maximize your value by getting both items done at their peak values.
Imagine your team is also developing a Halloween app at the same time as the Santa app. Figure 2 shows the value against time for this app.
Developing the Santa Claus app first makes it likely that all the value of the Halloween app will get lost. To maximize value overall, it makes sense to develop and release the Halloween app first, before starting work on the Santa Claus app.
The value from the Halloween app more than makes up for delivering the Santa Claus app a little later. But delivering either app too late destroys all value. If risk is the key driver, the team should not even attempt the Halloween app.
Obviously, one must know both value and how it changes over time to undertake such analysis. Don’t be intimidated—perfect numbers aren’t essential; estimates of the value are good enough.
Time, Value, and Risk
Managing software work through effort alone is easy: Get a budget, do some estimates, and work to keep to both. But considering only these two factors can leave money on the table. Managing through value is a game-changer, even if it is more difficult and requires more skill.
When you manage through costs alone, it is difficult to win arguments. There is always someone somewhere who will offer a lower price. But considering value—in particular, the effect of time on value—makes for more intelligent conversations and better decisions.
