Being a product owner is a tough job. Product owners often carry a heavy burden because they have to get a succession of decisions exactly right. And they usually need to do this while being extremely busy. Everyone seems to need some of the product owner’s time.
And that includes the Scrum team–not just during sprint planning and sprint reviews, but throughout the sprint! But finding and pinning down product owners in a timely manner can seem impossible, especially if the product owner is unaware of how vital it is that the team have frequent access to them.
Two videos follow that are designed to help Scrum Masters help their product owners. The first video introduces two ways to help re-engage product owners and what to do if a product owner is truly too busy to fulfill their role. The second video discusses three things to try that can help a busy product owner find time for the team. As always, a written version of the video content is included for your convenience.
Product Owners Inspect So Teams Can Adapt in Real Time
The phrase “inspect and adapt” is a big deal in the agile world. And that’s as it should be. Inspect and adapt are both important words. But they belong together.
There’s no point inspecting if you don’t go on to use what you learn to adapt. And adapting without first inspecting results in arbitrary changes.
Unfortunately, some product owners don’t take advantage of all the opportunities they’re given to inspect. These product owners often disengage during sprints. They might show up for a sprint planning meeting and probably for the sprint review, but throughout the sprint they are as elusive as Bigfoot.
I’ve got some tips that will help if your product owner is not spending enough time with the team during the sprint.
Two Ways to Help Reconnect Product Owners & Teams
The first thing I suggest is speaking with your product owner about the importance of staying engaged throughout the sprint, as opposed to just checking in at the beginning and the end. Point out that the team will benefit from feedback during development, that team members will have questions that need timely answers, and that working together is the best way to ensure success.
And note that I said to speak with your product owner about this. Email and chat software are great; they have their purposes. But I think you’ll be more persuasive if you actually speak with the product owner.
If you can’t persuade the product owner to connect more often throughout each sprint, here’s an easy next thing to try. Tell the product owner that they will be responsible for running the demo during the sprint review.
I prefer to have various team members run the keyboard to show the new features each worked on. But when faced with a disengaged product owner, I tell the product owner to be the one with hands on the keyboard.
I sometimes go so far as to imply it’s a Scrum rule that they give the demo. It’s not, of course. But I’ve learned that if they know they’ll have to demonstrate the product at the sprint review, they stay more in tune with what’s happening during the sprint. They don’t want to embarrass themselves so they stay more in touch with the work and the workers in the sprint.
Do You Have the Right Product Owner?
Product owners often disengage during sprints because they’re busy. If that busyness is self-made, we can sometimes help by showing the product owner how to be more effective or how to delegate parts of the job. (See the next section for more on how to help a harried product owner.)
But in other cases, the busyness is real and cannot be removed. If that’s the case and your product owner really is too busy to do the job, you may need a different product owner.
You probably won’t be successful at making this change if you go to the product owner’s boss and tell them you need someone different. But you can often succeed in getting a new product owner if you convince the current product owner to support the idea.
I do that by telling the product owner that they’re too busy for the job. They’ll nod along as I point out the obvious. I then tell them that they should instead be the key stakeholder. I tell them the key stakeholder is the person that the whole team—developers, Scrum Master, and product owner—are all focused on making happy. The key stakeholder has the right to get mad if the team doesn’t build the right features.
I often make it sound like this is an official Scrum or agile role. It’s not, but—you know what?—maybe it should be.
When I tell the overly busy, disappearing product owner that they may instead be the key stakeholder, the idea immediately resonates. They see that they can delegate the product owner responsibility to someone else yet retain the right to insist the product contain certain features.
This is often enough to encourage them to delegate the job to someone else or to support the organization in an effort to find someone. And of course, we should be looking for someone who has time to fully be the product owner without disengaging during the sprint.
3 Ways Scrum Masters Can Help Harried Product Owners
Sometimes you have precisely the right product owner for the role, but they just need some help with finding time for important work or with empowering the team in their absence.
Here are three ways you can help busy product owners.
1. Get on their calendar
One of the most useful ways a Scrum Master can help a product owner is by helping them make time for important work that could get pushed aside by the day-to-day emergencies of work.
For example, suppose your product owner needs to write acceptance criteria for the user stories for the next sprint. They hope to get to it on Monday. Doesn’t happen. They hope to get time on Tuesday. Doesn’t happen. Wednesday, same thing.
This happens because items on a to-do list are promises to ourselves, and we don’t treat those promises as well as we treat promises to others. Today I had two meetings and 7 things on my to-do list, such as making this video. I made all the meetings, because I didn’t want to let others down. But 4 items remain unstarted on my to-do list.
If your product owner is struggling to fit certain work into their week, offer to schedule a time to meet with them to help do it. Agree that tomorrow at 2 pm the two of you will meet to write the acceptance criteria for next sprint’s stories. The product owner will almost certainly make time for that shared task, whereas they probably wouldn’t if it were just an item on their own to-do list.
2. Encourage the team to answer its own questions
Another way you can help a harried product owner is to convince team members that they can answer some questions themselves. Some team members fall into a trap of thinking that their product owner needs to specify every last detail about every product backlog item.
That’s not true. Product owners need to specify the things about a product backlog item that are so important that the item will be rejected without them. But there are many smaller details about how something is implemented that can best be decided by the team.
For example, imagine a system with a screen that can be sorted by various columns. Now the columns can be sorted in ascending or descending order. Which column and which order should be the default?
If the product owner has a strong preference, they can absolutely state it and the team will need to sort in that order on that column. But lacking that strong preference, a decision by the team is likely to be just as good as one from the product owner.
As Scrum Master, help your team understand this. And where the product owner has not already stated a strong opinion, encourage team members to make a decision. They’ll probably make the right decision. If not, the product owner can redirect it as soon as they next see the product.
Sure, the team will occasionally have to backtrack and re-do some work. But that will probably not be much, probably won’t happen often, and needs to be balanced against all the time saved by not having to discuss every small issue like this in advance.
3. Be on the lookout for time-saving best practices
A third way you can help your product owner is by being on the lookout for time-saving best practices. You are more likely to be attuned to advances in how products are developed. For example, as Scrum Master you might have heard about story mapping or job stories shortly after each was introduced. It could easily be years before such innovations come to the attention of a product owner.
Keep your eyes open for advances in product development, agile, technology, and so on and bring time-savers to the attention of your product owner.
