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

Food for your soul: the FOODBOOM story

Passion for food and great ideas drove FOODBOOM and when the time came to confront their strategy and build on the vision they asked agile42 for help

Image of apanagiotou

Anna Panagiotou

Dive deep into Cynefin™ for Agile

Advanced Cynefin™ for Agile Masterclass with Dave Snowden in Berlin on September 24 and 25, 2019

Image of apanagiotou

Anna Panagiotou

From Agile to Agility in Lisbon

Andrea Tomasini will talk about ORGANIC agility and the path from Agile to Agility at the eXperience Agile conference in Lisbon on Sep. 30, 2019

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.

Advanced Agile Team Coaching Course in Berlin and Helsinki

Join agile42 coaches to learn a more structured approach to coaching teams
Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.
Image of javierperez

Javier Pérez

Javier invested his first years of career working as developer and business analyst in Madrid. When Javier moved to Berlin, he discovered his passion: to help teams and organizations in their cultural transformation towards agility working first as Scrum Master and later as Team Coach.
Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Cynefin, Wardley Maps and ORGANIC agility in Stockholm

Workshop by Dave Snowden and Simon Wardley “Navigate uncertainty: Strategy and innovation with Cynefin™ & Wardley Maps” is coming to 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.