Should A Product Owner Attend The Daily Scrum?
Should Product Owners attend the Daily Scrum? I am asked that question on a regular basis.
So let’s put this one to bed together officially.
We’ll start by examining the Scrum Guide, then delve deeper via pragmatic real-life experience. Finally, we’ll close with an analysis of how Product Owner attendance can hijack the Daily Scrum and how to make their attendance an enriching experience instead.
Scrum Guide: The Rules of the Game
The updated 2020 Scrum Guide clearly states the following:
“The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”
According to this sentence, it’s not that the Product Owner should or should not attend – it’s that they don’t need to unless of course, they are “pulling backlog” like the Developers. So, if these simple sentences are so clear, why is there any confusion or even a question about their attendance?
As it turns out, the Scrum Guide may give us more insight that would lead towards a need for Product Owner attendance.
Later in the same section, it says:
“Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.”
Promoting quick decision-making is an essential reason for holding Daily Scrums.
As the data from the Chaos Report from the Standish Group reveals, decision latency (the time it takes for a decision to be made) is the key factor in project success. If those decisions involve changing the priorities of the Product Backlog or prioritizing interrupts over the work in the Sprint Backlog, the Product Owner’s input could be viewed as required at the Daily Scrum.
There are other lines in the Scrum Guide that provide further elucidation. In an earlier portion, it explains:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
and
“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”
So, these taken together could equate to a rational argument as to why the Product Owner should be at the Daily Scrum.
After all, if the entire team is accountable for the Increment, and the entire team is responsible for all product-related activities, and the Product Owner is part of – not apart from – the Scrum Team, then they should be at the Daily Scrum!
Talk from the Trenches
Now let’s put the Scrum Guide and theory aside, and examine what we have learned from the field. I polled a group of experienced Scrum practitioners. Here is some of what they said:
“The Product Owner belongs at the Daily Scrum. The absence of any single person signals that they are NOT part of the team. They should not use it to ask for updates or otherwise direct the meeting. They should LISTEN to what the team has to say and OFFER an update of their own. If this event is used to directly or indirectly impose a sense of importance or hierarchy, it dramatically loses its value.” – Toby Johnson, Senior Product Manager
“The internal Scrum Roles ought to temporarily dissipate to leverage a space of psychological safety since the Daily Scrum is a pulse check of “The Team”. While this is not an event to appease or provide a status update to the Product Owner, they could attend but as a member of the team and not only wearing their Product Owner hat.” – Roy Nanku, former NavalX Military Scrum Trainer & current Scrum Inc. Consultant
“In my experience, the Product Owner needs to be at the Daily Scrum because there are always issues around things popping up, all around prioritization of the ‘what’. ” – Jessica Crowley, former Project Controller for a large train brake manufacturer & Enterprise Agile Coach, current Scrum Inc. Consultant
So, it seems that we have consistent data around having Product Owners attend, but that it’s not without complications. What are the major hijacking behaviors Product Owners exhibit? Let’s list them and then examine the fixes.
Hijacked! (And Getting Back on Track)
According to the Scrum Guide, “the purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” Understanding work item status and what’s preventing it from moving forward is a main ingredient in adjusting the upcoming planned work.
Teammates jumping in to help each other (sometimes called “Swarming”) is a beneficial pattern we hope to see coordinated at every Daily Scrum.
At the end of the day, it’s all about behaviors. Anyone can hijack or derail the Daily Scrum and render it unproductive or degrade it into solely a status meeting. While the status of work is important for everyone to know, what is more important is to find ways as a team to drive it all to done.
What Product Owner behaviors can derail a Daily Scrum? And how can we avoid or cure them? Here are five main categories (with examples) we commonly see and how to fix them.
1) Micro-Management: the most debilitating behavior we see is when Product Owners get into the weeds of every little thing the Scrum Master or Developers do. One example of this is when they cross over into dictating the “how” instead of the “what” and crushing innovation.
A second example is when they act like traditional Project Managers and assign work to people. A third example is when they are overly focused on team output metrics, like velocity, and constantly questioning why backlog items aren't moving.
Cure: Stay out of the HOW! Everyone knows the Product Owner has input, but it’s better to let the team dazzle you with their brilliance. Instead of dictating how things should be done, speak last, and use questions to expose flaws in logic in a positive way or push the team to think further outside the box. This is particularly tough when the Product Owner is also a Developer, so be mindful of that. Don’t assign work to Developers. Let them pull what they want to do and have the capacity for. Coordinating that is their job facilitated by the Scrum Master, not the Product Owner. Stay focused on outcome metrics and let the team be guided by output metrics (ex. velocity, plan/do ratio, etc.). The team’s ability to self-manage is important to creating a culture of autonomy alongside accountability.
2) Loving the Spotlight: There are three common versions of this behavior. The first is running the meeting. This is an expression of micro-management. Especially if it’s run in a way that gets them the information the Product Owner wants versus the Developers getting the information they need to maximize the likelihood of achieving the Sprint Goal. The second is acting as a single-person audience to whom the team members must present what they have done. The third is being viewed as (and accepting the role of) the single source of answers.
Cure: One, don’t facilitate the Daily Scrum. Unless it’s your turn according to a working agreement or some other arrangement. Let the Scrum Master help the team figure out who should do it if it’s not the Scrum Master themself. Two, don’t let the Developers speak only to you. Encourage them to speak to the group; let them feel comfortable that you’ll chime in if you need to. This includes the body language of them not facing you the entire time. Three, be conscious of team members treating you as an encyclopedia. Foster conversations between team members with answers like, “Thanks for asking me. Before I reply, I’d like to hear from others here.”
3) Inappropriate timing of new requests: Of course, the team needs to know about new requests, but do they need to know today? Putting new requests "out there" to hear the team’s ideas, just to let them know, etc. can be very disruptive to the current work. It puts their brains in a problem-solving mode for the new things and draws their focus away from their current commitments.
Cure: Introduce new requests at the proper time. If it’s truly an important interrupt, then the Daily Scrum is perfect for that. If not, then the best time to introduce them is at Backlog Refinement. As a backup plan, it could be done as part of a Sprint Review. In any case, be judicious about the timing of your presenting new requests and think about how it will affect the team’s focus and commitments.
4) Lateness or unannounced skipping: Product Owners spend a lot of time with customers and stakeholders, often at the expense of time with their team. This can leave them feeling neglected or that being part of the Scrum Team is less important than the rest of the world.
Cure: Expect to act like any other member of the team and show up on time. If you can’t make it, adhere to whatever working agreement your team has around lateness or telling each other you can’t attend. The team knows you’re not going to make every Daily Scrum. Be conscious of how many times you miss it and other events and see if things are getting out of balance. Make a point to block your calendar for the Daily Scrum (and other events) so your teammates know that being with them is just as much a priority as speaking with those they are in service of.
5) Lack of crucial information: While we are encouraging Product Owners to share when appropriate, it can also be disruptive when the answers the team seeks cannot be had due to a Product Owner’s being out of touch with customer needs or feedback.
Cure: While being present with the team is to be lauded, a Product Owner still must balance their time with customers and stakeholders. After all, the point of those interactions, and the Product Owner’s role in general, is to help translate those needs and the information around them into an actionable backlog for the team. Without it, impediments can be generated the team cannot clear. Make sure you attend every Sprint Review and learn how to foster good product feedback and how to capture and distill it into a digestible format the team can use.
Conclusion
Should Product Owners attend the Daily Scrum? Product Owners should be at the Daily Scrum as they are a member of the team who has critical information to share. They do need to remember that their presence can be beneficial or detrimental and it’s up to them to embody behaviors that promote team agility and not derail necessary conversations.
English 
French 
Spanish