Diminishing Returns–A Key Agile Principle

Posted by Robert Merrill on February 6, 2009 under Agile Methods, Estimation | Read the First Comment

With just a little bit of effort, the uncertainty in a project estimate drops rapidly. But there comes a point where getting even a little bit more accuracy takes a lot more work (yellow line) and there's an absolute limit (red line) without actually doing the project.

With just a little bit of effort, the uncertainty in a project estimate drops rapidly. But there comes a point where getting even a little bit more accuracy takes a lot more work (yellow line) and there

“Real Agile teams don’t waste time on X.”

“You can’t deliver quality software without getting X right first.”

My favorite quote from fantasy writer and Christian apologist C. S. Lewis is this: “(The Devil) often sends errors into the world in pairs—pairs of opposites…He relies on your extra dislike of one to draw you gradually into the opposite one. But do not let us be fooled. We have to keep our eyes on the goal and go straight through between both errors.”

A key principle of Agile software development (and much else in business besides) is that of “diminishing returns.” At some point, extra effort in the same direction, even on generally worthwhile activity, is no longer worth it.

I most often find myself talking about diminishing returns when it comes to cost and schedule estimation. “Robert,” someone comes to me, “I have an idea for some software that’s going to save us a million bucks. How long would it take to build it?”

“Would you mind telling me a little bit about it first?”

Thirty seconds later, I can give a range–a huge range–but a range. “I think we’re talking somewhere between four weeks and four years.” (At my first programming job we had this rule—all initial estimates were FOUR. The only question was the unit of time. It kept us laughing, and kept things real).

“For an estimation expert, you’re a big help!” But we talk some more. A hour and a whiteboard full of words and sketches later, I can count logical files in my head and use a typical productivity factor (a Function Point trick) and say, “Well, I think we could have something pretty slick between six months and three years.”

“Six months is a no-brainer, but I’m not sure the business case works out if it would really take three years. What could we do in a year?” (Notice, I’ve been overly polite and not pressed him too hard about where he got the million dollar number either).

“Let’s do a little requirements workshop. We’ll need a couple of people who use the current system, their supervisors, and the VP of Operations. I’ll see if we can’t get the likely tech lead and project manager, if this were to go.” A week later, we have our half-day workshop and come out with a stack of user stories on index cards and a digital photo of a domain model—a logical data model—we constructed on a wall, using sticky notes. After a day of analyzing all that, I call my enthusiastic friend back and say, “Three to six quarters—nine to eighteen months—would get us all the essentials and well into the high-value stuff.”

“I need to know how much money to ask for. What else do you need to know about the requirements to tighten that up?”

“We’ve hit a point of diminishing returns,” I say. “It isn’t the requirements. It’s the third party software we’d need to integrate, and the data. (To learn more about sources of estimation errors, read Software Sanity: Accurate Estimates and Other Myths on WTN.) We won’t know much more until we try. But if you can get fifteen months funding–ask for eighteen–but if you can get fifteen months, we’ll be OK, because we’re running an agile method. Being able to re-prioritize features on the fly will let us get the maximum value possible out of whatever money we get, and a fifteen-month effort will get us something pretty good. I’m just not sure exactly what we’ll have to leave out.”

The principle of diminishing returns shows up everywhere—not just with estimation. It”s how you have to answer questions like, “How much up-front design should we do? What about data modeling? How much unit testing is enough?”

Often, the principle of diminishing returns tells you when you need to switch tools. In the estimation example, once we got down to a factor of two, I suggested that we put down the up-front estimation tool and pick up the iterative-delivery-against-prioritized-requirements tool to keep the business case above water in the face of that stubborn, residual estimation risk.

In a day or two, I’ll post another example of when and how to use the principle of diminishing returns to determine when to switch tools to achieve a desired level of design quality.

  • Putcha V. Narasimham said,

    I did not know that the principle of “diminishing returns” which I first learnt in introduction to economics and forgot (because it was not brought up in science and engineering which I continued to study / apply)is useful in science, engineering and business.

    It is still not clear (to me) how one can use it in real-life projects to get consistent results (which is the problem with Agile principles and methods). It seems something more than principles is at work to assure success which only a few intuitive experts somehow know and can pull off. So, it is NOT engineering. That is, the learning of methods and tools do not enable an average but qualified learner to apply them and get expected results within given tolerance.

    Till then these principles are good to know but not good enough to use by an average professional for predictable outcome.

    Puzzled skeptic of hyped-up principles and methods
    21 MAR 14

Add A Comment