The Product Owner’s Guide to the Sprint Retrospective

By Roman Pichler, 17th June 2014

The sprint retrospective is the key mechanism in Scrum to improve the way people work. Some product owners believe though that they should not attend the meeting, and if they do then only as guests and not as active participants. But the retrospective does not only benefit the development team and the ScrumMaster; it is also an opportunity for the product owner to learn and improve, as this post explains.


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 outcome 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. 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 product owner, you are a member of the Scrum team, which also includes the development team and the ScrumMaster. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful software product. If you don’t attend the retrospective as the product owner, you waste the opportunity to strengthen the relationship and to improve the collaboration with them.

TheScrumTeam

But there is more to: Taking part in the sprint retrospective allows you to understand why the team requires some 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 may well 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 shows you that you have to decompose the user stories further and it suggests that the development team’s involvement in getting the stories ready should be improved – otherwise you would have spotted the issue before the stories went into the sprint.

If you had not been in the retrospective would you then whole-heartedly support the resulting improvement measures and change the way you work?


Be an Active Participant

Don’t attend the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant, use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be constructive and collaborative but don’t shy away from tough problems.

POAsActiveRetroAttendee

Here are some questions that you may want to explore in the retrospective:

  • Do you spend enough time with the development team? Are you available to answer questions or provide feedback quickly enough? Do you provide the right level of feedback and guidance in the right way?
  • Is the communication between the team and you open, honest, and trustful?
  • Does the team know how the users employ the product?
  • Are the team members happy with their involvement in analysing user feedback and data, changing the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to “groom” the backlog?
  • Are the team members aware of the big picture – the overall vision, the product strategy, and the product roadmap? Do you get enough of the team members’ time to help you with product planning and product roadmapping?

Improve the Wider Collaboration

As important as it is, continuously improving your collaboration with the development team and the ScrumMaster is usually not enough. You also need strong relationships with all the other people required to make the product a success. These include individuals from marketing, sales, customer service, finance, and legal, as the following picture shows.

POWiderCollaboration

A great way to review and improve the collaboration with your partners from marketing, sales and so forth is to invite them to the retrospective on a regular basis. Depending on how closely you collaborate, this may range from once per month to once per major release. A joint retrospective will help you develop closer and more trustful relationships, help smooth the launch of new product versions, and improve selling and servicing the product.

Here are some questions that you may want to explore in an extended retrospective:

  • Are the partners from marketing, sales etc. involved enough in the product planning and roadmapping activities?
  • Do they regularly participate in the sprint review meetings? Are the review meetings beneficial for them? Do they understand the project progress?
  • Do they receive the information necessary to carry out their work in a timely manner, for instance, to prepare the marketing campaign and to compile the sales collateral?
  • Do you get enough data and support from the partners, for instance, regular updates on the sales figures and the market feedback you require?

You can, of course, also discuss these questions one-on-one. But getting any issues on the table and discussing improvement opportunities creates a sense of we-are-all-in-this-together; it reaffirms the need for collaboration and teamwork to provide a great product; and it can break down departmental boundaries.


Learn More

You can learn more about the sprint retrospective meeting and the product owner by attending my Certified Scrum Product Owner training course. Please contact me if you want me to teach the course onsite or if you would like me to run a product owner workshop at your office.

Source: http://www.romanpichler.com/blog/product-owner-sprint-retrospective/

RSS Feed

14 comments on “The Product Owner’s Guide to the Sprint Retrospective

  1. Christopher Davey

    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.

    • Roman Pichler

      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.

  2. Scrum tool

    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.

  3. Product owner

    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.

  4. theronkelso

    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?

    • Roman Pichler

      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?

      • Theron

        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?)

        • Roman Pichler

          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?

  5. Michael Duxbury

    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…

    • Mark Levison

      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.

  6. Roman Pichler

    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?

    • Mark Levison

      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.”

      • Roman Pichler

        Sounds great. Thanks for sharing your approach!

  7. Mark Levison

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *