Product owner unavailable

Clint Patterson

In theory, product owners make themselves always available. Ain’t gonna happen.

Even the most available product owner has meetings, goes out of the office, works on another project and engages in manner of other opaque ‘management activities’. Development team members have to deal with this. They have to learn to stalk the product owner.

Availability matters

Product owner availability matters, because Scrum relies on just-in-time functional specification, in the form of a face-to-face conversation between the developers who implement user stories and the product owner who describes them. This works because making functionality decisions as late as possible allows you to make the most informed decision, and because face-to-face conversation offers the second-highest bandwidth form of communication. (Face-to-face conversation with a whiteboard improves the information flow.)

An absent product owner results in zero communication bandwidth. In the worst case, development stops and the product owner doesn’t know that they have limited the team’s productivity.

Tactics for the team

The development team can adopt three tactics to work with an occasionally absent product owner.

1. Find as many communication channels as possible: e-mail, direct messages, group chat, issue tracker, etc. Experiment and find out what works, beyond camping out at their desk.
2. Use every channel necessary to let the product owner know that a story will only make further progress after a discussion. Ping them to let them know that you need them.
3. While waiting, prepare questions and send them to the product owner in advance. Leave a note so they can find and think about the question before you catch up with them.

Although you can’t see the product owner at their desk, or they haven’t responded quickly to a message, they might have to option to interrupt their current activity. Software developers often give up when the product owner doesn’t appear available, because they make their own work less interrupt-driven and meeting-based than management work.

Secondly, coming up with a clear question makes up half the work in a conversation about software requirements. Before going to ask the product owner a question, first writing it down makes it easier to see whether you have a coherent question. If you do this in an issue tracker or feature document, you can later edit the text and record the answer, to expose the decision to other people in the future.

Keep it simple

If you have a straightforward enough question, you may get a one-word answer from a product owner while they work on something else. After all, in some companies, product owners spend half their time stuck boring meeting.

Finally, don’t forget to try the simplest thing you can do: put a big ‘your team needs you’ sticky note on the product owner’s monitor. You never know, perhaps they went to get a coffee and will appear minutes later.

Scrum theory tells you to expect an always-available product owner in the room; in practice, team members may need to stalk the product owner