Communicating Estimates and When the Plan Slips: Updating, Delivering Bad News Early and Replanning

Version note: The plan update code in this post was built and run with .NET 10; the discussion of adding people is based on the observation in Fred Brooks' The Mythical Man-Month (1975).

Make a Guess First

Monday, 4 January 2027. The team of Bookstore, the online bookstore used as the shared example across this site's series, has finished three sprints of Institutional Orders Release 1. The plan was an average of 20 points per sprint; 19 points were done in Sprint 24, 17 in Sprint 25 and 11 in Sprint 26, which fell over New Year. In the same three sprints scope went from 130 points to 142: as we saw in the fifth post, the school invoice fields and the consent text turned from uncertain risks into concrete stories. On Friday Hakan will discuss the school's spring order with Nevin Hanım.

Three questions. When should Selin tell Hakan: today, or after waiting another sprint to see whether things recover? Which options should she take to Hakan? And Emre's suggestion, "Let's borrow someone from the other team for two months": does it save the date?

Communicating an Estimate to Stakeholders

The hard part of communicating an estimate is not the number but the information around it. As we saw in the first post, once the range and the assumptions get separated from the sentence, the estimate turns into a commitment. That is why the Bookstore team keeps a one-page estimate note for every release and renews the same note at every update. The note has these sections:

The "Change" row is the most important part of the note. What makes a stakeholder trust an estimate is not that it never changes, but that when it changes, the reason is clearly visible. "The date slipped" on its own costs trust; "the date slipped because scope grew 9% and the New Year sprint was weak" gives a basis on which the decision can be discussed.

Tracking: An Update Every Sprint

The note's numbers are the plan from the fourth post, updated with actuals. The new class keeps Release 1's sprint results and reuses the VelocityRange and SprintEnd methods from the fourth post:

namespace Bookstore.Planning;

public sealed record SprintResult(int Number, int DonePoints, int ScopeAtEnd);

public static class ReleaseUpdate
{
    // Institutional Orders Release 1: every sprint end since it started
    static readonly SprintResult[] Actuals =
    [
        new(24, 19, 133),
        new(25, 17, 138),
        new(26, 11, 142),
    ];

    const int PlannedScope = 130;
    const int MustAtStart = 96;

    public static void Run()
    {
        // Burn-up: plan (mean 20) vs. actual
        Console.WriteLine("Sprint  planned  done  scope");
        int done = 0;
        for (int i = 0; i < Actuals.Length; i++)
        {
            done += Actuals[i].DonePoints;
            Console.WriteLine($"  {Actuals[i].Number,4}  {20 * (i + 1),7}  {done,4}  {Actuals[i].ScopeAtEnd,5}");
        }

        int scope = Actuals[^1].ScopeAtEnd;
        int remaining = scope - done;
        double growth = (double)(scope - PlannedScope) / Actuals.Length;
        Console.WriteLine($"Remaining {remaining} points, scope growth {growth:F1} points/sprint");

        // Refresh the velocity range with the new sprints: again the last 10 (only Velocity is used here)
        Sprint[] last10 = [.. SprintHistory.Last10.Concat(Actuals.Select(a => new Sprint(a.Number, [a.DonePoints]))).TakeLast(10)];
        (double low, double mean, double high) = ReleasePlan.VelocityRange(last10);
        Console.WriteLine($"Velocity range now (S{last10[0].Number}-S{last10[^1].Number}): worst-3 {low:F1}, mean {mean:F1}, best-3 {high:F1}");

        int used = Actuals.Length;
        Console.WriteLine();
        Console.WriteLine("Option A, keep full scope:");
        foreach ((string name, double v) in new[] { ("worst-3", low), ("mean", mean), ("best-3", high) })
        {
            int flat = (int)Math.Ceiling(remaining / v);
            int growing = (int)Math.Ceiling(remaining / (v - growth));
            Console.WriteLine($"  {name,-8} {ReleasePlan.SprintEnd(used + flat):yyyy-MM-dd}  (if scope keeps growing: {ReleasePlan.SprintEnd(used + growing):yyyy-MM-dd})");
        }

        // B: only Must by March 1; the new regulatory work is Must as well
        int sprintsLeft = Enumerable.Range(1, 20).Last(n => ReleasePlan.SprintEnd(n) < ReleasePlan.Target) - used;
        int mustRemaining = MustAtStart + (scope - PlannedScope) - done;
        Console.WriteLine();
        Console.WriteLine($"Option B, Must only by {ReleasePlan.Target:yyyy-MM-dd}: {mustRemaining} points in {sprintsLeft} sprints");
        foreach ((string name, double v) in new[] { ("worst-3", low), ("mean", mean), ("best-3", high) })
            Console.WriteLine($"  {name,-8} capacity ~{sprintsLeft * v:F0} -> {(sprintsLeft * v >= mustRemaining ? "fits" : "does not fit")}");
    }
}

