What Product Owners Should NOT Do During The Daily Scrum
The amount of damage Product Owners can do in 15 minutes is unbelievable.
The amount of damage Product Owners can do in 15 minutes is unbelievable.
Should Product Owners attend to the Daily Scrum? I guess many developers would say, “No, please!” Unfortunately, often Product Owners cause trouble during the Daily Scrum instead of being helpful.
Although the Daily Scrum is an event for the developers, Product Owners can attend it and add value to the collaboration. During my journey, I’ve come across some common problems caused by the Product Owner during the Daily Scrum:
The Boss: the meeting doesn’t start until the Product Owner is available. Developers ask the Product Owner what they should work on next.
Status Report: developers report to the Product Owner what they plan to do to achieve the Sprint Goal.
New Requests: The Product Owner brings new requests during the Daily Scrum even though they have no relation to the Sprint Goal.
The Daily Scrum lasts fifteen minutes, but the damage caused by some Product Owners can last months. Let me share with you what Product Owners should not do during the Daily Scrum.
If you are interested, you could also watch the following video on my YouTube channel. I hope you can benefit from the insights I share.
The Boss
It’s 09:15, time for the Daily Scrum. Peter joins the video call; the other developers are already there. Then, a conversation starts:
Peter: “Shall we start our daily?”
John (Scrum Master): “Harold is not here yet. Let’s give him two more minutes before we start.”
Peter: “Hum. It’s the third time already this week. He is always late.”
Harold joins the video call. He seemed to be in a hurry.
Harold: “Sorry, guys. I had to finish something very important. But, let’s start then. Björn, could you start? Please.”
Björn: “Yes, sure. Yesterday, I finished the API for the chatbot. Now I need something else to do. What should I take next?”
Harold: “I think you could start with the migration script. Then, maybe Peter could help you in case you need.”
Peter: “Well, I was planning something different, but it’d be fine for me to work on this with Björn today.”
What’s wrong with this example?
Developers didn’t start the Daily Scrum because the Product Owner was not present.
Harold, the Product Owner, assigned tasks to the developers.
Developers asked the Product Owner what to do next instead of being self-managing.
My example may seem exaggerated, but I’ve observed this situation multiple times. Generally, it happens with inexperienced Scrum Teams or with a Product Owner who loves micro-managing. Let’s have a quick look at the Scrum Guide. In bold, you can read the fundamental parts.
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.
The Product Owner is a peer to the other team member. Scrum has no hierarchy. If Product Owners fail to understand what self-management is, the Scrum Team will not produce a relevant outcome.
Status Report
Until the Scrum Guide 2017, the Daily Scrum was very prescriptive. Developers would answer the same three questions every single day:
What did I do yesterday?
What will I do today?
Do I see any impediment?
The Scrum Guide 2020 leaves the format of the Daily Scrum up to developers. This change helps Scrum Teams escape from the status report format.
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.
The status report happens when developers are reporting where they are and how to move forward. It may seem OK, but it’s not OK when developers share this information only for the sake of sharing. This deviation tends to happen if the Product Owner takes over the Daily Scrum. Some Product Owners want to micro-manage developers instead of helping them achieve the Sprint Goal.
Scrum has no place for micro-management. Developers are self-managed professionals.
If the Daily Scrum doesn’t help the developers to get closer to the Sprint Goal, the event was inefficient. Every day, developers should progress towards the Sprint Goal.
New Requests
Another massive mistake is to hack the Daily Scrum to place new requests. Sometimes it’s hard to hold on to our emotions. We may have a fabulous idea to share with the developers, but waiting for the right moment is a wiser decision. The most appropriate moment to share new ideas is the refinement sessions.
I’ve hacked the Daily Scrum with new requests many times. The result was always ugly. Some examples are:
Implementing a chatbot: once I presented a new idea to implement a chatbot, I wanted to get a quick resonance from the team. I couldn’t imagine the damage that question would cause. The developers were so curious about the chatbot that they couldn’t focus on the Sprint anymore. After the Daily Scrum, everyone was researching about chatbots. Unavoidably we didn’t achieve our Sprint Goal.
The pointless bug: software always has bugs, but not all bugs are worth fixing. Once, I had the brilliant idea to share with the developers a bug the customer service found. The impact was minimal, and the probability of it happening was also insignificant. Yet, the developer who worked on that feature previously decided to fix the bug. It turned out to be complex to fix. Once again, we failed to achieve the Sprint Goal.
After many mistakes, now, I reflect more before saying anything during the Daily Scrum. I ask myself the following questions.
Does this need to be said?
Does this need to be said by me?
Does this need to be said by me right now?
The Successful Daily Scrum
The Daily Scrum is an event for the developers. Yet, Product Owners can attend it and add value. As a Product Owner, I like being available for the developers. Showing up every day to the Daily Scrum is a way of doing that.
I still think it can be valuable for the Product Owner to attend for the following two reasons:
The Product Owner is part of the Scrum Team. By not attending an ‘Us vs. Them’ mentality may emerge. Scrum works best without sub-teams and a whole-team mindset.
Inspection at the Daily Scrum may lead to discussions where the input of the Product Owner is necessary.
— Maarten Dalmijn, What’s the role of the Product Owner at the Daily Scrum?
Once Product Owners understand they are part of the Scrum Team, it becomes easier to attend the Daily Scrum to help. In my opinion, during the Daily Scrum, Product Owners should:
Listen to the developers mindfully.
Help if someone asks for it.
Avoid influencing the developers’ daily work plan.
Trust the developers.
Avoid using the daily to micro-manage the developers.
Do you want to write for Serious Scrum or seriously discuss Scrum?