YES, THE PRODUCT OWNER NEEDS TO BE AT SPRINT RETROSPECTIVE — BY AGILECOCKPIT
Throughout my career as a Scrum Master, Agile Coach and Professional Scrum Trainer there is not a single misconception I’ve heard more than “the Product Owner should not be at Sprint Retrospective”.
As I was teaching a Professional Scrum Product Owner (PSPO I) class recently, this misconception popped up again. When asked why some of the group thought the Product Owner should not be at Sprint Retrospective, the answer was “because he or she is not part of the team and should let the team and the Scrum Master have the retrospective in peace”. Another group then said, “well, for us he or she is part of the team, but in our experience the Product Owner and the team don’t get along that well — so for our team it’s better to have that safe conversation without the Product Owner”.
Both examples are very telling to me and are the most common examples I hear. They are typically symptoms of the actual problem though: a sub-optimal Scrum implementation and a Scrum Master that does not uphold Scrum.
What the Scrum Guide says
The Scrum Guide is very clear. The Scrum Team is composed of the Product Owner, the Scrum Master and the Development Team.
It also states: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
Meaning, if you don’t have the entire Scrum Team at Sprint Retrospective, you’re not inspecting and adapting the full Scrum Team. So whatever improvements you might come up with at Sprint Retrospective might by definition be sub-optimal because it was not an improvement made by the full team that does Scrum.
This is exactly what happens if you have a Sprint Retrospective without the Product Owner present: you’re missing an important opportunity to inspect and adapt the full team.
Why is that so bad? So we don’t inspect and adapt the full Scrum Team. Big deal!
Say you’re running a relay race with a team of four and your team always finishes last. In order to improve, you would need to look at (inspect) the team as a whole, and make changes (adapt) to those parts of the team not running smoothly.
What would happen if you would just inspect three of the team members and not include the fourth? What are the risks of sub-optimization and not fixing the actual problem? They’re pretty high, since you’re not looking at the full picture. And even if there’s no problem top fix, how would you know you’re not missing a great opportunity to improve as a team? You wouldn’t, since you’re only looking at part of the picture.
Now compare that to leaving the Product Owner out of Sprint Retrospective; you’re not inspecting the whole and you’re not adapting the whole.
Scrum Teams work together very closely and with each person having a specific role. Not including all roles in your inspection and adaptation process will only give you a partial picture. It will not enable you to identify problems that affect you as a Scrum Team and you will not be able to resolve them. And because of the way Scrum Teams operate, not inspecting the whole Scrum Team can do irreparable damage to your team in the long term.
And even if everything is running smoothly you are missing a chance to further improve as a team, which is part of the immense power of Scrum.
… the team doesn’t trust the Product Owner and if the Product Owner is there the team is not likely to speak up.
In this scenario, the problem seems to be the absence of trust between the Development Team and the Product Owner. This should be a reason to have a Sprint Retrospective with the full Scrum Team, as only they can fix this. Not doing do will only make things worse.
… the Product Owner is never there, so the team just goes ahead without him/her.
If the Product Owner is not involved enough to be part of Sprint Retrospective, then what else could be wrong? And again, this is exactly the kind of thing that should be addressed in Sprint Retrospective, so having one without the Product Owner would make things worse, not solve them.
… the Product Owner is the manager of the team and that doesn’t encourage an open an honest conversation.
In a Scrum Team everyone should be equal, yet I understand the reality of the Scrum Roles being actual roles and not HR functions. So, you could end up in this scenario. Still — will the problem be fixed with the Product Owner not being at Sprint Retrospective? It would still mean the Scrum Team is not inspecting and adapting itself, but rather a sub component of it.
Fixing the problem
If the above resonates with you and you are currently experiencing a situation where your Product Owner is not at Sprint Retrospective, here are some things you could try to get them more involved.
- Invite them to every other Sprint Retrospective to start with. This allows the team to get used to the Product Owner being there while at the same time allowing their usual safe space at every other Sprint Retrospective. Give this a shot for 4–6 Sprints and inspect and adapt after that time.
- Try to fix the underlying problem. If your Product Owner is manager for the team, for example, try and see if you could change that. This could reset relationships to be more compatible with the setup of a Scrum Team.
- Have two Sprint Retrospectives, or two parts. This is a tactic I have personally used in the past to tackle this problem. We would split the time box of Sprint Retrospective in two and use the first one for the Development Team and Scrum Master. This would allow us to set up topics that we wanted to discuss with the full Scrum Team right after. Eventually, the two merged.
Not having your Product Owner at Sprint Retrospective, regardless of how appropriate or fitting it might sound, is never a solution to the real problem. Even more so, it’s unhealthy and damaging to the Scrum Team.
If your Product Owner is currently not attending Sprint Retrospective, try fixing it with some of the suggestions above — or reach out to me to discuss further.
Like to learn more about being a Product Owner?
Are you currently a Product Owner? See how you’re doing by taking the