We add case "update": ReleaseUpdate.Run(); break; to Program.cs and run it:

dotnet run --project src/Bookstore.Planning -- update

Sprint  planned  done  scope
    24       20    19    133
    25       40    36    138
    26       60    47    142
Remaining 95 points, scope growth 4.0 points/sprint
Velocity range now (S17-S26): worst-3 14.0, mean 18.5, best-3 22.3

Option A, keep full scope:
  worst-3  2027-04-09  (if scope keeps growing: 2027-05-21)
  mean     2027-03-26  (if scope keeps growing: 2027-04-09)
  best-3   2027-03-12  (if scope keeps growing: 2027-03-26)

Option B, Must only by 2027-03-01: 61 points in 4 sprints
  worst-3  capacity ~56 -> does not fit
  mean     capacity ~74 -> fits
  best-3   capacity ~89 -> fits

Reading the Output

The first table is the burn-up in numbers. Against the planned 60 points, 47 were done; more than half of the 13-point gap comes from the New Year sprint. Scope grew by 4 points per sprint on average. On the chart from the fourth post this means the actual points hugging the lower edge of the fan and the pink scope line rising. This is where keeping the two lines separate pays off: half of the delay comes from the team's pace and half from scope growth, and the two causes have different remedies.

The velocity range has been updated too. The last 10 sprints now run from Sprint 17 to 26, and Sprint 26's 11 made it into the worst three: the range is 14.0, 18.5 and 22.3. Whether the New Year sprint should pull the low end of the range down this far is debatable; leaving a one-off, leave-driven dip out of the range is a defensible choice as well. But it has to be done deliberately and written in the note.

Option A keeps the scope: the remaining 95 points finish on March 26 in the average case and April 9 in the bad case. If scope keeps growing at the same rate the dates slip two more weeks; in the bad case to late May. March 1 no longer holds for the full scope in any scenario.

Option B ships only the Must scope on March 1. The Must items were 96 points at the start; the new invoice fields and consent text are legal requirements, so they are Must too. The remaining Must work is 61 points and there are 4 sprints before March 1. About 74 points fit at average velocity, 56 in the bad case. So the Must scope fits in the average case and is roughly one story short in the bad case. This is the consequence of the MoSCoW warning in the fourth post: when the Must share is high, flexibility runs out at the first slip.

Spotting a Slipping Plan Early

At Bookstore the slip became clear in the third sprint, but the signals were there earlier. The places to look are known. Velocity staying below the middle of the range two or three sprints in a row is not an alarm on its own, but actual points drifting towards the lower edge of the burn-up fan is a trend. A scope line that rises every sprint shows requirements are still not settled, meaning the cone from the first post is not narrowing at the expected rate. Risks leaving the register and entering the plan as issues reduce capacity directly. There are signals inside the sprint as well: items sitting in "In Progress" for a long time and stories called "almost done" that never reach Done. Tracking item age is the topic of the Kanban series post "Flow Metrics: WIP, Throughput, Work Item Age and Cycle Time".

None of these signals alone means "the plan slipped". But each deserves a line in the "Change" row of the estimate note. For a team that updates the note at the end of every sprint, a slip is not a surprise but the result of a trend that has been visible in the note for weeks.

Options When the Plan Slips, and Who Decides

When a plan slips the options are limited: cut scope, move the date, add people, or give up quality and a sustainable pace. The last one is not an option but a debt; we will come back to it below.

Adding people looks like the most reasonable option at first. Drawing on his experience with IBM's OS/360 project, Fred Brooks observed the opposite in The Mythical Man-Month in 1975: "Adding manpower to a late software project makes it later." There are two reasons. The first is ramp-up time: a newcomer is not productive until they learn the code, the domain and the team's habits, and the people who know most, Emre and Ayşe, have to spend time on them. In the first weeks the team's net capacity does not go up, it goes down. The second is communication: a team of n people has n(n − 1) / 2 communication channels. A three-person team of two developers and a Product Owner has 3 channels; a fourth person makes it 6. Brooks himself points out a limit: adding people works for work that can be split into independent parts. At Bookstore, with eight weeks left, someone dropped into the pricing and validation code is unlikely to contribute by March 1; but an independent piece of work, such as exporting the order list, could be given to them.

