A completed example
This fictional example shows the level of detail to aim for. It is not a customer's work history.
Sprint retrospective Team: Checkout squad Sprint: Sprint 14, March 3 to March 14 Meeting: March 14, 2:00 to 2:45 pm Facilitator: Priya Attendees: Priya, Marcus, Elena, Tom, Ayesha Sprint goal: Ship saved payment methods to all web users. Outcome: Partly met. Saved cards are live behind a flag for internal accounts. Public rollout moved to Sprint 15. Last retro's action items - Marcus: add a staging smoke test before each deploy. Done. - Elena: book design review in week one. Not done, review happened on day 6. What went well - Pairing on the card vault integration meant most pull requests merged within a day. - QA caught the expired card bug before release. What did not go well - The payments sandbox was down for two days and we had no fallback. - Three tickets were started without acceptance criteria and needed rework. - Tom was pulled onto a support escalation for most of week two. What we want to try - Write acceptance criteria during refinement, not at pickup. - Keep a mock of the payments API for local testing. Action items - Ayesha: build a mock payments server for local development. Due March 21. - Priya: add "acceptance criteria written" to the definition of ready. Due March 18. - Elena: book the Sprint 15 design review for day 2. Due March 17. Carried over - Public rollout of saved payment methods. - Error copy for declined cards, waiting on legal review.
Make it yours
Your draft
The example is fictional. Edits stay in this page and disappear when you leave. Copy or download your work to keep it.
How to fill it in
- Fill in the team, sprint dates, facilitator and attendees before the meeting so the discussion starts on time.
- Copy the sprint goal from planning and write the outcome plainly as met, partly met or not met, with what shipped and what moved.
- Open the meeting by reviewing last retro's action items and marking each one done, not done or in progress with a short reason.
- Write each point under went well and did not go well as a specific event with its effect, not a general feeling like "communication was bad".
- Limit action items to two or three, and give each one a single owner and a due date before the meeting ends.
Start from your actual work
On a Mac, Dayflow can help you remember the work behind the update. It drafts a timeline from screen activity. Export a date range as Markdown from Settings → Export. Review that record alongside your calendar and task tracker, then fill in the template above.
For a guided walkthrough, see exporting your work history or drafting a report with Claude Code. Check the assistant's draft before sending it.
Local AI keeps screenshot analysis on-device. Your own cloud provider or Dayflow Pro processes selected screenshots off-device. An assistant can receive the Dayflow data it retrieves in your conversation. Local storage does not make a cloud assistant conversation local. Read the data-flow guide before choosing a workflow.
Questions about this template
What should a sprint retrospective include?
Include the sprint goal and whether it was met, a check on last retro's action items, what went well, what did not, what the team wants to try, and a short list of action items with owners and due dates. Noting carried-over work is also useful, so the next planning session starts with an accurate picture of what is still open.
What is the difference between a sprint review and a sprint retrospective?
A sprint review looks at the product: the team shows what was built, often to stakeholders, and discusses the backlog. A retrospective looks at how the team worked: process, tools, communication and blockers. The review asks what was delivered, while the retro asks how to work better next sprint. They are usually separate meetings, with the retro held after the review.
How long should a sprint retrospective take?
A common guideline is about 45 minutes for a one-week sprint, scaled up to an hour and a half for longer sprints. What matters more than length is finishing with agreed action items. If the team regularly runs out of time, pick fewer discussion topics and spend the saved minutes on deciding what to change.
Can I use start, stop, continue instead of went well and did not go well?
Yes. Start, stop, continue covers the same ground with a stronger focus on changes. You can relabel the sections as start, stop and continue and keep the rest of this template as it is. Whichever format you use, keep the review of last retro's actions and the owned action items, since those make the retro produce change.
Should retrospective notes be used to evaluate individual team members?
No. A retrospective is a team process record, not a performance review, and using it to judge individuals makes people less honest in the next one. Write problems as events and their effects rather than blame. If a personal issue comes up, the manager should handle it in a separate one-to-one conversation.
How can I remember what actually happened during the sprint?
Check the sprint board, merged pull requests, incident notes and your calendar before the meeting. If you use a Mac, Dayflow can draft a timeline of your work from screen activity, which can jog your memory. Check that draft for mistakes and add meetings, calls and offline work it would not capture.
Use the right format for the next step
- Weekly status report for a concise progress update.
- Daily work log for a record you can come back to.
- Daily standup template for yesterday, today, and blockers.
Download Dayflow