Don't estimate - forecast

Don’t estimate – forecast!
Martin Aspeli, Head of Engineering, Deloitte Digital
F E B R U A R Y 2 0 , 2 0 1 8

Hofstadter’s Law: It
always takes longer than
you expect, even when you
take into account
Hofstadter’s Law.
T H E T R O U B L E W I T H E S T I M A T I O N

3 | Copyright © 2017 Deloitte Development LLC. All rights reserved.
Work time vs.
wait time
In software development, time spent in
queues (waiting for available capacity,
decisions, dependencies, etc.) tends to
dwarf the time spent doing actual work.
Estimating work time to a meaningful
degree of accuracy may be possible in
stable domains. Estimating wait time a
priori is virtually impossible.
Cognitive biases lead us to over-estimate
our own ability to estimate.

Your process is an assembly line
… and it can be measured

Define the
commitment
and delivery
points
• The clock starts when we commit
(“Next”) and stops when we deliver
(“Done”). The elapsed time between
these two points is known as the cycle
time.
• The number of work items in-between
these states (including “Next”, but not
“Done”) is the WIP.
• The arrival rate is the rate at which
items arrive into “Next”, and the
throughput is the rate at which items
are completed (moved into “Done”).

Conservation of
Flow is a pre-
requisite for
predictability
It is not possible to forecast the work of an
unstable delivery system.
We need to commit to starting work at
roughly the same rate that we complete it,
and we need to ensure that every item
that is started is eventually completed.
Each time we violate these rules, we
sacrifice predictability. WIP-limited Kanban
systems are a good way to improve
conservation of flow.

Use a CFD to understand flow health
The Cumulative Flow Diagram shows changes in WIP, approximate average cycle time, and delivery rate over time. Look for bulges
(increases in WIP) and flat lines (nothing completed).

Measure end-to-end cycle time
A Cycle Time Scatter Plot shows the number of days required to deliver each work item. The X axis is the date of completion.
Percentile lines show the performance trend. Use these to define SLAs for completion of a single work item.

All the risk is in
the tail
Most delivery projects have a distribution
of cycle times that looks something like
this. The longer the tail, the less
predictable we are.

The tail is
caused by
queues…
… and queues are caused by over-
utilisation of capacity.
Slack capacity reduces queues, which in
turn reduces cycle time, which in turn
reduces cost of delay (and makes us more
responsive)

To forecast
using data, use
Monte Carlo
simulations
If we believe the shape of the Cycle Time
distribution in the recent past is a
reasonable guide to the future, we can
use Monte Carlo techniques to simulate
the future. This will give us a range of
plausible outcomes, which we can feed
into our planning.
We need tools to do this, but the
algorithm is quite easy to understand.

Without data,
we can use a
parametric
model
If we don’t have data or don’t believe the
data we have is applicable, we can make
assumptions about things like the size of
the backlog, the rate of throughput, etc.
We should do this using ranges, not
absolute numbers, and again use Monte
Carlo simulations to forecast a range of
plausible outcomes at different levels of
confidence.
Choosing data and interpreting forecasts
is an art and a science!

Read these
And see:
• Actionable Agile: http://actionableagile.com (tools for working with data from JIRA and similar systems)
• Focused Objective: https://github.com/FocusedObjective/FocusedObjective.Resources (open source Excel based tools)

This publication contains general information only, and none of the member
firms of Deloitte Touche Tohmatsu Limited, its member firms, or their related
entities (collective, the “Deloitte Network”) is, by means of this publication,
rendering professional advice or services. Before making any decision or taking
any action that may affect your business, you should consult a qualified
professional adviser. No entity in the Deloitte Network shall be responsible for
any loss whatsoever sustained by any person who relies on this publication.
As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary
of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description
of the legal structure of Deloitte USA LLP, Deloitte LLP and their respective
subsidiaries. Certain services may not be available to attest clients under
the rules and regulations of public accounting.
Copyright © 2017 Deloitte Development LLC.
All rights reserved. Member of Deloitte Touche Tohmatsu Limited
Thank you.
Martin Aspeli
Head of Engineering
Contact: maraspeli@deloitte.co.uk

Don't estimate - forecast

More Related Content

What's hot

Similar to Don't estimate - forecast

Recently uploaded

Don't estimate - forecast