Question

Who should be the participants in retrospective? Will it be only the team members OR should the Product manager, all the stakeholders and dependent teams also participate.

I am of the opinion that only the team should meet to discuss in retrospectives, else all team members will not open up. But one of the managers insist that all the stake holders should also be included.

Was it helpful?

Solution

Who should be the participants in retrospective? Will it be only the team members OR should the Product manager, all the stake holders, dependent teams also participate.

The purpose of the retrospective is for the scrum team to evaluate their performance during the sprint. In this meeting they can discuss:

  • What went well during the sprint?
  • What went wrong during the sprint?
  • What the team could do differently to improve?

The project stakeholders and product manager should not be involved as they were not part of the Scrum team on a day to day basis. The retrospective is for the scrum participants.

In my experience, I have found that stakeholders and product managers are not concerned about technical matters, development practices, hardware issues etc. which the development team encountered during the sprint. Their main concern is that the Scrum teams are producing the correct product, and they find this out during the product demos.

As for other dependent teams, they too should not participate in the retrospective either as they did not directly participate. However, a member/members of the Scrum team should, along with the Scrum master, definitely regularly participate in Scrum of Scrums with other dependent development teams to ensure that other teams are aware of progress, and so that knowledge can be shared.

OTHER TIPS

I would use the classic answer.... "it depends". Your work culture (how open people are) and your relationship with the PO influence this decision.

Ultimately, the goal of retrospective session is to look for an improvement. You may want to ask yourself (and team) whether having PO in your session will yield better result or worse.

I used to work in the team that PO is involved in the session and he really contributes a lot to our meetings from different perspective. Still, this is because he has a very good relationship with the team and everyone can speak openly.

Another option is to divide your session into "non-technical" and "technical" issues. After the non-technical issues are discussed, the PO can leave and enjoy his freedom. (Usually they should be happy about this). However, the Scrum master should be cautious on how are you going to prioritize the action items later as the team may value the team's items more than the PO's.

The stakeholders have their say at the end of the Sprint Review, which is their point of time to voice concerns, influence the possible forecast the upcoming sprints and give feedback.

The Sprint Retrospective is for the Scrum Team. In some cases only the Development Team and the Scrum Master are present at this meeting. The product owner should join, often the relationship with the product owner is part of what can be improved, so inviting him/her should make that process easier. Also, any changes to the DoD (that can be made as outcome of the Retrospective) need to be taken past the Product Owner, maybe the team missed an important reason (like legislation) for the things to be as they are. In the end the Product Owner is end-accountable for the product and it's quality, so he should have a say.

In the Professional Scrum Developer course we also include a remark that you might get a more open communication going by asking the Product Owner to leave the meeting at some point. If that is the case, the lack of transparency and trust should be addressed at some point in a retrospective in the future, I'd say...

Stakeholders have no place at the retrospective. If they want changes to how things are going they will need to go through the Product Owner. If there are issues between stakeholders and the team, it might be a good idea to do a separate meeting (not a retrospective) with the whole scrum team present (incl SM and PO) to put the cards face up on the table and work out the issues.

Have you asked the manager why he thinks these stakeholders need to be included? What does he want to get out of that meeting? Figure out which meeting would be the right place for that concern to be addressed and who should be the one addressing it. There might be a need to plan something that's outside of the standard scrum meeetings, which of course is allowed.

Relevant passage from the scrum guide:

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.

If there are issues related to for instance planning, collaboration and communication between the PO and the team members, then I suggest to invite the PO to the retrospective.

When you are doing planned product releases, it might be useful to organize a retrospective directly after the release, where the team and stakeholder can discuss the sprints that have lead to the release and come up with ideas to improve the way of working for the upcoming delivery.

There is no hard and fast rule on who to invite to the retrospective. The right answer will almost certainly change on a retrospective-by-retrospective basis. The right answer also depends on many things:

  1. The relationship between the PO and the team
  2. The relationship between stakeholders and the PO
  3. The relationship between your manager and your team
  4. The current issues that the team faces (are they more technical or more business-oriented?)
  5. And any number of other potential things (sorry to be vague...)

As the facilitator of the Retrospective, it is up to your Scrum Master to structure the Retrospective such that it will lead to continuous improvement. If that means involving key stakeholders, then those stakeholders should be invited. If that means a closed door session for just the core team, then the retrospective should be closed to external participants.

Since Scrum Masters have no hard power, a good Scrum Master would understand the need to seek input from the team, the manager, the PO, and relevant stakeholders in order to build consensus on who to invite each time. A good Scrum Master would build a positive relationship with your manager such that the manager will eventually understand why this flexibility is so important.

Licensed under: CC-BY-SA with attribution
scroll top