That was the important bit!
Destructive and non-destructive estimates
@meelijane
About me
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
Idealistic:
Really hard:
Customer collaboration over contract negotiation
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Hard:
Important:
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