Product Owner required
November 16, 2011
Recently we had to find someone to act as Product Owner for our project. He had little experience of Scrum or of agile software development so I wrote him a primer on what role we needed a Product Owner to fulfill. This post is more or less what I sent him to see if he had the time and appetite for the role (with company and project details removed/altered to make it more generally applicable).
There are some things that people assume about the role of Product Owner, so let’s dispel some of those upfront.
What the Product Owner is not
- It’s not a “prestige” or “honorary” role, you will have work to do and decisions to make
- It’s not a project manager role, it has specific responsibilities but they are not related with the running of the project
- It’s not shuffling work around on a spreadsheet and then handing it over to be done
- It’s definitely not running the build team 😉
What does the Product Owner need
- A clear and detailed product vision – the build team will look to the Product Owner for guidance on features and how they should work and fit in with “the vision”
- A solid understanding of Business Value – I’ll come back to what I mean by Business Value
- Communications with the key stakeholders and project sponsors
- Understanding of the User Stories in the backlog – we’ll work out what level of detail and language they need to be valuable to both you and the build team
- Some understanding of how software is developed, but not low level details. It will be helpful for us to occasionally explain technical concepts, but we won’t be asking you to cut any code.
- Skin in the game. You’ll be responsible for maximizing the value realized from the effort spent.
Ultimately, Business Value is whatever the Return On Investment (ROI) of this project is going to be judged on. That could be the number of users, the happiness of our users, the diversity of our users, the number of installations of the application, the collective dollar savings our customer make by using the product, or any combination of those (or more) options. This is not always going to be the same for all time either.
For example, right now we are trying to make a handful of customers happy, but next year we’ll probably be more interested in increasing the number, and diversity, of projects using our application, and how much money they are saving the firm by doing so (it’s an internal project in our firm, but the teams in the firm will only use it if they perceive it to be giving them additional value).
It’s going to be up to you to identify the current Business Value and prioritize work accordingly to get as much Business Value as possible…and be aware of when Business Value changes.
Activities
So I’ve talked about what a product owner is not, the things they need, defined business value. It’s probably a good time to talk about what you’d need to actually do.
Product Backlog
This is where every feature, bug, task, activity, etc related to the product lives. You would be responsible for keeping that list up-to-date and prioritized. This is the element of the role that was referred to as being a full time role. We will end up with some shared responsibility of its maintenance, but you would have the final say on priority of work. With that control, you’d be expected to keep on top of what’s in the backlog, see dependencies (with our assistance where it’s a technical dependency), and determine urgency of items. In an ideal world, you might be able to assign a numerical Business Value to each story to assist you…but we’ve attempted that on other projects and it’s not a trivial thing to do, so let’s walk before we run. There is also the breaking up of stories into smaller units and the creation of “epics” which span many stories to deliver a higher level feature.
Demo
You get to accept or reject any work done. Traditionally this is done via a demo at the end of an iteration where you would come along and we’d demonstrate all the features built in that iteration. Being intimately familiar with the stories, you would be in a position to say whether or not it’s acceptable, or perhaps needs some additional work. The feedback from this is also a driver for fine tuning the user stories so that your expectations line up with what we’re delivering (and vice-versa).
Planning
In iteration planning we essentially take the prioritized backlog and see what can be delivered, in a fixed period, starting with the highest priority item and working our way down the list. Of course this is an oversimplified view and it’s not always the most effective way to work, so your input would be required to provide themes and higher level goals for each release/iteration. For example, in one release we might focus on integration with other systems, in another we might focus on improving user experience.
So, given all of the above, are you still interested in the role job?