Product Backlog: Requirements or User Stories?
There is no "one recipe" in Scrum for the right product Backlog, only some important ingredients to mix up in the right way
Hi there, spending some extra time at the airport (thanks to lovely pilot strikes) gives me the chance to write a bit about Scrum and the Product Backlog. A Product Backlog is a stack of "features" prioritized by Business Value, which means that on top of the stack there is always the most valuable item for the customer/client.
The owner of the Product Backlog is the Product Owner and as such should be the one and only authorized to make changes to the Product Backlog, given also the fact that the main responsibility of the Product Owner is to maximize the delivered Business Value at every iteration, or the ROI. If anybody would be allowed to enter new items and change their priorities, the Product Owner will have no control over the Backlog anymore and would not be able to fulfil her main responsibility. There are many possibilities to allow the team and the stakeholder to participate into the Product Backlog development, but I would like to focus on the Product Backlog itself for now.
One of the "assumption" that is often made, when starting to adopt Scrum, is that there will be a Product Owner and there will also be a Product Backlog. Well, it happens that the Product Backlog quality is one of the major responsible for the outcome of what the team will produce in terms of software, and is absolutely one of the most difficult things to work out. There are many problems related to having a right Backlog in place, and as you may guess there is no "one recipe" for the right Backlog, only some important ingredients to mix up in the right way ;-)
The Product Owner should have full control over the "investment" that is made into the Product and have also the responsibility of defining product development milestones and content, understanding the market need, the customers and being able to assign the right business value to the right features. In our experience, in many european - and not only - companies, it has been proven to be quite "unusual" that a single person into the organization is appointed with all the power and responsibility needed to be a Product Owner. Nevertheless many organizations managed to make Scrum effectively work and increase their productivity and overall quality, how can the Product Owner do an effective job without having the full control over the Product?
The idea is to have the Product Owner "...get initial and ongoing funding..." (Ken Schwaber) for the product development, more or less in a virtual way from the Product Stakeholders. At Agile42 we "setup" the concept of Product Management Board as the place where the Product Owner present to all the Stakeholder of a Product, the actual Product Backlog, and ask them to help him in attributing Business Value to the single items. To do this we invented the Business Value Game (see here) that allow the Stakeholder to:
- Reach a common understanding on the Product Features, and agree on overall value, discharging the Product Owner from having to deal with different stakeholders at different time and manage conflicts
- De facto "approve" the Product Development Budget for the next Product Release, so that the Product Owner has full control over it and can together with the Team work on the Backlog without further approval
One of the problem to solve is "What do I put into the Product Backlog?" or better: "How are the Features looking like?" and here the answer is mostly... "Of course, Scrum is Agile, and the Features are User Stories...".
We love User Stories - thanks once more to Mike Cohn for having invented them - but it happend often that the level of granularity the User Stories need to have to fit into a Sprint and satisfy the Team needs, is too much for a typical Stakeholder that want to assign the Business Value to them. Stakeholder we deal with are normally all management roles (VP, CxO) including every company department if the company core business is related to the Software they develop. For this reason we developed a bit more structured approach, which tries to keep the agility of the Product Owner safe, as well as allowing the Stakeholder to "manage" the product Budget at least at an high level.
The Product Owner present to the Stakeholder at the Product Management Board, Requirements, which represent the "need" that have to be fulfilled with the Product, and ask the Stakeholders to express the Value for the Customers if these needs would be fulfilled within the next Product Release (hypothetically, keep in mind the Business Value is connected to the timeframe in which will be made available to the customers).
Once Stakeholders voted for the Business Value of Requirements (the Product Management Board is also a timeboxed meeting), the Product Owner will try to give an initial "very rough" commitment on the amount of value that would be delivered into the next Product Release (a Release spans normally through multiple iterations). At this point the Product Owner is "free" to break down the Requirements into User Stories, and find Solutions to the highest valued needs together with the team (a good practice is the User Story Workshop). The Product Owner may ask the Team to give initial high level estimations to the defined stories (S, M, L is enough at this stage) and using the Team Velocity, check how many Requirements (and therefore Business Value) may be delivered in the next Product Release. The Product Owner may than inform the Stakeholders on the progressive value delivery at each Sprint and keep a total earned value chart updated, as a report to the Stakeholders.
With this approach the following important achievements are possible:
- The "separation" of Business Responsibility from Product Development via the Requirements and the Product Management Board
- Clear distinction between "Problem Domain" (Requirements) and "Solution Domain" (User Stories) and allow the Team to creatively propose alternative possible solutions the well defined needs or problem statements
- Ease the work of the Product Owner in term of ROI maximization, de facto the Requirements represent the value, and the User Stories estimations (points or ideal days) the cost. The Product Owner is allowed to make tactical decisions in changing priorities, once the costs of development will be known
What do you think? Do you have some alternative ideas to solve this problem?