Software & TechnicalFree
Engineering Status Report for Executives
Percent complete is not progress. River reports the date each milestone moved to, the scope that arrived after commitment, and the decisions waiting on a person.
River reads the ticket export, the milestone plan and last period's update, then writes the version an executive can act on. Every milestone carries four dates: the one you committed to, the one you reported last time, the one you are reporting now, and the cumulative slip between the first and the last. The decisions section names each decision, the person who has to make it, and the date after which making it no longer helps anyone.
Search the phrase and page one is status report templates. They share the same five headings and a red, amber or green light at the top. The headings are fine. What they cannot do is stop a milestone reading amber for three consecutive weeks while its date moves six weeks to the right, because each report describes the present and nothing in it compares that to the last one. The slip is real and invisible.
Built for the engineering leader who has forty minutes on Thursday and an exec review on Friday. Reach for it when the honest answer is complicated and the format is not helping. The roadmap pack holds the dates this update reports variance against, and the release notes say what reached customers. The technical program plan pack holds the handoffs behind a date that moved, and the incident postmortem is where the reliability line comes from. Where a milestone has no data, the absence goes in the update with a name against it.
Percent complete is a board setting
Start with what done means. Atlassian's own documentation is explicit: a work item is considered Done when it is in a status mapped to the right-most column of your board. That is a configuration choice, made once by whoever set the board up, and it differs between two teams in the same programme. So a percentage of closed tickets is a statement about column mappings. It is not a statement about whether a customer can use the thing.
Then the denominator. The same page notes that work items added after the sprint starts are indicated with an asterisk, and that a story point figure shown as two values with an arrow between them means the estimate was adjusted mid-sprint. Both facts exist because scope moves constantly, and both get flattened the moment you report a single percentage. The update keeps apart the two sentences an executive needs separately: we are behind, and you added things.
Delivery metrics get the same treatment. DORA now publishes five, having replaced mean time to restore with failed deployment recovery time, and warns against blending metrics across multiple teams or entire organizations because the context differs. So the update reports them per service, with the service named. An organisation-wide deployment frequency on slide two is a number the people who defined it say not to compute. Per service costs nothing to compute and survives the first question from the room.
How it works
Send the export
The ticket export, plus the deploy log and the incident record if you have them.
Name the commitments
The milestone dates you actually committed to, and what shipping means for each one.
Paste last week
Last period's update, which is what turns a status snapshot into a reported change.
Read the asks
The update lands written; you check the variance sheet and the decisions waiting on people.
What you get
- Every milestone with the date it was committed to, the date now, and the slip
- A diff against last period's update, so a repeated slip stops reading as amber
- Scope that arrived after commitment, counted apart from the work you are behind on
- Each decision waiting, with the person who makes it and the date it expires
- Progress against what shipping means for that milestone, not against closed tickets
- Delivery metrics per service, because the framework that defines them says not to blend
Common questions
We do not keep last week's update anywhere.
Then the first one you write here becomes the baseline, built from the plan and the ticket history rather than from a previous document. From the second onward every milestone carries its own date history, so a slip is arithmetic instead of a memory. Most teams find the first run alone already surfaces two dates that had quietly moved.
Our tickets are not tidy enough for this.
They do not need to be. The dates come from the milestone plan and what shipping means comes from you, so ticket movement is an input rather than the spine of the report. Where the export is too messy to support a claim, the update says so and names what would confirm it. How much of your work the tickets can see at all is a delivery metrics review.
Is this a Jira summariser?
No. A summariser compresses ticket movement, which is the part of the week an executive has the least use for. This reports against dates you committed to and against what shipping means for each milestone. What actually reached customers comes from the release notes, not from a status column.
What if the honest answer is that we are late?
Then the first line says so, with the new date, the cause, and whether it has moved before. An update that reports amber for a month and then announces a quarter of slip costs more credibility than any single bad number. Naming the third slip as the third slip is what keeps the room.
Our exec team wants one slide.
They get one, and it holds the two things only they can act on: the dates that moved since they last looked, and the decisions waiting on named people with expiry dates. The variance sheet and the detail sit underneath for whoever asks the follow-up question in the room.
How much technical detail goes in?
Enough to make a date defensible and no more. A migration that slipped because the acquirer's certification takes four weeks needs that sentence; it does not need the retry semantics. The design belongs in a solution architecture document, and the update links to it rather than reproducing it.
What separates a decision from a risk?
An owner, a date and a consequence. A risk is a sentence about the future that nobody has to answer. A decision names the person choosing, what they are choosing between, and what closes off if they have not chosen by a date. Once made, it gets recorded in an architecture decision record.
Engineering Status Report for Executives
Fill in the form and your workspace opens with the work already underway.