Sprint review andretrospective

When to use

On the afternoon of the last day of every sprint. Hold the sprint review first, then the retrospective.

Roles

• Product Owner: leads the sprint review. You invite stakeholders and decide how the backlog changes.
• Scrum Master: facilitates both sessions, and leads the retrospective.
• Developers: demonstrate the work and take part fully in the retrospective.
• Project Manager: updates the milestone forecast at the review and raises any risk to the milestone plan.
• Product Manager and stakeholders: join the review to give feedback. They don't attend the retrospective.

Before you start

• Check which items meet the Definition of Done. Only those are shown.
• Prepare a working demo in a production-like environment, not slides.
• Invite stakeholders at least a week ahead, using the shared sprint calendar.

Steps: sprint review (1 hour)

1. Restate the sprint goal and say whether the team met it.
2. Demonstrate the done work. Developers show real software, in the order it serves the goal. Stakeholders try it where they can.
3. Gather feedback. Ask stakeholders what they would change and what they need next. The Product Owner notes each point.
4. Update the forecast. The Project Manager shows the milestone plan and says whether the next milestone is on track, at risk or late, and why.
5. Adjust the backlog. The Product Owner says which items move up, move down or are new, based on the feedback.

Steps: retrospective (90 minutes)

1. Set the stage. Remind the team the retrospective is a safe space, and review the actions from the last retrospective.
2. Gather data. Each person notes what helped and what got in the way this sprint. Bring the facts: the impediment log, Run time spent and how the sprint goal went.
3. Find patterns. Group the notes and vote on the two or three topics that matter most.
4. Dig into causes. For the top topic, ask why until you reach something the team can change.
5. Agree one or two actions. Each action is small enough to try next sprint, with an owner. Add it to the sprint backlog for the next sprint.
6. Close. Check in quickly: was this retrospective a good use of time?

Outputs

• Stakeholder feedback, and the backlog changes that follow from it.
• An updated milestone forecast: on track, at risk or late.
• One or two improvement actions with owners, added to the next sprint.

Pitfalls

• Slides instead of software. Stakeholders learn the most by seeing and trying the real thing.
• Showing work that isn't done. It sets wrong expectations. Leave it on the backlog.
• Too many actions. Ten actions get none done. Pick one or two and follow through.