How to conduct a retrospective?
The retrospective takes place after the sprint review and before the next sprint planning session, and is the team’s regular opportunity to improve how it works. Use this approach after each sprint and at the end of the project to capture lessons learned from the entire project.
- 12 steps
- Total time: 1 h 30 min
- Preparation: 15 min
- Result: A list of specific improvements to be carried forward into the next sprint, documented in DevOps.
Required tools
- Azure DevOps — The Retrospective extension in DevOps is used as a support tool for the meeting.
Plan the meeting
1.Schedule the meeting at the right time
Schedule the retrospective after the sprint review and before planning the next sprint, so that responsibility rests with the project manager.
2.Cut to the correct length
Adjust the meeting length to the duration of the sprint: typically 45 minutes for a one-week sprint, 1.5 hours for two weeks, 2.25 hours for three weeks, and 3 hours for one month.
3.Set up the meeting in DevOps
Use the Retrospective extension in DevOps as a support tool to gather input from the team before and during the meeting.
Follow the agenda's five steps
4.Set the goal
Establish the goals for the meeting in advance—for example, improving stand-ups, communication with stakeholders, or operating rules.
5.Collect data
Draw on everyone's experience and perspective from the sprint to create a shared pool of information.
6.Develop insights
Identify useful patterns in the information collected, and always ask why things happened the way they did.
7.Determine the next step
Identify the problems and challenges the team needs to address, and create a concrete plan for how they can successfully tackle each one.
8.Conclude the retrospective
Summarize the meeting, thank the participants, and consider how future retrospectives can be improved.
Use Start-Stop-Continue
9.Ask what went well and what didn’t
Have each team member identify what went well during the sprint and what did not go according to plan—without looking for someone to blame.
10.Ask what the team learned
Discuss what the team learned during the sprint that could improve the way they work.
11.Review the definition of “done”
Check whether the definition of “done” is still appropriate for the team, or whether it should be tightened as the team gains more experience.
12.Share the knowledge at the end of the project
At the end of the project, the knowledge gained by the project group is shared with all of ProsessPilotene as part of the final report.
Discussion
Ask a question or share what helped you.
