The sprint retrospective is a key mechanism in Scrum to improve the way people work. This article shares my tips on how you can use the meeting as the person in charge of the product to strengthen connections and improve the work.
The Retrospective in a Nutshell
The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices, to get even better at creating a great product.
The meeting takes place right at the end of the sprint after the sprint review meeting. Its output should be actionable improvement measures. These can range from making a firm commitment to start and end future meetings on time to bigger process changes, including switching from, say, Scrum to Kanban. The retrospective is not a finger-pointing exercise. As Mahatma Gandhi famously said: “Be the change you want to see in the world.”
As the Scrum product owner, you are a member of the Scrum team, which also includes the development team and the Scrum Master. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful digital product. If you don’t attend the retrospective, you waste an opportunity to strengthen the relationship and to improve the collaboration with the development team.
Additionally, taking part in the sprint retrospective allows you to understand why the team requires time in the next sprint to carry out improvements such as refactoring the build script, or investigating a new test tool; and maybe more importantly, it helps you improve your own work.
Say that some of the user stories the team had worked on did not get finished in the sprint. At first sight this looks like the development team’s fault. But analysing the issue might reveal that the size of the stories and the quality of the acceptance criteria contributed to the problem. As you are responsible for ensuring that the product backlog is ready, this finding affects your work: It indicates that you should improve the development team’s involvement in refining the stories to ensure that that they are ready, that there is a shared understanding, that they are feasible, and that they can be tested.
Be an Active Participant
Don’t make the mistake of attending the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant instead. Use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be collaborative and actively listen to the other attendees, but don’t shy away from addressing tough problems.
Here are some questions that you may want to explore in the retrospective:
- Is the communication between the team and you open, honest, and trustful? If not, how can you improve it?
- Are the development team members happy with the time you spend with them? Are you available to answer questions and provide feedback on work results as needed?
- Do the team members actively participate in analysing user feedback and data, refining the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to refine the backlog?
- Do the team members understand the big picture – the overall vision, the product strategy, and the product roadmap? Do you get sufficient help from the team with product discovery activities and strategy reviews, and do you actively involve the team members in product discovery and strategy work?
Hold a Retrospective with the Stakeholders
As important as it is, improving your collaboration with the development team and the Scrum Master is not enough. You will also benefit from trustful connections with the stakeholders, such as representatives from marketing, sales, customer service, finance, and legal.
A great way to improve stakeholder collaboration is to schedule a larger retrospective, for example once every two or three months. Here are some questions that you may want to explore in an extended retrospective:
- Do the stakeholders feel sufficiently involved in the product discovery and product roadmapping activities? Do they think that their ideas and concerns are taken into account?
- Do they regularly participate in joint meetings like product strategy reviews and sprint reviews? Are the meetings beneficial for them?
- Do you get enough support and commitment from the stakeholders? Do the individuals stick to shared goals and joint decisions?
You could discuss these questions one-on-one, of course. But jointly addressing issues and identifying improvement measures creates a sense of we-are-all-in-this-together; it helps create trust and it facilitates collaboration. Ask your Scrum Master to help you prepare and to facilitate the meeting. This allows you to contribute and share your perspective and needs.