Subscriber only lesson.
Sign up to this course to view this lesson.
About this lesson
The Sprint Retrospective is a lessons learned meeting with a focus of identifying opportunities to improve the performance and management of the next Sprint.
Download this lesson’s related exercise files.Step 7: Sprint Retrospective.docx
207 KB Step 7: Sprint Retrospective - Solution.docx
Step 7: Sprint Retrospective
The Sprint Retrospective is a lessons learned meeting with a focus on identifying opportunities to improve the performance and management of the next Sprint.
When to Use Step 7: Sprint Retrospective
The Sprint Retrospective should always be done. It is scheduled to occur shortly after the Sprint Demonstration and before the next Sprint starts.
- The purpose of the Sprint Retrospective is continuous improvement, not to assign blame or create a final project report. Therefore the discussion is primarily about process and facilitation of the Sprint – not the actual results.
- The Sprint Retrospective is attended by the Scrum Master, Product Owner and all Scrum Team members – but not by senior management or the business team. If senior management or the business team has Sprint process issues that they want raised during the meeting, they should work through the Product Owner or Scrum Master.
- The lessons learned from the Sprint Retrospective are applied in the next Sprint.
- Two primary questions are asked at a Sprint Retrospective:
- What went well during the Sprint that should be continued in subsequent Sprints?
- What could be improved on the next Sprint?
- The Scrum Master normally facilitates the meeting and documents the conclusions in order to remind the Scrum Team during the next Sprint and to share with other Scrum Masters in the organization.
Hints and Tips
- This is a very powerful meeting if the Scrum Master keeps it focused on: 1) “What did we do well that we want to continue?” and 2) “What do we want to change?” Don’t let it become a design review or turn into a heavy dose of blame or personal attacks.
- However, the team does need to hold each other accountable. If someone made a commitment with respect to the Agile/Scrum process (such as agreeing to be 100% dedicated) and then didn’t follow through (the individual took Fridays off to go fishing) the team should confront one another.
- These meetings normally last about one to two hours and have a tendency to pump energy into the team as they are eager to go and try the improvements they have identified.
- The finding from the museum website upgrade example are similar to the types of findings and actions that I have seen with other projects.
- Things to continue: estimating process, overall teamwork, and the use of the Scrum meetings
- Things to improve: earlier acknowledgement of roadblocks, and quicker reviews with the Product Owner.
Lesson notes are only available for subscribers.
PMI, PMP and PMBOK are registered marks of the Project Management Institute, Inc.