July 7, 2008

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?

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.
blog comments powered by Disqus
Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Latest Posts

Workshops on the Certified Agile Leadership pathway

CAL 2 workshops offered in Berlin on Agile Leadership, Organizational Design, Changing Leadership, part of the Certified Agile Leadership program

Image of marion

Marion Eickmann

I am one of the founders and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Exhaustion is Not a Status Symbol

Leverage the agile values to mitigate the risks of exhaustion becoming a status symbol

Image of melissa.boggs

Melissa Boggs

Meet The Coach: Kemmy Raji

Having worked in various sectors from financial institutions to utility companies, meet Kemmy Raji.

Image of agile42

agile42

News and views from the Headquarter of the agile42 team

Meet us at Agile People Sweden 2018

Come and join the coaching clinic with agile42 at Agile People Sweden 2018 Conference in Stockholm

Image of sofia.svanback

Sofia Svanbäck

I am the Business Relationship Manager of agile42 in Finland and Sweden. I started working at agile42 in May 2018 and haven’t done anything so interesting before. The decision to join agile42 is a decision I am proud of today. My days are filled with customer related things, like negotiations, offers, and training / coaching bookings to mention a few.

Meet The Coach: Sunny Dhillon

For our Meet The Coach series, agile42 coach Sunny Dhillon talks about his background, his agile journey,  and insights about Agile adoption. 

Image of agile42

agile42

News and views from the Headquarter of the agile42 team