Asked how long something will take, the honest answer is a distribution. Most of the pain in software projects comes from that distribution being flattened into one date very early, by someone who was not going to build it.
Estimate the thing you understand
We break work down until each piece is small enough to be confident about. If a piece cannot be estimated, that is not an estimating problem - it is a research task, and we schedule it as one.
The range is the information
- The low end assumes nothing surprising
- The high end assumes the usual amount of surprise
- The gap tells you how much we still do not know
Re-estimate as you learn
An estimate made before the first sprint is the worst one you will ever have. We revise after each cycle and show you the revision, including when it moves the wrong way.
What actually makes it slip
Rarely the coding. Usually a decision waiting on someone, a third party behaving differently to its documentation, or scope that grew a little at a time.
