Reviewing the Sprint
Scrum is an iterative framework that proceeds through a series of Sprints. Each Sprint aims to produce a useable product or result. This is then reviewed and re-planned going into the next Sprint. Fixed communications and scrum meetings are defined within the framework to facilitate this.
Before each Sprint begins, there is a Sprint planning meeting. This looks at what will be undertaken in the next Sprint, based on the priorities of the remaining items from the Product Backlog and the team’s capacity. As work progresses, there are short, Daily Scrum meetings.
At the end of each Sprint, there are two meetings. The Sprint Review meeting looks at what was produced (based on the planned Sprint Backlog). The Sprint Retrospective looks at how these results were achieved and what could be changed in the next Sprint. It is all about making the next steps of the project more productive – and more enjoyable for the team.
What does the Sprint Retrospective look at?
The Sprint Retrospective is not about what was achieved in the previous Sprint, but how it was achieved. It should focus on what worked well during the Sprint, what did not work so well, and what else the team could be doing. Factors to look at include:
- Team practices
- Roles defined
- Tools and software used
- The working environment
- Anything else that team members deem relevant
The meeting is a chance for each team member to highlight what they thought worked well in the Sprint and what could be improved. The aim of the meeting is to produce a plan for specific improvements going forward.
Points raised and actions identified will need to be prioritized to allow focussing on the most important ones. Further Sprint Retrospective meetings can come back to those that are not actioned for the next Sprint.
The Sprint Retrospective is an important meeting, but one that is sometimes missed out. It is vital, though, for anyone looking to get maximum value out of Scrum.
Who should attend the meeting?
The Sprint Retrospective is for the whole Sprint team – including the Product Owner and Scrum Master. Everyone should be given a chance to raise issues that affect them. Points raised should focus on improvements and actions going rather. They should not be based on blaming other team members for problems, nor for promoting team members’ own agenda.
As a guide, the meeting should last around three hours. It could be less if the Sprint has been shorter than around one month, though.