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.”
Take Part
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 actively involve the team members in the product 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 strategizing 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.
Post a Comment or Ask a Question
14 Comments
I feel it very much depends on the levels of trust and courage with-in the team. Although the goal is to be completely transparent a technical team may not want to truthfully discuss their area of improvement with the person chiefly responsible for return on investment. I’d suggest only introducing the PO to the retrospective once that trust and courage has been built. I do take the point that with the right facilitator given the correct level of authority this could be a non-issue.
Thanks for your comment, Christopher. I’d be interested to understand why the team does not want the product owner to attend the sprint retrospective and would suggest making it the topic of your next one. If the collaboration between the product owner and team is not effective ad if both parties don’t trust each other, then it’s virtually impossible to create a great product and everybody loses.
I guess if the team is encouraged to participate in an overt manner during the retrospective, and if the PO takes the initiative to suggest new ideas and ways to improve, it might just get the team members to “open” up and participate in a more fruitful manner. The retrospective is important for a number of reasons, and one of the primary reason is for the PO to envision and suggest “new” changes to improve the current workflow and process. His or her attendance is essential in the retrospective.
It is very imperative for the PO to attend the retrospective. The sprint retrospective is fundamentally a stakeholder’s event, and since the PO represents the stakeholders’ interests in the project, he or she should ideally remain present in the meeting. Besides the “official” presence of the PO, the retrospective offers a unique opportunity to discover the client’s mindset, and avail an inner understanding about the project as well as the client’s expectations and project vision.
Roman – It seems that too often, retrospectives focus on the Development Team’s process, relationships, and tools. Your post here does a great job of addressing the need to address relationships across the entire Scrum team, including the extended team. What I see missing is that tools and processes for the entire Scrum team need to be addressed. If TDD is a valid topic for a PO to engage in, which I believe it is, then so is Lean UX user research and/or choice of wireframing tools is equally valid topics for the retrospective.
How do we make the retrospective process more inclusive of “discovery” type processes, relationships, and tools?
Hi Theron, Thanks for your comment. It’s a great idea to look at discovery practices in the sprint retrospective. But remember that Scrum is essentially a solution validation tool, a model that helps teams build a great product – a product with the right features and the right UX. Problem validation – figuring out the target market, the value proposition, the business goals and model – is not supported by Scrum. As a consequence, teams should start Scrum once they have successfully performed problem validation. For major updates of existing products, teams may have to stop doing Scrum to do some research and validation and then do Scrum again to develop the update, or to do both in parallel (if that’s feasible). Discussing these options is something that could and probably should be done in the retrospective. Do you agree?
Roman, Makes sense. We’re trying to do discovery in parallel to scrum and trying to use retrospectives to improve the ongoing discovery work processes as well. Has resulted in: “they” need to get better ay X, or thinking is silos so far. Is there a way to do retrospectives across Discovery -> Delivery?
(Interested in your thoughts on the best way to inspect the work products from Discovery as well. Is there “demo” of validated experiments?)
Hi Theron, I would suggest to explore how well running the two activities in parallel works for you. You may find that it is more beneficial to focus everyone on discovery if the discovery/validation effort is significant, for instance, when creating a major product update that addresses a new market segment.
I like to timebox the validation work, for instance, to one month. I also like to review the progress on a weekly basis based on the Vision Board/Lean Canvas/Business Model Canvas/Javlin Board or whatever tool is used to capture ideas and insights. I like to understand how many risks/assumptions have been addressed/validated and how many crucial risks and how much uncertainty is left on the board/canvas.
Does this help?
Mark – If I understand you correctly, you’re saying those three situations are where you may not want a PO in a retrospective.
But to me, they’re all really good cases of where the PO *should* be in the retrospective – if for no other reason than to counteract the fears you raise.
– “They may have a bigger title and represent power – they have to ask how the team will respond to this.”
If this is the case, not being in the retrospectives (being ‘elusive’) will only add to this feeling. The PO should be there, making the team feel at ease.
– “The team may have significant issues with the way they work especially in the first few sprints. How can they make their openness to feedback clear.”
Again, if the PO attends and is supportive, that’s a much better message to give off. If the PO isn’t made aware of ‘significant issues’ early on, that sounds like a big problem waiting to happen.
– “If the team decide to take on an improvement that they don’t want they have ask if it is in their position to comment.”
This is the most interesting one; in your example, the PO should be there *precisely because* the team wants to try TDD. That way they can work together on a plan. In my opinion, if would be perfectly reasonable for the PO to say, “that’s a great idea, but maybe not so close to the release”, and elicit feedback from the team. Perhaps there’s a reason why now is the perfect time; perhaps the team compromises and everyone agrees TDD should be trialled in three sprints time; perhaps they decide to timebox some initial research in the upcoming sprints. The point being, how could something like this be discussed *without* the PO being in attendance?
What you may have been saying, of course, is that POs shouldn’t attend retrospectives if they’re not very good POs…
Michael – as I just replied to Roman I’m saying that there may be times early in a team’s existence when the trust hasn’t yet been established. If it hasn’t then its important to establish rapidly.
Hi Mark, Thanks for your insightful comment. I find that product owners benefit from having a ScrumMaster who provides guidance on how to play the product owner role effectively – to make product decisions and to act as a team player – who suggests ground rules for the retrospective, and who prepares and facilitates the meeting. The latter may mean talking to the product owner beforehand to make him or her aware of what the retrospective is all about and to kindly remind the individual during the meeting to respect the ground rules. If a product owner is not willing or able to effectively collaborate with the dev team, then this should be addressed in the next retrospective. Do you agree?
Roman – I think we’re on the same page, I just wanted to play a counterpoint.
My general approach is do a safety check, possibly a blind safety check. Prompt question might be “Team would you be as open and honest as necessary if our PO was present.”
If the answer is affirmative – fantastic. If not I would use it as a discussion point in the retrospective. My question would be: “What would we need to do establish sufficient trust with our PO to invite to a future retrospective.”
Sounds great. Thanks for sharing your approach!
Roman – interesting post. I do remind PO’s to be careful when their relationship with a team is new there is a balancing act to be played when they are present at the retrospective.
– They may have a bigger title and represent power – they have to ask how the team will respond to this.
– The team may have significant issues with the way they work especially in the first few sprints. How can they make their openness to feedback clear.
– If the team decide to take on an improvement that they don’t want they have ask if it is in their position to comment.
Example of the later – a few years ago I had a very new, very aggressive PO working with a young team. The team were discussing improving their Engineering Practices (trying TDD in this case) and the PO said “I hear TDD is very powerful and that’s cool. However I have a very important release coming up in three sprints please don’t practice TDD before then”. As you can imagine those comments had a chilling effect on the team, not just wrt to TDD but also one morale. The release took alot longer then three sprints and the team took alot longer to build the momentum and drive they needed.
So I like having my PO’s involved in the Retrospective as long as they remember the Dev Team own how to achieve the goals the PO sets out.