We all have to start somewhere, becoming an awesome product owner (PO) is not something that happens over night. It takes a lot of coaching, communication and enthusiastic engagement from the PO to make that happen. What can you do as a scrum master (SM) to guide your PO down the path and help them learn the best way to interact with the development team and the stakeholders? Keep on reading for three helpful techniques to get you started.
First things first, when introducing Scrum in a new organization, or when a PO is new to Scrum, there is a tendency to conflate the product owner role with a project manager role. This can be dangerous because a project manager generally has a command and control mindset while a good product owner must have a collaborative mindset. There’s also a separate set of responsibilities for each position, though there is some overlap which is where to the confusion can stem from.
So the first step is to sit down with the PO and go over scrum roles and ask them to identify the differences between the guide and their perception of the role. Any sticking points you uncover give you a starting place to start coaching the new PM; it’s very important that the PM understands what’s required of them. The PM should be able to rely on you as the SM to guide their growth into the role but not to babysit them or do their job for them.
The scrum guide says that the product owner is responsible for adding to and maintaining the product backlog. However this simple statement encompasses an enormous range of responsibility and the scrum guide doesn’t prescribe any techniques of dealing with it. Coaching the product owner through these three different backlog management techniques will go a long way to helping them manage it properly.
Product Road Map – First of all creating a product road map will help the PO with prioritizing the backlog. A road map is a broad-strokes list of what the product will look like in the future. It’s helpful to divide the road map into three different time horizons: next few sprints, next 3 months, next year. Nearer term horizon items should be much more detailed than next year horizon items. For example a next sprint item could be something like “Create a web page that does X” while a next year item could be “Create product X for a new market segment”.
Here’s a link to a more detailed discussion about creating an agile road map.
Release Planning – Once you have a decent road map built up it’s a good time to perform some release planning. This is a technique in which you work out dependencies for stories or tasks and order them accordingly. Then draw a line in the sand so to speak and decide which are going to make it into the next release, and the release after and so on.
It’s important to note that release planning shouldn’t be driven by a deadline but rather a feature set. At the end of a sprint the project should always be in a “potentially releasable state”, release planning is a tool to help the product owner decide when to actually release.
Click here to get some more information on release planning.
Backlog Refinement – This is an activity in which the product owner works with the development team to bring the backlog into a “ready to work” state. Stories at the top of the list should be well defined, have acceptance criteria written and be estimated with story points. It also gives the team a chance to remove irrelevant stories and to break down large stories into smaller more manageable pieces.
For more information on backlog refinement check out this cheat sheet.
A product owner’s job is not easy, but a good scrum master should be able to help guide them through the process. Using the techniques of creating a road map, a release plan and backlog refinement will get you started in making an awesome product backlog for your project.
As a little bonus: here’s a great list of product owner anti-patterns to watch out for.