A brief introduction to agile product ownership.
The Product Owner ensures that the final product contains the exact collection of features that is required to meet the business requirements. She does this by continuously prioritising the Product Backlog to reflect the priorities of the products customers, users and Business owners.
The Product owner in agile development is the key to value driven, incremental product development. The Product owner owns the product backlog and is responsible for it’s content and the prioritisation of that content.
By managing the product backlog the product owner effectively decides what to develop next. Given that we are operating in an agile environment we can assume that we are working on a ”fixed time, fixed budget”-basis. Consequently we must have the ability to vary scope. (If you work on a fixed scope project you are not in an agile environment).
The Product Owner makes sure that we use our limited resources to build the features that yields the most value. The Product Owner decides what does and what does not become part of the product.
Since the requirements for a given product has a tendency to evolve and expand over time we need to find a way to make sure that what we develop is the part of the requirements needed for the product to succeed – and only those features. Every feature put into your product represents a cost in terms of maintenance and evolutionary development. (Another aspect of this is complexity which invariably goes up when the amount of features increases but we will leave that out for now).
The tools we use to achieve the goals described above are prioritisation and time boxing.
The product owner needs detailed knowledge of how her product is utilised to be able to decide whether a given feature is truly needed to support the business case for that product or not. So, if you as a product owner can not answer the question ”how does this feature add value to my product” you’re headed for trouble. You should either investigate further into the matter to understand a features value or simply remove it from the backlog.
The Product Backlog
The Product owner writes a Product Backlog. Before setting about writing the user stories that will describe the requirements for your product you should be able to answer at least the following questions:
- What are the unique selling points for my product
- How will my product create revenue
- Who will be using my product
- How will my product add value to my customers
Furthermore you should define the goals for your project and a vision for your product. This will help you when we come round to prioritising the user stories in the Product Backlog.
A projects goal could be something like:
- Have a first version of your product released by a certain date
- The first version of your product should meet the business requirements from X department (Marketing needs to be able to create and release campaign sites in less than 4 days without the need for a programmer)
- A statistics tool must be implemented in the product to allow editors to do follow ups of readers interests.
The vision for your product describes what your product is really about. For example:
My product will be Europe’s best news site for east european citizens.
Obviously, your project goals should support your vision for your product. When you are working with your Product Backlog and need to make a decision whether to put a feature into your next iteration or not, simply asking: ”does this feature help me achieve the goals for my project and does it bring my product closer to my vision for it” will guide you in making that decision. Deciding between two candidates for your iteration will hopefully be easier in the context of goals and vision.
For more information on how to prioritise – try Mike Cohns ”Agile Estimating and Planning” http://www.adlibris.com/se/product.aspx?isbn=0131479415 or The Kano Model http://en.wikipedia.org/wiki/Kano_model.
Once you have decided on your project goals and is comfortable with the vision for your product you can begin to write the user stories that will make up part of the Product Backlog.
A good explanation of how to write user stories can be found here: Writing Stories. (From Mike Cohns book ”User Stories Applied for Agile Software Development” http://www.userstories.com/book)
Definition of done
You will need a few more documents to go with your Product Backlog. One of them is the Definition of Done. The Definition of Done is there to ensure that when someone within the projects says ”I’m done” everybody knows what that means. Sterling Barton has written a brief description of how one might go about defining a Definition on Done. It can be found here: http://www.gettingagile.com/2007/10/05/building-a-definition-of-done/
Presumably your organisation has an IT or Operations department and sooner of later you will have to find out how they will support your product once it is to be released into the production environment.
Typically these are also the people who set up your developing teams environments (code repositories, continuous integration servers, test servers, stage servers etc).
Ask them to supply you with the information your developers will need and contact information your development team can use when questions arise.
Preferably, you as a Product Owner will also have a contact person from Operations who can act as a stakeholder in your project. Have Operations attend all meetings where decisions regarding the release of your product is made – typically your project steering committee meetings.
Ensure that the team initiates contact with your Operations contact person and informs him of their strategy for development. This should act as a sanity check of the road the team has chosen for fulfilling your requirements. If your organisation has a team of architects and they are not part of the development team don’t forget to do the same with them.
You will want to make sure that Operations commit to decisions regarding the release of your product. Keep in mind that a decision to make an earlier launch is not uncommon in within agile projects.
A plan for the release strategy for your projects evolvement after the initial release is a good thing to start discussing in an early state. If you plan to do frequent releases Operations need to plan for this – for example by automating deploys
Filed under: Role descriptions, definition of done, dod, pb, po, product backlog, product owner