(2019-08-20) Jeffries Some Thoughts On Estimation

Ron Jeffries: Some Thoughts on Estimation. Many people object to the tag #noEstimates. I both agree and disagree

In the noE discussions, things go better when we’re careful what kinds of estimates we’re talking about

Abuses

“Negotiating” From Power

While it may be true that a little pressure helps, I have my doubts, and there’s no doubt at all that rushed software doesn’t work well, isn’t very maintainable, and is usually later than it would have been had it not been rushed.

Estimates Become Promises (Commitment)

Abuse is Common

The “no estimates” idea is simplistic but simple, while “better estimates” is also simplistic but quite complex, wearing a more “businesslike” outfit.

Waste

Unless you are in the business of producing estimates, estimates are clearly waste. As such, they should be minimized, made as inexpensive as possible, and eliminated where possible.

I think the strict “no estimates’ people are saying that the odds are good that we can meet the needs without (bothersome) estimation, and using their stance to trigger the exploration of the real needs and finding better ways to meet them.

Systemic Problems

The problems of abuse and waste are systemic: the system needs improvement. We could argue very strongly that we should fix the systems problems, improving how we create estimates, how we use them, training our people, including managers to use them well, and so on.

Exactly right, but a very big problem, especially from the viewpoint of a development team at the bottom of a corporate hierarchy. “You’re using these estimates as weapons, let us show you how to use estimates well” probably isn’t going to gain much traction a few levels up the hierarchy.

Management Requires Estimates

What is management going to do with the estimates provided? There are plenty of possibilities, some pretty sensible and some less so. I’ll start with one that is less so.

Recently a colleague reported that a “Sprint Commander” in their organization had asked a team to schedule 20 story points per Sprint rather than 16, so that they’d be like all the other teams, who were scheduling 20.

I’d also bet the Sprint Commander is showing actuals as well as estimates on that graph, and that, my friends, is pretty much guaranteed to be bad.

Notice the slippery slope here. Management wants a graph. Sprint Commander makes it pretty, management uses it to micromanage without really understanding what’s going on.

My guess is that they want to know things like this:

• How well are things going?
• Are we on track to meet my OKRs?
• Will we avoid contract penalties?
• Will the customer get what we promised?()
• Is it time to whip the ponies harder?

It should be clear that while estimates and actuals might be part of answering those questions, they do not serve as the answers to any of them

I believe, and the noE proponents believe, that estimates, even really good ones, are not always the right information. I’d argue that they are rarely the right information.

the time box forces the work to be sliced into smaller pieces. And size does matter: smaller is better.

“Just Count Small Stories”.

As story size gets smaller, the size becomes more consistent. If you never take on anything that seems longer than a day’s work, you’ll soon hit a pretty decent average of 3/4 of a day per story or something like that.

Even better, quite often when you spit a big story, you find some parts of it that you do need right away, but other parts that you can defer until later, perhaps even as an after-release enhancement.

When Agile teams, with their Product Owners, get in the habit of splitting stories and deferring the more frilly bits, they begin to get creative.

Do these ideas scale? Do they apply at the corporate level, the state level, the national level? I’m not here to say. I am here to say that one might do well not to get hung up on the name, instead looking at whatever estimation one does (or recommends) and consider whether there are better forms of information to ask for, and better ways of providing it.