March 10 2017 – I’ve had reservations about these article for a couple of years and need to write another one. For now I’ve renamed the article to include (might). In short delivery of value is defined by policy rules. It could be performed by a PO. If you don’t have a PO don’t let that prevent delivery of value. You’ll learn a lot by delivering and learning from delivering – no excuses. The original article below remains intact because the activities can still be useful in your context.
What is a Product Owner, what do they do, why do we need one? This is somewhat of a perplexing and puzzling role for most newbies to Agile product development. In the past with been used to being handed a requirements specification usually written by a business analyst. We are blind (even the BA) to the vision that provides the impetus for the requirements. We are forced to interpret a written word from a third party who more often than not is forced to become an expert in a matter of days or months. If we are lucky enough to have an experienced analyst we still will miss out on important nuance that a real expert in their field can provide.
By using these old approaches we automatically increase the risk of not delivering what the customer needs. This is borne out of the inevitable mis-interpretation of requirements, invalid assumptions, poor direction and poor purpose. In the past these sort of maladies were an accepted part of the business of producing software. This has become an untenable situation (it always has been) and since the 1990’s Agile methodologies have come to realize that there needs to more focus on what is business value and that value should be driven by one person. This is called the Customer in eXtreme Programming and Product Owner in Scrum. Due to the popularity of Scrum and better explanation around the role, Product Owner has become the accepted term and has found it’s way into other frameworks like Disciplined Agile Delivery and Scaled Agile Framework. This term will be used through this article, but we still take a well deserved bow to XP for promoting the importance as well.
We will see that the Product Owner or PO for short, is more than a requirements gatherer. They do a lot more than this and can be considered a full time job on a large project. They are the lynch pin from which project success will occur from and therefore are crucial in the delivery aspect as well. Paying lip service to such a role results in solutions which can be great technically but of little use to users.
Why is it a Full Time Role
The PO has a lot on their plate. They need to consider Business Value, Dependencies, Risks (Market and Technical), ROI, Cost of Delivery, Learning Outcomes and more. The Scrum Guide says the PO includes the following activities:
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
- Optimizing the value of the work the Development Team performs
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
As helpful as the scrum guide is we have to search a bit deeper to find out how we execute on its points. There are many sources for this information and I’ll let you know what these are. Hopefully by now you can start to see that the job is large and important. It’s also very pertinent to mention that this role needs to be respected throughout the entire organisation. Management should empower and support the person and the team building the solution needs to respect the decisions made.
Lets take a quick look at each item in turn now and summarize what each may entail and where to look for more information.
Clearly expressing Product Backlog items
Clearly in the past has been confused with massive requirements documents. Ironically document thickness was assumed to convey preciseness and clarity. An Agile Product Owner (or instructs others to ) will provide requirements that are fit for purpose. We prefer User Stories as they have a desirable side effect, by their brevity, of forcing conversation. But there is no prescription and the amount of detail in the requirements should be driven by project context. The only caveat is to provide the right level of detail at the right time. We want precision when we want to create a feature and less when we aren’t sure. Take a look at the INVEST criteria and DEEP criteria for guidelines on User Stories. User Stories Applied is the text you should first look at.
Ordering the items in the Product Backlog to best achieve goals and missions
There are a number of factors influencing the order of the backlog and this can be the more treacherous part of the PO job. Here the PO needs to weigh up the economic value to the gained, i.e. ROI, risks (market and technical), desirability of features, dependencies on other features and more. The PO will need to create Themes with constituent Epics and User Stories and conduct Release Planning. The release plan (a view into the backlog) is continually being updated when new information becomes available. The simplest of ordering methods is to simply use High, Medium and Low. To adopt a more forensic approach the PO can use other techniques such as financial impacts (NPV, Payback Period, Opportunity Cost and Cost of Delay – COD is most important according to Reinsertsen), Kano Analysis for desirability and Weigers Prioritization to name just a few. Agile Estimating and Planning which also covers sizing, another important factor in ordering, is the place to look for more detail. Sizing is also covered in a previous blog post.
Optimizing the value of the work the Development Team performs
I interpret this to be the Pareto Law in action. That is 20% of the effort/features/cost will give you 80% of the customer value. Jeff Sutherland provides the most compelling explanation for this I’ve seen. Jeff suggests that a project should be self funding after 20% has been delivered. If your PO got it right it should. Value can quickly accrue by stacking up the Pareto charts (see the diagram).
The previous point about ordering in my mind is a significant factor in achieving this along with correct sizing of stories, that is not developing every single nuance (split the stories) that a feature may expose. Have a read of The Lean Startup by Eric Ries for very good reasoning why you would want to do this. It summarizes much of the Lean movements mantras quite nicely and these marry well with Agile.
With respect to the stacked Pareto Chart, this is not necessarily a new or original idea. Who came up with it – it’s not important. You can find similar but different representations in Alan Shalloway’s book Lean-Agile Software Development: Achieving Enterprise Agility and James Shore’s and Shane Worden’s book The Art of Agile Development. There’s probably others I’m not aware of as well 🙂
The PO should also know when to call the project off – either it’s ready to go no more development required – Pareto or to Cancel the project – which is hopefully rare.
Early Cashflow – Alan Shalloway
Early Cashflow – James Shore & Shane Worden
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
This is one of the simplest things to do but so easily forgotten or neglected. Alastair Cockburn calls these Information Radiators as they convey information without verbal communication – communication via osmosis or osmotic communications. This backlog is visible through a physical board. These take the forms of the Release Plan and the Sprint Backlog. A good PO will be constantly adjusting this as new information becomes available from the market and the team – as this information appears dynamically the information is dynamically updated so it is transparent and visible to all. It should then be a conversation starter and any issues are quickly brought out into the light to be dealt with. Face to face communication is the most efficient way of dealing with issues which most of the time can be resolved on the spot. Your PO needs to around to do this. It’s recommended to include other radiators like the Vision Statement, Release Goal, Sprint Goal.
Ensuring the Development Team understands items in the Product Backlog to the level needed
The expands on the first item, but is implies more that this. Agile delivery operates within the Agile Planning Onion. The depth into the onion defines the amount of detail required and thereby minimizes wasted acts of requirements definition on features that may not come into existence.
The product owner needs to be vigilant, re-prioritizing, re-estimating (all with help from the team) to ensure the right information, to the right level of detail is conveyed. This is the well known Lean principle of Last Responsible Moment in action here. Roman Pichler’s DEEP acronym comes into play – especially D – Detailed Appropriately. An item selected for development in an upcoming sprint should have the relevant amount of detail and acceptance criteria to enable the development to proceed. Defining a Definition of Ready is a good thing to have here.
But that isn’t enough, the Product Owner needs to be available whenever the team requires information. New information will appear during development and this is too be expected. The PO needs to be present to answer questions face to face. Any other forms of communication are a only a fallback position and represent greater risk in delivering the incorrect functionality.
During the sprint, the Product Owner is expected to interact with the team to perform Backlog Grooming. The backlog is readied for upcoming work and the PO needs to talk to the team about risks to development. The PO is also talking to other stake holders to further refine the most important backlog items.
Larger projects can be too much for one PO to handle. In these cases PO’s can be aligned to Themes, but there is still one Chief Product Owner for the entire project. You can find an intro to the idea here. Might be an idea for another blog post 🙂
The following diagram succinctly shows the the level on involvement required by a PO:
In it we see that the PO effort for a project is constant. It implies no hand offs and constant engagement with stakeholders, users and team members.
Being a good PO requires some practice. Training and mentoring will definitely help along side performing the PO duties. If you skimp on the duties you increase risk very quickly. Not having access to a dedicated PO is a major impediment as was identified in the Medco case study from 2007 that Jeff Sutherland refers to occasionally. Personally from experience, not having access to a PO always leads to missing the mark. Missing the mark can mean hundreds of thousands of dollars of wasted effort. A good Product Owner will easily offset this risk. If you don’t have a Product Owner then you shouldn’t be doing the project full stop! (set that money on fire – you may as well).
For details noted texts have already been mentioned. I also recommend Essential Scrum by Kenny Rubin. This is the essential compendium for Scrum. For specific product owner content go for Agile Product Management with Scrum by Roman Pichler. Derek Davidson also has a pretty good article on what a PO does. How a PO fits into Scrum take a look at the Scrum Reference Card for a start. This link is a decent checklist for a PO.
I feel the most comprehensive guide as of now (Mar 2013) is Bob Galens book, Scrum Product Management.
This has been my take on the Product Owner role and the importance of the role. It will probably not be the last I have to say on it. Welcoming of your meaningful feedback 🙂
Happy Agility and Let’s get on with the next great thing!