Should the Product Owner participate in every Scrum event?

<< Agile Blog

To be clear: All events in Scrum should help the Scrum Team reach the best possible results and every team should work out their own way of working.

There are three roles in Scrum: Product Owner, Scrum Master and Developer (Developer Team member). They all form the Scrum Team. While there are some meetings reserved for all the team, like Sprint Planning or Sprint Review, there are also meetings reserved for Development Team only, like the Daily Scrum. I’ve seen instances where a ScrumMaster has rearranged the Daily Scrum because they couldn’t attend. This misses the point. The Daily Scrum is for the team not the Scrum Master!

Here are the events in Scrum and I’ll briefly describe the role of Product Owner in each of them.

Sprint Planning

Creating a short-term plan for an upcoming sprint from the Product Backlog. When a Product Backlog is well-maintained, then planning should be easier for a team. The role of the Product Owner at this meeting is to negotiate with developers what can be done in the following iteration. They are the only person who decides what order the work should be done in. It is the Development Team who decides how much work they are able to do. The Product Owner should listen to developers and then make their own decisions on the advice from the Development Team

If the Product Owner cannot make this meeting, the Development Team should take stories in to the sprint from the top of a backlog. It is therefore possible for the meeting to go ahead without the PO, but it is usually much better if the PO can attend.

Daily Scrum

I’ve worked with a variety of organizations who find this aspect confusing. The Daily Scrum is a working meeting, and *only* developers need to be there. However, easy access to the Product Owner during the meeting is likely to have some advantages. It certainly doesn’t mean that the PO must attend the meeting, but if the team needs clarification and the PO isn’t there then the team might have to go with their own best guess. A PO in attendance could clarify any concerns that the team may have. It is absolutely not a status meeting for the PO. A ScrumMaster should ensure that this doesn’t happen through coaching the team and the PO.

Backlog Refinement

It is possible to have a useful Backlog Refinement meeting without the PO there. For example, sometimes there are a lot of technical issues that the team need to discuss. However, as you’re refining the stories in the backlog, it would be usual for a PO to come along. When the meeting is about prioritizing the backlog or creating/removing stories, the participation of PO is crucial.

I’m working with a team at the moment who do daily backlog refinement, for just 15 minutes. The removal of longer, less frequent backlog refinement meetings is working well (we’ll keep experimenting though!).

Sprint Review

This is where the Team shows what they accomplished during the sprint. The role of PO here is very important, as ultimately, the PO decides what should be shipped. It’s always important in this meeting to discuss the Sprint goal and if the team has achieved it. Also, this meeting is where some stakeholders may attend so the PO can discuss the vision of a product and gather some feedback about stories already done.

Sprint Retrospective

The Scrum Guide says that the Sprint Retrospective is for the Scrum Team – that is the Developers, the ScrumMaster and the Product Owner. However, there is a potential conflict if the PO attends. The rest of the team may not be as open about things with the PO there. My “out of the box” suggestion to new teams is that the PO can attend, but by invitation from the Developers. Then if the team want a more private retrospective, they can. However, this entirely depends on the situation and the people. My advice is to experiment and find what works for you. Remember though, that the Product Owner is the one who can potentially take a look at problems from a different perspective, so please consider this.


Always remember to use the wisdom in your team, and always try new things. You can always count on a help of a Scrum Master.

<< Agile Blog