“Without planning we would fall right back to being hunters and gatherers again”
-- someone on the internet
The gist of it (aka TL;DR):
- Separate sizing and planning – different circumstances lead to different times to completion, even for equal sized work items,
- replace estimation by analysis and forecasting,
- apply confidence intervals according to your familiarity with the problem class. And
- communicate the whole probability distribution whenever possible.
A minimum setup for planning?
While I’m a big fan of many of the “no estimates” ideas and the whole “beyond budgeting” movement, I think we still need to make planning better for those instances where we can’t avoid it.
When we talk to people outside of product development and project work, estimation and planning are very normal. Questions like “What do we plan for dinner?” or “What are the plans for the party?” show that planning is a normal thing for many, if not most, people.
There are many situations where we need to do planning and “estimation” outside of project and product work. After all, it was planning and estimation that enabled us to become settlers instead of hunters and gatherers several milenia ago.
The important thing is to un-mix the two concepts. And maybe also extract a third component called “co-ordination.”
Planning and estimation in the physical world
When we ask someone “When will it be done?” we implicitly ask a number of questions, with different contexts, like: * With regard to the understanding of the problem? (to gauge it’s actual size) * How much work has to be done for this? (How many square meters of wall have to be painted? How much scaffolding has to be built for this? Etc) * How much experience do you have with this kind of work? (Have you ever held a paintbrush? Have you used this kind of paint on this kind of surface before?) * With regard to the understanding of the problem? (this time, to gauge it’s feasibility) * What other problems have to be solved, first? (Do I have to move my furniture into a U-Haul for the time of the renovation?) * Can these problems be solved directly, or do they, in turn, have any prerequisites? (Do I need to have a drivers license to rent a U-Haul?) * With regard to the execution of the solution * How many people will do the work? Can the work be parallelized? * Who will actually perform which work? How experienced are they? (How long does it take them to paint one square meter, how long does it take them to build one running meter of scaffolding?) * With regard to external aspects * What other work has to be finished at certain times? (e.g. outdoor work during dry weather that has to be done first) * What other activities depend on this task? (How long will I have to live in the motel and leave my stuff in a U-Haul before I can move back in?)
Planning and estimation in the project world
When we go through these questions, we can infer some activities for planning in the product / project world (and in the world of so-called agile software development) as well.
Separating size and certainty
When we separate the question of the amount of wall surface to be painted from the question of experience in painting walls, we also separate the question of “size” and the question of “certainty.”
Being aware of the (un-)certainty enables us to better asses how much accuracy will be in our plans and adjust for it accordingly.
Using Liz Keogh’s model of complexity for example, we could agree that for all activities categorized as 3 (Someone in the world did this, but not in our organization (and probably at a competitor)) we will assume that it might take anything between half as much effort as we think now or twice as much.
For an item categorized as a 1 (We all know how to do this [and did it several times before]) that range might –just as an example– be from 0.8 to 1.2.
Of course, you have to finde the right factors for uncertainty for each level on the scale according to your local situation. ## Separating size and effort As even Mike Cohn wrote: estimation is about effort and knowing the “size” of an item does not automatically give us the effort necessary to complete that item. (Using white-out to “paint” the wall will result in a different amount of work than using a spray gun)
Separating effort and duration
Here’s the thing about ‘estimation’ and duration: even if we knew the effort that is required, we still can’t know the time it will take from start to finish.
Let’s look at a different analogy here, specifically with regards to relative estimation.
If you ask two people -one who drives a sports car and another one who drives a truck– how long it would take them to drive from Munich to Berlin (about 600 km) relative to the time it takes them to drive from Munich to Karlsruhe (about 300 km) they would probably both answer the same: “Twice as long.”
In this example relative sizing enables people with different backgrounds to still have meaningful conversations about effort, without even needing to know the absolute estimation of one another.
Still, when executing, the person driving the sports car would probably deliver a package to Berlin in less time than it would take the one driving the truck to get to Karlsruhe. (Hint: Trucks are limited to 80 km/h in Germany and there are –unfortunately– still large parts of the highway system in Germany without speed limit so the sports car could leverage its top speed from time to time).
What this example also shows, is that it is important to keep in mind that the actual time it takes to complete an item can very much depend on the current capabilities of the people working on it.
Managing prerequisites and dependencies
Even in the world of agile software development, it is necessary to understand prerequisites and dependencies.
That does not mean that we need Gantt charts or PERT-diagrams with detailed timelines month and years into the future. The well researched cone of uncertainty has shown that these would be useless in a matter of weeks anyway. To me the frustration with the misuse of techniques like Gant charts and PERT diagrams that seems to be one of the drivers of the whole “no estimate” movement.
But using the basic ideas of PERT for example –actively modeling which activity is dependent upon which other activity and which activities can be tackled independently– is still quite helpful. Just mapping out –and agreeing upon– which hard dependencies exist on the next lower level of abstraction makes a huge difference when it comes to succeeding with most real-life multi-step ventures.
Putting it all together: a model for sizing and planning
From my experience, every explanation about how to do planning and sizing right has to be wrong on some level, but maybe some [of the ideas] are useful nonetheless.
A flawed, but sometimes helpful, workflow for the question “When will it be done?”
- Cut it down to to chunks reasonably well understood size (analyze,
don’t estimate). Some ideas for that could be:
- using the sizes NFC, 1, and TFB as explained by Pawel Brodzinski instead of t-shirt sizes or other arbitrary numbers
- using equivalent items from the past is also quite helpful (selecting a couple of reference items, or at least one for each size, to compare future work items with)
- Make sure to know about the dependencies between the work items.
- Use historical data (e.g. lead time distributions separated per reference item class) to forecast durations. (The closer you get to actually working on the elements the more important it is to use not any historical data, but data from the team (or other subpart of the organization) that will do the work.
- Apply confidence intervals (e.g. based on Liz Keogh’s aforementioned scale) to those forecasts.
- Apply risk management heuristics (e.g. from “Waltzing with Bears” and maybe, but not necessarily using the Riskology spreadsheet) to the result of the previous steps.
- Communicate the result as a probability distribution, or at the very
least as a range, not as a single number.
- If you don’t use the whole distribution try to communicate a date or duration that feels sufficiently safe, like the 80th percentile, and communicate the other ends of the distribution in relation to that point (e.g. “for 8 out of 10 items like this, it should take 21 days, but we might end up three days earlier or -in 2 out of 10 cases- it might take 25 days” - thus you avoid anchoring people on the nano-percent-probabillity of 18 days)
- If your endeavor consist of dependent items (and you can’t break the dependencies) consider using something like the PERT-approach without actual dates to plan parallel and sequential parts of the work.
Some people might argue that it would be possible to lump steps 3 to 5 together in just one so-called “Monte-Carlo simulation” as they come out-of-the box in many contemporary tools but there are drawbacks to this approach. (although Riskology also uses a Monte Carlo simulation under the hood),
On the other hand, the black box approach of many of the Monte-Carlo simulations that have been integrated into popular tools makes it very hard to really know what is being calculated, how things are weighted and so on.
Even so, just applying steps 1 through 4 already gives so much better forecasting and planning that, in my book, it is definitely worth the while.
till next time
Michael Mahlberg
Footer (ignore)
fieldstones
Estimation hast many dimensions: * complexity * effort
planning has other dimensions: * capability of the system (e.g. company or team) * relative cost of not doing things * customer demand (e.g. due dates)
