Architecture & practice·topic 8 of 10
Estimation and planning
The part of the job where engineers are asked to say something confident about the future. These terms will not make your estimates right, but they will let you say precisely why they are wrong, which is what the conversation actually needs.
Read in order · tick what you already know
- 01
you were asked for a date before anyone had opened the vendor's documentation, and gave one.
Cone of uncertainty
- 02
you said about three weeks, and heard it repeated in a meeting as the date it will be done.
Estimate
- 03
the date went on a customer contract, and after that the scope was the only thing left to move.
Commitment
- 04
you estimated the happy path, which is the only version of the work you pictured.
Planning fallacy
- 05
you padded the estimate for the usual overruns and it still took longer than the padded number.
Hofstadter's law
- 06
instead of estimating the migration, you looked at how long the last three migrations actually took.
Reference-class forecasting
- 07
the team sized it a five, and someone in a status meeting asked how many days a five is.
Story point
- 08
you sorted twelve ideas into small, medium and large in twenty minutes, which was all the decision needed.
T-shirt sizing
- 09
the number went up every quarter and the amount of software delivered did not change.
Velocity
- 10
the team was measured on tickets closed, and the tickets got smaller.
Goodhart's law
- 11
you agreed to spend two days on it and to come back with what you had, whatever that was.
Timebox
- 12
the task had two weeks allocated and took two weeks, and it would have taken three days in a crisis.
Parkinson's law
- 13
each addition was reasonable on its own and the project is four months longer than it was in January.
Scope creep
- 14
the date was fixed and the scope was fixed, and everyone acted surprised about quality.
Iron triangle
- 15
you shipped the smallest thing that would tell you whether anyone wanted it, and half the team called it unfinished.
Minimum viable product
- 16
the first thing built was a thin path all the way from the button to the database, doing almost nothing.
Walking skeleton
- 17
a fifth of the features covered nearly all of the usage, and the rest of the roadmap was the other four fifths.
Pareto principle
- 18
three engineers joined the late project and the next month was slower than the one before.
Brooks's law