That was the important bit!

Destructive and non-destructive estimates

@meelijane

About me

Estimate Work

estimate-work.com

Budget and project planning tool

Why use estimates at all?

Agile

Waterfall

vs

"Wagile"

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Responding to change over following a plan

Idealistic:

Really hard:

Customer collaboration over contract negotiation

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Hard:

Important:

Responding to change over following a plan

Customer collaboration over contract negotiation

Agile estimation techniques

• Relative
• Collaborative

In reality, sometimes:

• Chaotic requirements
  ("small" change = much more effort)
• Uncertainty that has consequences
• External factors that add new pressures e.g. reporting, deadlines, winning contracts

"Estimation is neither good or bad. If you can work
effectively without estimation, then go ahead and
do without it.

If you think you need some estimates, then make sure you understand their role in decision making. If they are going to affect significant decisions then go ahead and make the best estimates you can.

Above all be wary of anyone who tells you they are always needed, or never needed. Any arguments about use of estimation always defer to the agile principle that
you should decide what are the right techniques for
your particular context."

- Martin Fowler, How do you estimate on an Agile project?

Estimation is valuable when it helps you make a significant decision."

What do we mean by "destructive estimates"?

What's actually being destroyed here? Information

The less destructive an estimate is the more relevant information we have access to when making decisions.

Generally speaking, less destructive estimates also handle the inclusion of new information better as well.

"Destroyed" might just mean "missing"

Totally avoiding all planning is pretty destructive

vs

There is a link between the hard decisions a team has to make and the  information content of their favourite estimation techniques

Our theory:

Collecting, maintaining and analysing information is expensive and time consuming.

This is one of the motivations behind #NoEstimates.

Hopefully you have some software that can help!

We should use the simplest technique that gives us access to just enough of the right information to make a reasonable decision

There is no "best method", so stay agile in your approach!

"Destructive" and "non-destructive" is a spectrum 

All estimation methods can feel like "a lot for a little" or "a little for a lot", depending on whether the information provided addresses current problems.

Don't try to produce estimates if there are no clear decisions to be made.

Use the technique that provides the right information for the current decision with the least overhead.

Destructive

Non-destructive

One single number

Magic documentation of every possible permutation and every possible risk

Story points

Statistical analysis

Risk registries

Gantt charts

T-shirt sizes

Big/Uncertain/Small

Roadmaps

Results from a spike

Trend data

More consequences

Fewer consequences

3-point estimates

A single "padded" number

No context

Implied context

Qualitative risk

Quantitative risk

Story points

Somewhat destructive - relies heavily on context and precedents to interpret values

What decisions are being made?

Do we need to do a research spike?

Is this enough work for the team for a period of time?

Do we need more resources?

How might we approach this work?

What information do we get to help make these decisions?

Distilled version of shared team knowledge

The estimation process itself gets people thinking about how to do tasks, even if the numbers are rubbish

Large and uncertain tasks can be flagged early for spikes/triage

Each task is relatively quick to estimate, so the team can produce a lot of information in bulk

What information is missing?

Units of measurement and other explicit context that stakeholders outside of the Agile team understand

Assessment of risks outside of tasks

Dates

When is it less appropriate?

When communicating with stakeholders outside of the Agile team (because of tacit context)

Deciding fixed dollar-value costs for a project

Setting deadlines for delivery

Quantitative analysis of risk

Story counts (trends)

Non-destructive - statistical forecasting (Monte Carlo, etc.) based on all available real data.

#NoEstimates for individual stories.

What decisions are being made?

(No longer dealing with individual tasks)

What resources do we need?

How can we co-ordinate our agile teams?

How can we make high-level improvements?

How can we plan time-boxed activities?

What information do we get to help make these decisions?

Automated charts if you are using tools that support it

Long term trends that are as accurate as story points anyway

Presented as data that can be subjected to quantitative analysis (maybe via an API)

Charts and predictions that people outside the team can understand

What information is missing?

All information about individual tasks

Triage or research opportunities

How might we approach the work?

When is it less appropriate?

If there's a lot of uncertainty in upcoming work or variability in the data

When you don't have much data yet

Identifying individual tasks that might need triage

If team members are changing, not as portable between teams

If the team relies on having an estimation process to break down and think through tasks before they start

Waterfall projects or tenders

Gantt charts/CPM

Semi destructive, because we only see one possible sequence/timeline when in reality there are many

What decisions are being made?

How can we co-ordinate non-agile teams, potentially across multiple departments?

Can we make high-fidelity resourcing decisions?

How can we hit a specific deadline?

What do we need to do to meet dependencies between tasks?

What information do we get to help make these decisions?

Key dates

Concurrent vs. serial tasks

Highlights dependencies between tasks

Can incorporate resource management

Very visual, based on calendars

Addresses a broad range of common external stakeholder questions

What information is missing?

Priorities

Impact of uncertainty in tasks

Team velocity data

Other possible timelines

When is it less appropriate?

When there is a lot of uncertainty in tasks, making many alternate timelines likely

Very time consuming to constantly re-do

Not that helpful in correlating blow-out of individual tasks to overall project dates

Overkill for simple projects

Mega spreadsheet

Very non-destructive but suffering from information overload

What decisions are being made?

All decisions

What gender your child will be

What animal you will be reincarnated as

Destructive

estimates

Benefits

• Good for reporting to stakeholders
• Easy to understand
• Simple to create
• Usually no advanced techniques or software required
• Can get a project moving quickly
• The right choice a lot of the time

Drawbacks

• Can't handle significant uncertainty
• Can't accomodate new information
• Can't handle scope change very well
• Lose all the context of the original estimate
• Can invoke Parkinson's law
• Dangerously easy to game/exploit, drift
• Short expiry dates

Non-destructive estimates

Benefits

• More information and context is available
• Appropriate for more complicated/serious decision making
• Allows you to see the bigger picture
• May cover different types of information simultaneously
• Easier to adjust if new information comes in
• Can spit out values for different scenarios if need be (e.g. "most likely", "worst case")

Drawbacks

• Information overload
• Usually relies on some specific techniques or software to help deal with the large amount of information and create summary reports
• Producing, analysing and maintaining the extra information can be expensive
• Can be harder for people to grok or require extra training
• Less decentralised within the team, relies on project management skills to produce effectively

Estimation is valuable when it helps you make a significant decision."

What you can do

• Think about whether/how you are estimating work right now
• Think about what decisions your estimates are used for, and what information you might lose when you do them
• Research other techniques along the Spectrum of Destructiveness
• Experiment with changing up your process to something that suits you better
• Iterate!

Thanks

@meelijane

estimate-work.com