How to Keep Stakeholders Informed About Engineering Progress
Engineering, product, program management, leadership and business stakeholders all care about delivery — but each asks a different question, and each tends to answer it by reading the ticket data in its own way. The result is five versions of the truth. The fix is a shared view, not more meetings.
Part of Engineering Delivery Intelligence: better planning and fewer surprises
This guide answers
- What does each stakeholder group need to know?
- Why do teams end up with different numbers?
- How do you build one shared view of delivery?
- How often should each group hear from engineering?
Five audiences, five questions
- Engineering
- Where is work stuck?
- Stage queues
- Aging work
- Product
- What changed, and what did it displace?
- Scope added and removed
- Program management
- Which dependencies and dates are at risk?
- Blocked work
- Carryover
- Leadership
- Are we on track? What needs a decision?
- Progress
- Risks
- Business stakeholders
- What reached customers? What is next?
- Released work
Different questions, same underlying data. The answers should agree.
None of these questions is unreasonable, and none of them is answered by a velocity chart. Most miscommunication between engineering and the rest of the business comes from answering one group’s question with another group’s numbers.
How the same ticket data gets read five ways
Engineering reads “done” as
Merged and tested
- 46 issues done in Sprint 24
- Sprint looks mostly successful
- Next: start the next priority
The business reads “done” as
Customers can use it
- 38 issues released in Sprint 24
- 8 are done but not yet available
- Next: when will the rest ship?
If “done” means different things to different people, every report will look wrong to someone.
The same happens with “in progress” (does code review count?), “blocked” (by what?), and “the sprint” (the original plan or the final scope?). Each group builds its own spreadsheet or dashboard with its own definitions, and the numbers stop agreeing.
Agree the vocabulary first. A small set of delivery stages — not started, development, code review, QA, done, released, blocked — with every workflow status mapped to one of them, gives everyone the same words.
Building one shared view of delivery
- Sprint data
- Status history
- Release status
Shared delivery view
- Engineering: queues and aging
- Product: scope and trade-offs
- Programs: dependencies
- Leadership: progress and risk
- Business: what shipped
Each group sees the view that answers its question — computed from the same data with the same definitions.
- One source of delivery data, read by every audience.
- One set of definitions for stages, completed and released.
- Different views, not different numbers: each audience sees the slice that answers its question.
- Evidence behind every figure, so disagreements are resolved by looking at the issues, not by debating whose spreadsheet is right.
Communicating initiative progress beyond the sprint
Business Profile epic
- Development complete
- 92%
- QA complete
- 68%
- Released
- 42%
Engineering completion ≠ production delivery. Development complete counts work past development; QA complete counts done and released; released counts only what reached production.
For initiatives, report development complete, QA complete and released separately — “80% done” can still mean nothing has shipped.
Business stakeholders often care less about sprints than about initiatives: is the new checkout coming this quarter? Sprint-level updates do not answer that. Report initiative progress by delivery stage — how much is built, tested and released — and show how the initiative’s scope has changed, so a growing initiative is not mistaken for a stalled one.
A communication rhythm that scales
| Audience | Frequency | Content |
|---|---|---|
| Team | Continuously | The board, stage queues, aging work |
| Product | Twice a sprint, plus on any trade-off | Changes and what they displaced |
| Program management | Weekly | Blocked work, dependencies, carryover |
| Leadership | Mid-sprint and at close | Status, risks, decisions, outcomes |
| Business stakeholders | Per release or milestone | What shipped and what is next |
The sprint progress for leadership guide covers the leadership update in detail, and the engineering status report guide covers the end-of-sprint format.
When the numbers disagree
Sooner or later someone will say “that’s not what my dashboard shows.” Treat it as a definitions problem before treating it as a data problem. The usual culprits are predictable:
- Different denominators. One report divides by the original commitment, another by final scope. See sprint scope change.
- Different meanings of done. One counts merged work, another counts released work.
- Different moments in time. One report uses status at sprint close, another today’s status. See why work carries over.
- Different workflows mapped differently. A “Ready for QA” status counted as development in one place and QA in another.
Resolve the definition once, write it down, and apply it in the shared view. The disagreement should not come back.
Product and engineering: communicating trade-offs
Implicit
“We added the incident work”
- Planned work quietly slips
- Product learns at the review
- Completion rate looks like a miss
- Nobody decided the trade
Explicit
“+8 incident issues; onboarding export moves”
- Trade made when the work arrives
- Product confirms or changes it
- Outcome explained before it happens
- Leadership sees a decision, not a miss
Name what the new work displaces at the moment it is added — not at the sprint review.
Most friction between product and engineering is about change that nobody made explicit. When additions are logged with what they displaced, the sprint outcome stops being a surprise to anyone — and conversations shift from blame to priorities.
See this in VeloWise: Epic delivery
Initiative and epic progress by delivery stage — development, code review, QA, done and released — so “done” is never mistaken for delivered.
Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.
Go deeper
Frequently asked questions
- How do I align engineering and product on delivery status?
- Agree on delivery stages and on what completed and released mean, then report from one shared source. Most misalignment comes from different definitions, not different facts.
- What should business stakeholders see?
- What reached customers and what is coming next, in plain language. Stage-level detail and ticket counts are usually more than they need.
- How do I communicate delays without damaging trust?
- Early and specifically: what is late, why, what it affects and what you propose. Trust is damaged far more by late surprises than by honest early warnings.
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 Communicate Sprint Progress to Leadership
Answer the seven questions leaders ask mid-sprint — on track, done, moving, blocked, changed, carrying over, shipped — in one short update.
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.