The Effect of Time on Value in Your Agile Projects

[article]
Summary:

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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.