Is the Scrum Guide Wrong About the Product Owner?
A recent conversation[1] reminded me that the ScrumGuide says neither the ScrumMaster or Product Owner are required to attend the Daily Scrum. But does that mean that they shouldn’t attend? The Scrum Guide is overly formal and can be hard to interpret. (I get it, I tend toward the formal too often myself).
Here is the entire section on Daily Scrum from the ScrumGuide:
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.
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.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
The key sentence is: “If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”
Translation: So if they’re doing stuff for the team, they should attend the Daily Scrum - not as important people but as regular team members.
Good? Bad? Or just poorly written?
Let’s step back and consider why we hold Daily Scrum.
Why Daily Scrum?
The intent is to inspect progress toward the Sprint Goal and update the Plan/Sprint Backlog based on what we learn. When I’m helping people understand Scrum, I frame Daily Scrum as having three main purposes:
- Transparency - Check our progress toward the Sprint Goal
- Replan - Update the Sprint Backlog
- Collaboration - Daily Scrum gives us insights into what others are working on and where we can help. (Hint: Pair Programming).
What is the Product Owner’s Role?
The Scrum Guide defines the Product Owner’s role like this:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
It says a bit more than that, however this is enough for our purposes.
So if their job is to help maximize value for the team, should they attend Daily Scrum in their role as the PO?
Should the Product Owner Attend Daily Scrum?
It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
Here’s what I’ve seen work:
- Clarifying user story questions immediately: If it is quick, they can clarify in the moment. If not, they can help right after the Daily Scrum.
- Request a Demo:They hear about progress and want to know more. They can ask for a quick demo right after the Daily Scrum. They get a better understanding and often help by making minor suggestions. (Hint: the team have a right to say “not yet” if the suggestion isn’t minor.)
- Sprint Goal: They keep up to date on progress or impediments related to reaching the Sprint Goal. If the team is missing information about a user story/feature, the Product owner can go find answers. If the impediment is access to resources outside the team, the PO might have the influence to get it.
- Sprint Backlog Updates: The PO can stay informed about changes to the Sprint Backlog and provide support if needed.
- Collaboration Opportunities: The Product Owner can help by testing usability or digging into the details of acceptance criteria.
- Product Backlog Updates: Occasionally, the PO will learn something from the Daily Scrum that helps them reprioritize the Product Backlog.
When should they not attend?
- If they’ve not yet learned to balance their authority with the rules of the Scrum game. For example, some POs will yell “fire” in the middle of a Sprint and demand a new User Story.
- If they’re acting as an order taker for stakeholders, rather than the person responsible for maximizing value of the product.
- When there’s a risk of micro-management. Some POs will try to use Daily Scrum and other opportunities to look over people’s shoulders and tell them what to do. Micromanagement is an Antipattern
- When it inhibits open communication. Team members may not feel comfortable sharing information with the Product Owner. If this is the case, I would suggest that the Scrum Master works on improving Psychological Safety.
Takeaway
I think the Scrum Guide is either poorly framed or outright wrong on this point. The Product Owner should attend the Daily Scrum. All of the cases where they shouldn’t attend, are cases where they’re not playing their role well. (With the exception of micro-management, in which case it might be the wrong role for them to be playing). So if PO’s attendance at Daily Scrum is harming the team, the Scrum Master should be coaching the PO on how to play their role more effectively, and/or improving psychological safety. In the long run, the Product Owner should attend Daily Scrum as the Product Owner and not as a Developer.
As for the ScrumMaster attending Daily Scrum, that’s a whole different conversation for another day.
Join us for our next Lean Coffee where you can ask questions and practice helping others.
Footnotes
Image attribution: Agile Pain Relief Consulting (August 2025)

Mark Levison
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org and AgileAlliance.org.