How to Communicate Sprint Progress to Leadership

What a good mid-sprint update looks like

This is the whole update. A director can read it in under a minute and know three things: the sprint is not on track as planned, why (13 issues added after the start, and a blocked dependency), and what they can do about it (approve a trade-off, escalate a dependency).

Everything on the card comes from data the team already has — sprint membership, status changes and the delivery stage each status maps to. Nothing is estimated from gut feel, and nothing requires a meeting to collect.

The seven questions leadership is really asking

Status meetings tend to answer these questions indirectly, one ticket at a time. Asking them explicitly — and answering each with a number and a one-line explanation — is what turns a meeting into a message.

Replacing status-meeting noise with signal

The problem with status meetings is not that people talk; it is that the useful information — what changed, what is stuck, what needs a decision — is scattered among updates that could have been read from the board. The meeting ends up being where the data is assembled, rather than where decisions are made.

When the update arrives already assembled, the meeting can shrink to the part that needs people: the trade-offs and the blockers. Many teams find they can replace one recurring status meeting entirely.

Answering “are we on track?” honestly

“On track” is not a feeling; it is a comparison between what is left and how much the team usually completes in the time remaining. Three questions make it concrete:

1. How much is left, and where is it? Work in QA with three days left is closer to done than work not yet started.
2. How much does the team usually complete in this many days? Use recent sprints, not estimates.
3. What is unlikely to finish regardless? Not-started work late in the sprint, blocked work, and work that has been in one stage much longer than usual.

In Sprint 24 on day 7, 13 issues fall into the third group: 6 not started, 3 blocked and 4 aging in development. Saying so on day 7 — rather than discovering it on day 10 — is the whole point of a mid-sprint update.

Making change visible: what was added, and what it displaced

“What changed?” is the question most progress reports skip, and the one that most often explains a missed sprint. Report additions with their reason and — just as important — what they displaced. If nothing was removed, say so: it tells leadership the team is absorbing the change, and that something planned will likely carry over.

The scope change guide explains how to show original commitment and final scope together so the sprint outcome is read correctly.

When to send it, and to whom

Each audience reads the same data through a different question. The stakeholder communication guide covers how to keep those views consistent so product, program management and leadership are not working from different numbers.

Writing the update: a template

• Lead with the status and the decision. A reader who stops after one line should still know whether to worry.
• Use numbers with a reason. “+13 scope” invites a question; “+13: incident follow-ups” answers it.
• Name blockers by what they wait on, so the reader knows whether they can help.
• Keep individuals out of it. Progress is a property of the work system, not a ranking of people.
• Link to the evidence. Anyone who wants the ticket list should be one click away from it — not reading it in the update.

Common mistakes

• Reporting percent complete without scope. “70% done” means little if scope grew 20% this week. See how to reduce delivery surprises.
• Treating “done” as “delivered”. Separate work that is complete from work that is in production.
• Saving bad news for the review. A risk reported on day 7 is a decision; the same risk reported on day 10 is a surprise.
• Different numbers for different audiences. If product and engineering report different completion figures, trust erodes quickly. Use one source.
• Turning the update into a performance review. Once people feel judged by it, the data gets managed instead of reported.

Frequently asked questions

How often should I update leadership on sprint progress?

For a two-week sprint, a short update at the start, around the midpoint and at the close usually works better than daily reporting. Add an ad-hoc note when something material changes.

Should I share the burndown chart with executives?

Usually not on its own. A burndown shows remaining work, but not scope changes, where work is stuck or what reached production. A short summary answering those questions is more useful.

How do I say a sprint is at risk without it sounding like failure?

State the facts and the decision: what is at risk, why, and what you propose. Early, specific risk reporting is a sign of a well-run team, and leaders generally value it over late surprises.

What data do I need to produce this update?

Sprint membership over time, status history mapped to delivery stages, and release status. The questions and update format do not depend on the source tool.

Related guides

• Engineering Progress Reporting Without Endless Status Meetings

  Stop assembling progress updates from tickets, chat threads and spreadsheets. Report progress, risks, changes and outcomes from delivery data.

• How to Create an Engineering Status Report Leadership Can Actually Use

  A sprint status report leadership reads in a minute: outcome, what changed, where work is, risks and a short summary — with an example.

• How to Reduce Surprises in Software Delivery

  Delivery surprises rarely come from missing data. They come from data never turned into context. Where surprises start, and how to see them early.

• How to Keep Stakeholders Informed About Engineering Progress

  Engineering, product, program managers and business leaders read the same tickets differently. Build one shared view of delivery instead.

All engineering delivery guides