The owner of scope and date decisions is not the team. In Scrum the content and order of the Product Backlog are the Product Owner's responsibility; Selin decides which Must item can wait until the first week. The promise to the school is a business decision; Hakan and Selin make it together. The team's job is to lay out the options and the probability of each clearly. If the team makes that decision on its own by saying "we'll make March 1", it also pays for the decision itself, in overtime.

At Bookstore the decision goes like this. Selin chooses option B and discusses a workaround for the 5-point "delivery points per campus" story on the Must list: for the first two weeks Gül will add the delivery point to the order as a note. That brings the remaining Must work down to 56 points, which just fits the bad case's capacity. The Should items will arrive with a second release on March 26. On Friday Hakan will explain this to Nevin Hanım, with the dates and the workaround.

Delivering Bad News Early

The answer to Selin's first question: today. The temptation to wait another sprint is understandable; maybe Sprint 27 goes well and nobody notices the slip. But waiting only buys two weeks of silence, while what it costs is options. On January 4 Hakan has eight weeks to talk to the school and Selin has four sprints to rearrange scope. Had the same news come at the Sprint Review on February 25, the only option left would have been moving the date and telling the school at the last minute.

Three things help when delivering bad news. First, bring options with it: not "the plan slipped" but "the plan slipped; we have two options and we recommend this one." Second, give the reason in numbers: how much scope grew, how much velocity dropped. Third, give the date of the next update; it keeps the stakeholder from filling the silence with worry. Delivering bad news early is less about the team protecting itself and more about giving the person who decides the time to decide.

Estimation Culture: Learn, Don't Punish

Every calculation in this series rests on the team's own history: the feature table in the first post, the epic ratios in the third, the velocity in the fourth. That data only helps if estimates are given honestly. Where developers who miss their estimates get questioned, estimates either get inflated or stop being given; either way, historical data loses its meaning.

The right place to compare estimates with actuals is the retrospective. When Release 1 is done, the Bookstore team will look at these questions: how often did the velocity range cover the actuals, why did scope grow 9%, which problem came up that was not on the pre-mortem list? The goal is not to find who was wrong, but to fix the inputs of the next estimate: maybe the reference class multiplier should grow, maybe regulatory work should be discussed earlier when splitting stories. Retrospective formats are in the Scrum series post "Sprint Review and Sprint Retrospective: Inspecting the Product and the Process".

In Production

Tie the update to a calendar. Bookstore's estimate note is updated at every Sprint Review and goes to Hakan the same day. The update itself doesn't separate good news from bad; the note arrives in the same form every two weeks. That way the update with bad news is not an alarm, just the next note.

Put workarounds into the plan. Gül adding the delivery point by hand is a scope decision; how long it lasts and the date it goes away should sit in the backlog as a story. Otherwise the workaround becomes permanent and the manual entry problem we tried to solve in the Requirements Analysis series is reborn somewhere else.

Don't overwrite the old estimate with the new one. The history of estimate notes is the only answer to "what did we know, and when?" in the retrospective. Notes kept in date order on one page are enough.

Common Pitfalls

• Hitting the estimate with overtime: it can work for a short while, but the longer it lasts the more mistakes and fatigue pile up; one of the Agile Manifesto's principles is that the team works at a pace it can keep indefinitely. And the next estimate rests on a velocity that never really existed.
• Saving bad news for demo day: the later the news, the fewer options the decision maker has.
• Treating adding people as the default fix: ramp-up time and communication overhead lower capacity first on a late project.
• The team deciding alone: scope and date are business decisions; the team presents the options and their probabilities.
• Forgetting the workaround: manual work becomes permanent and its cost becomes invisible.
• Tying estimation error to a person: punished estimates get inflated and historical data becomes useless.

A Small Experiment

★☆☆ Write a one-page estimate note for a piece of work you are doing, using the seven sections in the table above. Which section was hardest to fill? That section is most likely the weakest part of your estimate.

★★☆ Add an option to ReleaseUpdate that leaves Sprint 26 out of the velocity range because of New Year, and recompute the dates. How would you explain that decision in the note's "Assumptions" row?

★★★ Add a Monte Carlo to ReleaseUpdate that samples scope growth from the growth in the last three sprints instead of using a fixed linear number. What is the probability that the Must scope fits by March 1 under option B?

This post ends the Estimation and Planning series: we went from why estimates go wrong, to how to estimate, to how an estimate turns into a plan, a risk list and finally a conversation. Keeping the burn-up, velocity and risk list we used here in a tool, getting reports out of it and sharing them with the team is the topic of the Jira and Project Tools series.