The Software Estimation Manifesto

Accept that making estimates is unavoidable in commercial software development, whatever your methodology.

Accurate estimation is hard, harder without lots of experience, and even harder with changing scope or project risks.

Accept that time and money are never unlimited (if you can consistently achieve this please tell us how).

Assume initial bad estimates and use an ‘expected vs actual’ feedback loop to improve accuracy over time.

Verify your estimates (get a second opinion) before you communicate them to the project manager.

Move away from development methods that require perfect predictions in an up-front project plan written in stone.

Adopt development methods that minimise the impact of bad estimates and generate continuous improvement.

There are many types of estimate: developer fantasy world, realistic, pessimistic, arse-covering and downright cynical.

Realistic estimates allow for frequent annoyances (telephones), occasional impediments & rare disasters (office on fire).

Pessimistic estimates are more useful than best-case estimates; under-run usually has less impact than over-run.

Your estimates are not just wrong because the task takes longer, but also because you forgot a quarter of the tasks.

Estimates are inherently non-negotiable - how long it will actually take. Argue about price and quality instead.

Don’t negotiate estimates with your manager. Apart from anything else, he is better at it and will ‘win’.

Define ‘done’. What are you estimating exactly? (Several of Scrum’s benefits are individual wins.)

Specify who does the work. Despite much wishful thinking in the industry, programmers are not fungible, especially not good ones.

Make estimates that can be added together. If you say each feature will take a day, they’ll expect five per week.

How long a task should take is a fantasy best-case. Telling your colleagues about your fantasies is TMI.

The most cynical technique is sometimes true: take the next time unit and double it - ‘3 days’ becomes ‘6 weeks’.

Do not vary quality; software quality is a project-level consideration, not a per-feature decision.

Making estimates is a game of averages. Trade individual accuracy for overall accuracy.

Avoid the bandwagon effect. Blind estimation is common to the Delphi method, Scrum planning and others.

Improve estimates with comparison (with other estimates) and feedback (how good they turned out to be).

Learn the estimation techniques, such as Delphi method or Scrum planning; then learn some rules of thumb.

Even if you are not using Scrum, its principles of Transparency, Measurement and Improvement are useful.

Check your estimates to avoid them being ‘obviously wrong’. The best way to do this: ask someone else.

Understand the business context to the question ‘how long will it take?’ to discover the actual question.

Communicate estimates carefully - project stakeholders’ own interpretations are not necessarily the ones you want.

Improve your estimates. Use reality for feedback, i.e. ask yourself how long it actually took.