Rewrite six estimates

kind: drill

Each is a real sentence from a project meeting. Rewrite it as a range with an assumption, and add the date at which the uncertainty shrinks where one exists.

  1. "The login takes two days."

  2. "We’ll be done before Christmas."

  3. "That’s a quick fix."

  4. "The database migration is maybe a week."

  5. "Testing, let’s say one day."

  6. "Deploying it should be trivial."

Solution

  1. "One to five days. One if we use the library the fourth year used; five if we implement OAuth ourselves. I will know which by Thursday."

  2. "Six to ten remaining changes at our current 0.75 per week is eight to thirteen weeks, so before Christmas only if nothing is added. The next milestone tells us whether the rate holds."

  3. "Twenty minutes if the cause is where I think it is; up to a day if it is in the import path. Give me half an hour to find out."

  4. "Three to fifteen days. Three if the old data is clean, fifteen if the duplicates we found in the sign-in sheets are also in the export. I can check that tomorrow morning."

  5. "Not estimable as a separate item, because it is not a separate item — testing is inside every change. If you mean the acceptance run with the client, half a day plus the time to fix what it finds, which is unknown until it runs."

  6. "Unknown; nobody in the team has deployed to the school server. Two hours timeboxed to find out, then I can give you a range."

Items 5 and 6 are the important ones. "Testing" as a trailing phase is the 90 % syndrome with a name on it, and "trivial" is what people say about work they have never done.

Compute a forecast from an archive

kind: drill

A team’s archive/ shows changes archived in these calendar weeks:

KW38  KW39  KW41  KW41  KW43  KW44  KW46  KW47  KW49

Six changes are open or planned; the deadline is KW10 of the following year, and KW52–KW01 are holidays.

  1. Compute the throughput.

  2. Forecast the finish, as a range.

  3. Name two things that would make the forecast wrong.

Solution

  1. Nine changes from KW38 to KW49 is twelve weeks: 0.75 changes per week.

  2. Six remaining at 0.75 is eight weeks of work. From KW50, with two holiday weeks and no reason to assume the rate improves, that lands around KW10 — right on the deadline, with no slack. As a range: KW8 if the remaining changes are on the small side and the rate holds, KW13 if the rate drops as it did around KW40. Report both.

  3. Any of: the remaining changes are not comparable in size to the archived ones (the last ones usually are not — integration and acceptance work is bigger); the exam period in February; scope added after the second milestone; one team member unavailable; the historical rate itself included a burst that will not repeat.

The right conclusion is not "we will make it". It is: this forecast has no slack, which is a fact worth putting in front of the client in KW50 rather than in KW9.

Spot the mechanism

kind: drill

Name which of the four mechanisms is at work.

  1. Everybody in the room estimates between 2 and 3 days after the team leader wondered aloud whether it was "about two days".

  2. The team is at 90 % for the third week running.

  3. Nobody thought about the data migration until the second milestone.

  4. The estimate given to the teacher was three days; the same person had written "about a week" in their own notes that morning.

Solution

  1. Anchoring. The fix is procedural and cheap: everybody writes their number down before anybody says one. It costs sixty seconds and removes most of the effect.

  2. The 90 % syndrome, and usually with a missing definition of done underneath it. Ask what would have to be archived for it to be 100 %; the answer is normally three items nobody had listed.

  3. Planning fallacy. The migration was not underestimated — it was never estimated, because nobody imagined it. The cure is a checklist of the work that is always there and always forgotten: review, migration, deployment, documentation, acceptance.

  4. Optimism under observation. The private number was the honest one. Which is the argument for estimating alone first and only then in the group.

Note that three of the four have a procedural fix that takes under a minute. That is the claim of the module: hygiene beats method.

Estimate your own remaining project

kind: project

  1. Compute your team’s throughput from archive/: archived changes divided by elapsed weeks. Write the number down.

  2. List the remaining changes to the deadline, and mark the ones you believe are not comparable in size to what you have archived so far.

  3. Produce a forecast as a range, with the assumption behind each end named.

  4. Identify the one thing you know least about, and plan a timeboxed spike for it: a fixed budget, and an estimate as the deliverable.

  5. For the last three archived changes, write one line each: estimated against actual. Say what the difference has in common.

  6. Bring the forecast to the next milestone review — and say explicitly whether it is an estimate or a commitment.

Step 5 is where the learning is. Three lines are enough to show a pattern, and it is almost always the same pattern: the work nobody listed.