Sprint and Stakeholder Review

Walk into the review with the narrative already written

Frankee reads what your team actually delivered and turns it into a structured narrative for stakeholders: what landed and why it mattered, what did not, what is coming next, and the questions worth putting to the room. Preparation that usually happens the night before takes a few seconds.

It is called different things for different teams

The feature adapts to how your team works, starting with what it is called:

• Kanban teams see Stakeholder Review, built around a date range you choose.
• Every other framework sees Sprint Review, built around one completed sprint. That covers Scrum and Scrumban teams.

This is not cosmetic. A Kanban team has no sprint to summarise and no sprint goal to assess, so a review that asked "did we meet the sprint goal?" would be asking a question the team never posed. The naming follows your team's framework setting automatically, through the whole product: the page, the sidebar, buttons, the saved list, and the exported document.

Scrum: reviewing a sprint

Go to Team Events › Sprint Review, pick your team, and choose a sprint.

Only completed sprints are offered. A review of a sprint still running would describe work that has not finished as though it had, so the picker lists closed sprints only. Before generating you can preview the sprint's contents, which is a quick way to confirm you picked the right one.

The narrative is built from that sprint's issues, plus the sprint's own goal where one was set.

Kanban: reviewing a period

Continuous flow has no sprint boundary, so you choose the window instead. Rather than a sprint dropdown you get start and end dates.

• The default is the last 14 days through today, which suits a fortnightly stakeholder cadence. Change it to whatever your team reviews on.
• The maximum span is 60 days. Beyond that a single narrative flattens too much detail to be useful.
• Completed work means work that finished inside your window. Frankee uses the date each item was actually resolved, so an item started long before the window still counts if it landed within it.

What the review contains

Both frameworks produce the same eleven sections. The titles differ so the language fits how your team works, and any section with nothing to report is left out rather than padded.

• Sprint Summary, or Period Summary for Kanban. The value delivered as a whole rather than an item-by-item walk.
• Unplanned and In-Flight Work, or Work Still In Flight. Work in progress that was not part of the plan, which is usually the honest answer to "why did that other thing slip".
• What We Delivered. The same title for both.
• Sprint Goal Assessment, or Delivery Focus Assessment. Whether the sprint met its goal, or for Kanban whether delivery held to a coherent focus.
• What Didn't Make It, or Still In Progress. The Kanban wording matters: unfinished work in continuous flow is simply in flight, not a miss.
• Market Check-in Prompt. A prompt to ask whether anything outside the team has changed what matters.
• Questions for Stakeholders. What the team needs answered, which is what makes the meeting two-way.
• Demo and Talking Points. What to show and the points worth making while showing it.
• Next Up, or Up Next. One recommended priority with the reasoning, not a backlog dump.
• Risks and Blockers for Next Sprint, or Risks and Blockers for Upcoming Work.
• Open Questions and Assumptions for Next Sprint, or Open Questions and Assumptions for Upcoming Work.

Next Up comes from real backlog signals

For Scrum teams, Frankee looks for the next sprint and what has been planned into it. If a next sprint exists but is still empty, it falls back to the top of your ranked backlog. If there is neither, it says so rather than inventing a plan.

Kanban teams get upcoming work drawn from what is in progress or queued with a due date inside the same window, so "up next" reflects commitments rather than backlog order.

Saving and exporting

• Reviews are saved automatically. Find them under Saved Reviews, and reopen one rather than regenerating it. Scrum reviews are keyed by sprint and Kanban reviews by their date window, so regenerating the same sprint or the same window updates that review instead of creating a duplicate.
• Export to DOCX. Produces a formatted Word document with the title and filename matching your framework's naming. Useful for circulating to stakeholders who will not open the tool, or as a starting point if your organization has a house format.

Azure DevOps teams

Reviews work the same way, built around a completed iteration rather than a Jira sprint. Two differences are worth knowing:

• Azure DevOps iterations have no goal field, so there is no sprint goal to assess and Frankee will not invent one.
• Agile and Scrum process templates are supported. A project on an unsupported template is refused with an explanation rather than returning an empty review, since an empty review reads as a team that delivered nothing.

Tasks are excluded from both templates, so the numbers describe delivered value rather than implementation breakdown.

If something looks wrong

• No sprints in the picker. Only completed sprints appear. Check the team's board ID in Team Setup, since sprints resolve through the board rather than the project key. See Integrations.
• "End date must be after start date" or a span over 60 days on the Kanban picker. Adjust the window.
• The review says the goal is missing. That is accurate reporting: no goal was set on the sprint, or your tracker does not carry one. Frankee will not guess at one.
• Work you expected is absent. For Kanban, check that it was resolved inside the window rather than merely worked on during it.