Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a Scrum Team of a Product Owner and four developers (one of whom is Scrum Master), running one week sprints. As per Scrumguides.org (emphasis mine):

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself...

So that includes the Product Owner.

Following the advice from Agile Retrospectives by Derby/Larsen we're trying to focus our meeting on one specific topic. We have iterations of one week, so we usually cover only one topic each week.

Now, at least half of our Retrospectives will be very tech-oriented: talking about how to spread technical knowledge between us and other teams, improving automated testing, trying new tools, et cetera.

Our Product Owner is not very technical at all, and will not be able to contribute all too much in this kind of Retrospective.

Any suggestions on how to deal with this? Do we do those Retrospectives with just the development team? Do we "need" to look for ways to include the Product Owner too?

share|improve this question
up vote 7 down vote accepted

Ideally the Product Owner will be present and will find the retrospective both interesting and rewarding.

However, if the Product Owner does not see their value in technical conversations then there are some things you can do:

  • Start the retrospective in the usual way but cover Product Owner related issues first, then allow the PO to leave and focus on technical issues.
  • Run two retrospectives, one for business/requirements related issues and one for technical issues.
  • Alternate between technical and non-technical retrospectives.

I'm not a big fan of the last two of these approaches. But I think the first one can be made to work.

share|improve this answer

Including product owner is always a good practice. Don't be afraid that he will not get it. After few retrospectives he should better understand tech story's arsing and overall complexity of a project. He is a part of a team too, and maybe he has a issues to share with.

https://www.mountaingoatsoftware.com/blog/the-product-owner-in-a-sprint-retropsective

share|improve this answer

The retrospective goal is, among others to

Inspect how the last Sprint went with regards to people, relationships, process, and tools;

Although you feel like most of the discussion will be around technical problems, that could not be necessarily the case. Not to mention that solving technical problems is a way to reach a business goal and add value, not an exercise in itself, so the PO can and should have a say on that.

share|improve this answer

Lots of good points already made.

One more to add: Sometimes the action item from a completely technical discussion will be adding an item to the backlog that is more technical. In order for the PO to be able to prioritise it against other items he needs to understand its value. So even a completely technical discussion is to a certain extent useful to him.

share|improve this answer

Preferably the Product Owner attends all retrospectives, this will help him/her to improve the way of working together with the team members.

Attending technical discussion can increase insight in the way that team develops their product and the effect of this on the quality of the product. For instance when the team has built up technical debt, they can discuss strategies together with the Product Owner to reduce the debt and to prevent degrading the quality further.

share|improve this answer

From Roman Pichler blog: The Product Owner’s Guide to the Sprint Retrospective

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.

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.