how to not shoot yourself in the foot with estimation

How to not shoot yourself in the foot with estimation

neil_killickNeil Killick, 2017, All Rights Reserved


Business wants predictability…

+ Bang for buck + Responsiveness to change + Speed of delivery + High quality

Neil Killick, 2017, All Rights Reserved

Traditional…

• Build a plan up front • Keep changes to a minimum • Plenty of time for course

correction • Functional teams/estimation/

milestones • Project Manager steers

“Agile”…

• Cross-functional teams/estimation

• Little time for course correction • Unclear objectives • Unclear milestones • Frequent change • Frequent prioritisation

Potential to shoot yourself in the footFAIR HIGH

neil_killick


"Scrum employs an iterative, incremental approach to optimize predictability and control risk.”

~ The Scrum Guide


Incorporating feedback as we go

Not knowing exactly what we’re doing, in sequence, throughout the project

Welcoming change, making it easy, and incorporating it

Do these things make us unpredictable?

Empirical predictability

Understand how long we have to do what we need to do

Create/update the plan

Monitor progress through working software and other metrics and

observations


Deterministic predictability

Determine how long it will take to do what we need to do

Put the answer in a plan

Keep asking how long is left to deliver the plan

Stick to the plan


1 Become predictably good at delivering


Predictability is improved by behaving and delivering more predictably, not by making predictions


2 Be transparent — share your process and your progress

10

Empirical predictability

Working software every 2 weeks or so

Collaborative review with customers of where we’re at, and what we should do next — better than

“status reporting”

Mitigating risks and impediments by testing assumptions, managing/

reducing dependencies

Neil Killick, 2017, All Rights Reservedneil_killick


3 Find out what type of estimate is required


• What will we get, and when?

• Which is quicker/smaller, A or B? (for ROI purposes)

• When will we get X (feature)?

• How much will be done by Y (date)?

• Will X/everything be done by Y?

• Can we deliver X/everything for the time/money available?

• Are you going to deliver maximum bang for buck? Do you have a plan?

What are we actually estimating?


Sales What features can we sell to (potential) customers?

Marketing When can we start our campaign?

What features can we talk about at the next roadshow?

Project and program managers When will Jane/Team A become available for other projects?

When will we need Jane? (our shared UX specialist)


4 Incorporate appropriate levels of uncertainty


Part of estimate — call out risks/assumptions/issues/dependencies

• How stable is the team? Losing/gaining members? • Are all team members 100% committed to the project? • How predictable is the team’s throughput/velocity of

PLANNED work? • Is there a predictable level of UNPLANNED work? • What are our technical/schedule/people dependencies?


Don’t give a precise date when a set of scope will be delivered

Don’t say a precise set of scope will be delivered on a given date

— use confidence levels and shades of grey


5 Take into account poor/no prioritisation

— and agility


Remember - We are in a different paradigm


6 Estimate options for solving problems, not specific solutions


We control time rather than predict it in iterative development

• Minimum effort to solve problem, then iterate

• Iterative/incremental is a different paradigm

• Let’s discuss this, and align expectations


Problem We need to be able to contact dormant customers by email

Solution 1 (~6-8 weeks) Build an automated customer email system, integrated with MailChimp

Solution 2 (~2-3 days) Send manual email with no integration


7 Revisit estimates regularly and frequently


8 Estimate cycle times, not effort


9 Use data

(yesterday’s weather)


RELEASE 1 HIGH CONFIDENCE

LOW CONFID

ENCE

MAY 30th

MAR APR MAY JUN

THROUGHPUT FORECASTING INCORPORATING VARIANCE,

CONFIDENCE AND UNCERTAINTY

Milestone falls in our pessimistic forecast range, so we have fairly high confidence

neil_killick


RELEASE 1 (added scope)

HIGH CONFIDENCE

LOW CONFID

ENCE

MAR APR MAY JUN

MAY 30th

Milestone falls in our optimistic forecast range, so we have lower confidence - project needs steering to stay “on track”

neil_killick


RELEASE 1 HIGH CONFIDENCE

LOW CONFID

ENCE

MAY 1st (earlier date)

MAR APR MAY JUN

Milestone again falls in our optimistic forecast range, so we need steering to stay “on track”

neil_killick


RELEASE 1 (even more added scope)

HIGH CONFIDENCE

LOW CONFID

ENCE

MAR APR MAY JUN

MAY 30th

Milestone falls outside even our optimistic forecast range, so we need to reduce scope or push out date

neil_killick


Summary • Become empirically predictable — good at delivering, and know

when you plan/review/release • Be transparent — share your process and your progress • Know what type of estimate is needed • Incorporate uncertainty • Account for poor/no prioritisation — and agility • Estimate problems and options, not specific solutions • Revisit estimates regularly and frequently • Estimate cycle time, not effort • Use data (yesterday’s weather)


Thank you!

Any questions?

how to not shoot yourself in the foot with estimation

Technology