AI for Stakeholder Updates: Turning a Messy Sprint Into a One-Page Executive Summary

Your sprint board is a log of work. A stakeholder update is an argument about progress. The gap between the two is why the Friday summary eats an hour and still reads like a changelog.

We ran one of our own two-week sprints through this to see where the time actually goes: 41 closed issues, 9 carried over, 6 PRs still open at cutoff, and a project channel with a few hundred messages. Pasting the raw issue export into a model produced something competent and useless — ticket titles regrouped under their labels, one summary sentence per group. Nothing in it told a reader outside the team whether the release date still held.

That is not a model problem. It is an input problem.

Feed it decisions, not tickets

An issue tracker records motion. It does not record judgment. “Fix flaky auth test” and “Drop OAuth from the v2 scope” look identical in an export — both closed, same fields, same sprint — but only one of them is news to anybody above your skip-level.

Before you prompt anything, spend ten minutes sorting the sprint into four buckets.

Shipped and visible. Work a user, a customer, or another team can now observe. Not “merged PR #482” but “password reset now works on mobile Safari.”

Changed plans. Anything you decided differently from what was agreed at planning: scope cut, sequencing swapped, a dependency you took on. Each one needs its reason attached, because the reason is the only part a stakeholder can act on.

Blocked, with an owner. A blocker without a named person and a named ask is a complaint. “Waiting on security review” is noise. “Needs Priya’s sign-off on the data retention doc, requested Tuesday” is a request.

The number. Whatever the single tracked commitment is — launch date, migration percentage, error budget. State it, state whether it moved, state the direction.

Everything else in the sprint is implementation detail. It belongs in the sprint review, not the update.

Ten minutes of that triage did more for output quality in our run than any amount of prompt rewriting. Models are good at compression and bad at deciding what matters, because materiality depends on context they do not have: who is nervous about what, which date was promised to whom, which team got burned by this same dependency last quarter.

A prompt that survives contact with a VP

Once you have the four buckets, the prompt’s job is constraint, not creativity. Ours:

You are drafting a stakeholder update for [audience: e.g. VP Engineering
and two product directors]. They did not attend standup and do not know
the codebase.

Input follows in four sections: SHIPPED, CHANGED, BLOCKED, NUMBER.

Write:
1. A three-sentence opening: current state of the commitment, whether it
   moved, and the single most important reason.
2. "What shipped" — max 5 bullets, each phrased as user-observable
   behavior. No PR numbers, no service names unless the reader owns that
   service.
3. "What changed and why" — max 3 bullets. Each: decision, reason, effect
   on the date.
4. "Needs a decision" — each item names one person and one ask.

Rules:
- Under 400 words total.
- No adjectives of quality (solid progress, great work, strong velocity).
- If a fact is not present in my input, write UNKNOWN. Do not infer causes.
- Do not soften a slipped date.

Two of those rules carry most of the weight. The UNKNOWN instruction stops the model from bridging gaps with invented causality, which is the failure mode that can actually cost you credibility. The adjective ban strips the register that makes AI-drafted updates recognizable on sight — and that same register is what lets a genuinely bad sprint read as fine.

The word cap matters more than it looks. A one-page update is a forcing function: at 400 words you have to choose, and the choosing is the value you add. Let it run to 900 and you have rebuilt the changelog with better grammar.

Check three things before you send

Invented causality. The model will connect two facts that happened in the same sprint into cause and effect. If your input says the migration slipped and separately says two engineers were on-call, the draft may tell your VP that on-call load caused the slip. You never said that. Delete any “because,” “due to,” or “as a result of” that you cannot personally source.

Status inflation. Models trained on business writing default to reassurance. Watch for “on track” appearing next to a date you privately think is at risk, and for blockers quietly demoted into the closing paragraph. Read the draft once as though you were the person whose budget depends on it.

Flattened severity. Compression gives equal bullet weight to the thing that cost two days and the thing that could cost the quarter. Rank the bullets yourself after generation. That reordering takes under a minute and is the highest-leverage edit in the process.

Realistically the cycle lands around ten minutes of triage, one generation, and five to ten minutes of editing. Faster than writing from scratch, but the savings come from the draft, not from the thinking. Skip the triage and hope the model supplies the judgment, and you get a document that is quick to produce and that nobody trusts twice.