Product Owner required

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.

What is Business Value (in this context)?

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?

Writing better user stories

Recently we had a planning session where I was asked to explain what made a good User Story, so I thought I’d capture that in a blog.

We are all familiar with the standard layout of a User Story:
* As a …
* I want to …
* So that …

However, I’ve observed a temptation to just blindly follow that formula and then claim that you are “doing Agile”. For me, the real essence of Agile is looking at what you are doing, identifying if it’s giving you good value, and if not, changing it so that it does (or dropping the practice all together). So, how to we write better user stories ?

I’d like to start by breaking down what we capture with the above formula, what qualities we want from a user story, and then what we can do to improve our stories.

 

Role, Task, and Motivation

As a … : this defines the role of the person stating the User Story and gives it a context. If you have the same value here for every story, “User” for example, then the field is not providing any value to you. You should take the one role you have and try to break it into finer grained roles, even if they are not actually represented that way in your system.

I want to … : this is the task you are trying to achieve in the context you have just set up. Generally, people are quite comfortable describing this part. Concerns here are striking a balance between readability and capturing the necessary details. I’d err on the side of readability and make sure that the task part of the description is memorable and differentiates the story from others. You don’t have to capture all detail in this one line, you can add additional detail to a story outside of the “As a, I want to, Such that” structure.

So that … : this is the motivation behind the story and, I find, often over looked when writing User Stories. I’m not suggestion you write a lengthy thesis on the motivations of the user, but at least explore it and see if there are some useful pieces of information to take from it.

 

Testability

A good user story should also capture some information about how you might go about testing the story. This can be in the form of a simple “Done” list, or perhaps as  description of an integration level test/scenario(s) that would exercise it. I’ll assume that you would be writing unit tests (and writing them first) as part of the implementation.

 

Large Stories

A cardinal sin in my book is having huge stories that have such a complex completion criteria and cover such a wide range of functionality, that they take many iterations to be completed. These interrupt the rhythm of an agile project because it’s very hard to track progress against them. I’ve found that this can have a negative effect on the team morale as the story rolls on from one iteration to the next. We currently have a rule of thumb for our 1 week iterations, which is to limit estimates on stories to 3 days. If it looks bigger than that, I encourage the creation of sub-stories within it. So far, that’s working well for us.

Sure, you might find it useful to capture epic stories as a set of related functionality, but break it into bite sized chunks. Not only does this give you a warm feeling to the team as you close out all the sub-tasks, but the act if breaking an epic into smaller stories helps focus in on what exactly you are trying to achieve…which is what a good user story should do.

 

Conclusion

So do we write perfect user stories every time? No, of course not, but we often review stories in our retrospectives and identify which features of them made them easy to work with and which stories we had trouble with. I never expect a story to capture every detail, but I like to aspire for stories that anyone on the team could pick up and understand what needs to be implemented, why it’s being added to the product, and how they can go about verifying that they have finished the work.