Estimate or Guesstimate? | Richard Herbert

Introductions
Why estimate?
How to estimate
Alternatives

Hands up …

If you have an appreciation of Agile?
Who follows the practices of Scrum?
Who has to provide estimates?
Who knows quantum mechanics theory?

Richard Herbert MSc CSM - [email protected]
Originally started in architecture and engineering
Got into computing via structural analysis
Moved into IT management
Been a freelance web developer since 2001
MSc Internet Systems Development
Certified Scrum Master since 2014
Available for weddings, christenings, Bar Mitzvahs and other Agile opportunities

I need all these features but…
How long will it take?
How many developers do I need?
How much will it cost?
Can I change my mind?

It's easy to estimate something that's well known, constrained and predictable
Increases in variability, interpretation and understanding causes doubt
Where there is doubt, there is delay
Where there is delay, there is cost

Naming things (49%)
Explaining what I do (16%)
Estimating time to complete tasks (10%)
The challenge:
- guessing how long something, that you possibly haven’t done before, will take
- making estimates based on vague requirements
- trying to allot time for dealing with unforeseen problems

“In preparing for battle I have always found that plans are useless, but planning is indispensable”

…or…

“Plans are worthless, but planning is everything”

Goals or Epics
Features or Activities of each Goal
Tasks or outline Stories that form each Feature
Group Tasks into Releases

Short and to the point
Limited to an index card
Promise of a further conversation
Includes acceptance criteria
Estimated with Story Points

A promise of a further conversation

I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story
N	Negotiable	User stories, up until they are part of an iteration, can always be changed and rewritten
V	Valuable	A user story must deliver value to the end user
E	Estimable	You must always be able to estimate the size of a user story
S	Small	User stories should not be so big as to become impossible to plan/task/prioritise with a level of certainty
T	Testable	The user story or its related description must provide the necessary information to make test development possible

A polite word for a guess
Improves with experience
Cone of uncertainty

"The exact number of candies in this jar can not be determined by looking at it, because most of the candies are not visible. The amount can be estimated by presuming that the portion of the jar that cannot be seen contains an amount equivalent to the amount contained in the same volume for the portion that can be seen" http://en.wikipedia.org/wiki/Estimation

Linguist Geoffrey Pullum stated the quotation was "completely straightforward" and "impeccable, syntactically, semantically, logically, and rhetorically. There is nothing baffling about its language at all."
http://itre.cis.upenn.edu/~myl/languagelog/archives/000182.html

Not time but effort based sizing
Tee-shirt sizing (small, medium, large, x-large)
Trouser sizing (short, regular, long, x-long)
Dogs (Chihuahua, Greyhound, St Bernard, Great Dane)
Story Points
- Relative sizing (1, 2, 3, 5, 8, 13, 21, 34)

Planning Poker
All show their hand at the same time
Discuss and justify variations
Agree the effort – if not, break the Story

Team Velocity
Initially a guess
Indication of capacity
Indication of completion
Burndown Chart

Story Points:
The separation of the estimation of effort from the estimation of duration

"Every year there is a new estimation technique. The real Agile approach would be to throw estimates out"
Ron Jeffries - Agile Manifesto co-author

A popular movement in the Agile world
Considers estimating a waste of time
"At the one point in the project when I know the least about it you want me to commit to a timescale and cost!"
A ship's Captain can only see as far as the horizon

Yesterday's weather
Look back over past work
Keep metrics on similar stories
Forecast based on experience
Track stories through the stages

Estimating is hard
It's often wrong
Practice can help
Don't commit too far into the future
Consider other approaches
The value needs to be proven

Questions?

Feedback?

Comments?