Welcome to another episode in my blog series on “Anti-patterns that Doom a Product Owner to Fail“. In this blog, I’ll address the many ways a Product Owner can undermine the Scrum Team by causing Scrum Events to go bad. Let’s explore the many ways this can happen:
The Product Owner participates in the Daily Scrum
Problem
The Product Owner attends the Daily Scrum and actively participates in the meeting, rather than being a silent observer. When a PO talks during Scrum, it’s a disruption to the team; their focus should be on creating their plan for the day. If a Product Owner is constantly interjecting or conversing during this event, it will quickly go off the rails.
Solution
The Daily Scrum is a meeting for the Developers, not the Product Owner. That said, the Scrum Team may include the Product Owner, so s/he can keep tabs on how things are going and be available to answer any questions post-Scrum. But the Product Owner should only attend if s/he can remain silent and only engage with the team when asked.
The Product Owner leads the Sprint Review
Problem
The Sprint Review, like the Daily Scrum, is an official Scrum event. The Scrum Guide isn’t too prescriptive, but the Sprint Review is an opportunity to inspect the done increment and gather feedback. Unfortunately, the Product Owner often feels that s/he should take credit for the entire team’s work. Instead of giving credit where credit is due, the PO prohibits the Developers from presenting their work.
Solution
The Product Owner may facilitate this session, but the Developers are the ones who did the work, so they should be allowed to showcase their accomplishments. The Product Owner should sit back and listen rather than leading the review. At the end of the Sprint Review, the PO may preview the upcoming Sprint, with the caveat that it’s a forecast, not a promise, of the plan for the next iteration.
The Product Owner skips required Scrum events
Problem
The opposite problem of having the Product Owner showing up or taking control of a Scrum event is when the Product Owner doesn’t bother to show up at all. When this happens, the team doesn’t have any guidance. As part of the Scrum Team, the Product Owner should attend most of the Scrum events. If the PO skips required meetings, there could be a loss of trust and transparency.
Solution
The Product Owner MUST attend all required Scrum events. If s/he isn’t attending as expected, the team should try to get to the root cause of the problem and solve it. If the Scrum Team can’t resolve the issue independently, they should escalate to the Scrum Master, who will work to remove this serious impediment.
Scrum events are misused to gather new requirements
Problem
Each event in Scrum has a specific purpose. When the Product Owner or other team members hijack a meeting and turn it into something else, it’s a problem. I have repeatedly seen Sprint Reviews become not just a place for inspecting the increment but rather a full-blow requirements elicitation session. When Scrum events are misused, it’s confusing to stakeholders and distracts the team from achieving the intended outcome of the event.
Solution
If additional meetings are needed to do activities such as requirements elicitation, they should happen outside the official Scrum events. There is nothing in the Scrum Guide that says no other meetings should happen. It is implied that backlog refinement should happen but doesn’t specify how or how often. It’s up to the team to determine what other meetings make sense and reserve the Scrum events for their intended purposes.
A Sprint that should be terminated isn’t
Problem
As you should know, the only person who can terminate a Sprint is the Product Owner. There are very few reasons for an iteration to be canceled, but it should be canceled if the Sprint Goal becomes obsolete. If the team keeps working on items that are no longer relevant, you will waste time and money.
Solution
If it becomes evident that the Sprint Goal is obsolete, it is the Product Owner’s responsibility to terminate the Sprint immediately. Likewise, if other mitigating circumstances warrant canceling a Sprint, the PO should make the call as soon as possible. By acting sooner rather than later, the PO can save the organization money, and the Scrum Team can be repurposed to work on more valuable items.
Lack of preparation
Problem
Have you ever shown up to a meeting, but no one was prepared? I have seen this too many times in my career to try counting. Unfortunately, in my experience, this is more common than not. But because the work of a Scrum Team is visible and transparent, a Product Owner‘s lack of preparation is immediately noticeable.
Solution
As a Product Owner, you should always prepare for your Scrum events – official or unofficial. It would be best for you to have a plan, whether formal or informal. Any required pre-work, such as performing research, having user stories ready for review, etc., should be done before the meeting. Don’t show up unprepared – it makes you look bad, it’s unprofessional, and it will damage your reputation.
A unifying Sprint Goal isn’t created
Problem
I admit I am guilty of not always ensuring that my team defines a Sprint Goal for a Sprint. I’m not sure why, or if it’s just me, but somehow this vital aspect of Scrum ends up getting skipped. The whole point of a Sprint Goal is to provide a clear target for the team to achieve. Without a unifying goal, the team could end up choosing to work on the wrong things.
Solution
As a Product Owner, don’t forget to establish a Sprint Goal when you do your Sprint Planning. It’s essential to craft a Sprint Goal that everyone can agree on, and as with the overarching Product Goal, the Sprint Goal is a specific target the team can achieve. With a clear target, the team is much more likely to accomplish its goal.
Final Thoughts
Scrum events each have a clear purpose, with expected inputs and outputs. First, make sure the right people are at the appropriate events and that everyone knows who can participate. Second, don’t let your events get derailed by repurposing them for other activities. If you need to have additional meetings, go ahead, but make sure they add value and are not a waste of everyone’s time. Finally, don’t forget to create a Sprint Goal for each Sprint, so you know what you’re trying to accomplish.
Now, it’s your turn. Have you ever seen a Product Owner cause Scrum events to go bad? How did it happen? What was the impact? Is there anything you would do differently if you could do it again? I would love to hear your Scrum horror stories of how Scrum events went awry. Let me know below!