First of all, to realise “business value” you need to make a complete coherent release. Sometimes called a Minimal Marketable Feature (MMF). This release must be actually useful and beneficial to the business, otherwise there’s probably no reason to release it. (Or build it in the first place.) Identifying coherent, internally consistent releases like this isn’t always easy, and a good business analyst is invaluable in the process.

So from a business point of view, it’s not stories that they’ll be prioritising but releases. Stories aren’t worth a dime if they’re not released. So figuring out stories that are on average 2 days each, while an estimation exercise in itself, probably isn’t worth that much to you, or more specifically, to the business.

Now that we realise that it’s releases that are important, not stories, we want to start prioritising releases. To prioritise a release, we need to figure out the cost/benefit ratio. How much value is this release going to generate vs. how much is it going to cost. Ah, you say, that involves estimation, right? Exactly!

But we’re not just estimating the _cost_ of a release, we’re also estimating the _benefit_ of a release. And there’s little point in getting highly accurate cost estimates if we’re not going to get highly accurate value estimates, we need to be able to compare like for like. Which is partly why _cost_ estimates are often seen as waste, because their accuracy almost always rivals the accuracy of _value_ estimates. When that’s true, cost estimates _are_ waste!

With both sides of the equation, we start to think in terms of acceptable ranges of risk. A cost/benefit ratio of 1/5 is excellent, it’s a no-brainer, just get on with it. A cost/benefit ratio of 1/2 is much less excellent, and because estimates aren’t always accurate it could turn out to be 1/1.5, or even 1/1, or worse. Either you de-prioritise it, or see if you can get more accurate estimates before you commit.

Now we’re seeing why and where estimation accuracy might be important: high benefit ratios probably don’t require high accuracy, because even if you’re way out you’re probably still going to make money. Low benefit ratios either require more accurate estimates, or you probably shouldn’t bother at all.

About the other points you raised – you’re probably right – it is definitely very difficult to do this kind of a thing in “large” organizations. Or at least those that haven’t started thinking about inherent waste in software development methods, how to eliminate it, and about throughput and how to maximize it. There are other ways to deal with “dates” and “communication with upper management”. You just have find creative solutions to these problems.

One team I know did something quite cool – they got a budget approved from management for a new product (using a visioning exercise and supporting market research). The management trusted them to build/release it right – so they just ran with the program – releasing internally, and building up sales/marketing based on these preview releases. They adjusted realtime, and things went unbelievably smoothly. Sure, they had to cut back on the original vision because it was way too much to build given the time/budget constraints… but they didn’t need to nail things down before starting… What they did was make decisions based on the super-fast iterations (2-3 times a week sometimes) and show-casing the preview product to prospective customers, and stake-holders.

And this was in a big (fortune 500) company.

I personally think the foundational statement is the problem.

“If you do enough root-cause analysis, the only thing that can ultimately ensure this is raw speed. Hence, the only metric that matters is cycle-time and organizations must always try to reduce it.”

Raw speed is not the measure we should be using. The real measure is whether optimal business value is delivered through optimal attention to customer need and preference. Quality is a huge part of that. Yes, speed for an organization is important in terms of time to market, first to market, etc, however that’s not the whole story. Also if speed is the actual measure, then we can toss out all sorts of engineering rigor and just get crap (and I mean crap) out the door – which clearly, no one is advocating.

You are right about having small bite sized pieces (small stories) that are easier to manage, but estimating is what tells you what is small and what is not. Estimating allows an organization to make plans, allows teams to manage their throughput, allows for growth goals, allows for comparisons over time to see improvement in efficiency, and so much more.

Another problem with not estimating is, while that might work better for a tiny company and a small project, would a large company be able to do this? Are they going to be able to give to upper management the numbers they need to make decisions (especially in a non-agile world?). Agile can give those numbers, but estimating is an engineering practice that remains necessary regardless of the project management process you’re using.

Estimating allows you to think through the process and then gives you a measure with which to compare future work. Knowing what you can do and where you can go is part of the core of management. The good takeaway for me was the highlighting of small stories being more optimal than large ones, and for challenging us to think about what we do, allow ourselves to be uncomfortable, and then make choices instead of letting them get made on autopilot.

The team need to find the quickest and most efficient way to deliver the maximum benefit in the shortest time (which with a good project might have some real business-benefit analytics to clarify team-wide goals).

Good to have some measures so development teams can collaborate and compete, but the measures are a tool not a goal in themselves. They let great teams seek out even better ones to compete with!

Anyway – I wanted to respond to your flame-bait. Estimation is not ‘killing’ anyone, in the same way that in the old days of waterfall, documentation never *killed* anyone. That doesn’t make either of them a value-addition to the process of software development. When you have a bunch of average to below-average developers (or some other equally terrible constraint), maybe documentation *is* the right thing to do. Who knows?

What I do know for sure is that given a high-performing team, and a short-iterative process – *explicit* estimation is waste. The whole reason you estimate is that you want to try and deliver *exactly* what you sign up for in the period of time you chose as your iteration length. This is the whole in-search-of-perfect-estimates thing. However, what if you over-estimated, and finished early? Wouldn’t you try to take on more and thus deliver more? What if you under-estimated? You’d have to cut scope. So why this silly pursuit of ‘perfect’ estimates? Clearly, the product here is the working software – none of the other things matter. (Or are your developers being rated on their “estimation” skills? *shudder*)

The idea of getting all your stories down to 2-3 days in size serves several purposes – a) it eliminates the need for *explicit* estimation and lets your team be more productive by just focusing on the only thing your customers care about (the actual software), and b) it helps stakeholders and managers keep an eye on the progress, while giving them the opportunity to provide feedback – early and often, and c) homogeneous stories like this provide an automatically averaged velocity that can be used as a *reality* based prediction tool.

Who should do the job of breaking large size features into these manageable chunks? I don’t know – the answer depends the people on your team, their level of skill, and their depth of domain knowledge. If the project-manager (or scrum-master) can’t do this job, then they should obviously ensure that there is enough skill-set on the team for this to happen properly.

Hope this helps!

My real question, if nothing else, is why avoid estimation? Is it killing you to estimate?

I’m curious if you have a full understanding of story points and their benefits. Please take a refresher before you hurt someone .