What we need to know and do for planning…

originally by Michael Mahlberg on agile-aspects
What we need to know and do for planning…

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.

What you need to know 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?”

1. 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)
2. Make sure to know about the dependencies between the work
   items.
3. 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.
4. Apply confidence intervals (e.g. based on Liz Keogh’s aforementioned
   scale) to those forecasts.
5. 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.
6. 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)
7. 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

---

from agile aspects https://ift.tt/i9NyZMO
via IFTTT