Thread by @tastapod

[thread]

tl;dr:
1. Estimates are not necessarily waste.
2. Feature/story level estimation is almost always unnecessary.
3. You’re probably doing estimation wrong anyway.

For 1 we’re going to need a brief intro to Throughput Accounting (don’t worry) and what is and isn’t waste.

https://twitter.com/RonJeffries/status/1021818544256888833

Throughput Accounting is dead simple. There are only three numbers:
- “Throughput” is how much money you make selling your product.
- “Inventory” is how much you spend on stuff you turn into Throughput.
- “Operating Expense” is how much you spend turning Inventory into Throughput

In this context Lean defines three types of work:
- “Value-adding work”, or just “Work”, is anything that turns Inventory into Throughput.
- “Kaizen” is anything you do to improve the system of work. More on that later.
- “Waste” is anything else: neither delivery nor improvement

Where was I? Oh right, kaizen. So we have Work, Kaizen and Waste. Kaizen is usually applied as a series of experiments, with a hypothesis, baseline, etc. This is an investment of effort, and in a genuine lean environment you "stop the line" to do this, so you want to be confident

This requires a degree of guesswork. We are going to expend X effort to hopefully achieve Y improvement. We will measure this using Z metric. If we only achieve fraction-of-Y improvement we can decide whether to double down or back off. In other words, kaizen requires estimates.

Ok, back to the Work. In lean production/manufacturing context, work means producing stuff. More stuff per unit time is better, ceteris paribus. But that's not the whole story. Lean methods also apply to product development. In product development we don't know the answers.

Which means Work is a mixture of Delivery (making stuff) and Discovery (figuring out which stuff). In cynefin terms, Delivery is cyn-complicated (has lots of detail), and Discovery is cyn-complex (has emergent properties). We /cannot know/ the answers in the complex domain.

So we have to guess. This guess takes the form of an investment for an anticipated return. Both of these are unknown, so we estimate. I usually suggest this estimate takes the form of a "qualified range estimate", a min-max range with an indication of why the range exists.

For instance: team X thinks it's 3-6 months. The range is because we don't know about:
- the domain
- the tech stack we will be using
- access to key SMEs
- an external dependency
- etc. in decreasing order of potential impact

This suggests a couple of things:

1. Work to reduce uncertainty is first class work. This gives us better data to make more informed decisions. Delivering in small slices to get feedback is one way to do this. Lean Startup folks call this the Build -> Measure -> Learn cycle, or "fire, aim, ready".

Talking to people and finding things out is another way to pay down some of this uncertainty. This is on the Investment side. Similar work should be going on on the Return side of the RoI function. If we discover this initiative isn't paying off after all we should pause & adjust

2. As the weeks progress (I suggest weekly tracking of these R and I figures, at least to start with when you are in high uncertainty) we can continually review the RoI proposition. In other words we are evaluating successive values of RoI based on (qualified) estimates of both.

Where traditional PMO/PMP practices fail IME is they don't look at the R side of this, and just obsess about the I side, so you get conversations like this: "You said it was going to cost $X, now you say it is going to cost $X+20%. You are a Bad Project Manager!" Rather than:

Last week we thought it would cost about $800k-$1m to make $10m savings. Now we think it will be $1m-$1.1m, so we are more confident (narrower range) that it will be a bit more expensive. We also think the $10m is looking more like $9m savings.

Should we continue? Of course!

The fun starts with /risk-adjusted/ return on investment (h/t @PapaChrisMatts). We factor in /when/ we make the return, and we claim that money now is more valuable than money later. So we might slice the delivery into small product increments that have a partial payoff sooner.

@PapaChrisMatts This is one of those crazy win-win-win situations. Doing smaller things:
- carries less risk
- requires less investment
- provides feedback sooner
- allows us to course-correct
- improves relationships with stakeholders

So you should do that.

@PapaChrisMatts but figuring out /what/ to do, where to spend that money in the face of multiple options, requires us to make investment decisions in uncertainty, about the time and cost of software development and the expected return. There's a word for this. This is called estimation.

Now, if you don't need to do this because:
- there is low uncertainty
- the work is deterministic
- you are comfortably in cyn-complicated (detailed) or cyn-obvious (simple) domains

then don't.

Any work you don't need to do is waste. This doesn't mean "estimation is waste".

That was point 1. Estimation isn't necessarily waste.

2. Any feature level estimation is unnecessary, or can easily be made unnecessary.

For forecasting/investment purposes you don't need anything finer grained than quarterly planning IME. For that I recommend Blink Estimation

Here: dannorth.net/2013/08/08/bli…

If your stories are wildly different in size, then
a) it probably doesn't matter (see e.g. tsta.pt/2GFCgv4), and b) you can slice stories by acceptance criteria to slim them down, AKA Acceptance Test-Driven Planning (same paper)

Also, @lunivore has some great material on making seemingly un-break-downable things smaller. such as lizkeogh.com/2013/09/05/cap…

@lunivore Finally, 3. You're probably doing it wrong anyway.

If you are doing anything more fine-grained than Blink Estimation / Wide-band Delphi, you may well be a victim of estimation theatre. I have a blog post in the pipes about how we are misusing methods like Monte Carlo simulation.

@lunivore I'll tack it onto the end of this thread when I post it. Ok, I think I'm done.

So, where you need to make decisions in uncertainty, you probably want some sense of expected time and cost to inform those decisions. We'll call those "estimates". Where you don't, you don't.

/end