Scrum Rules: Your Product Owner Refines the Product Backlog for Each Sprint Planning Meeting

September 15, 2020
6 minute read
Read

The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks.

If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.

The refinement activity is unlike other activities in Scrum in that it is not time-boxed as a meeting. Instead the Scrum Guide gives us fairly specific guidance that refinement “is an ongoing process” and that the “Scrum Team decides how and when refinement is done.” The actual work of refinement involves the Development Team working with the Product Owner to:

  1. Add detail to Product Backlog items.

    Detail comes out mostly through splitting items that are too big to fit easily into a single Sprint. Splitting adds detail because the “new”, smaller items that make up the larger item each have unique information. Here is an example that illustrates how splitting adds detail:

    1. Original Large Item: “As a Job Seeker I can upload my resume.”

    Split into:

    1. “As a Job Seeker I can upload my MS Word resume.”

    2. “As a Job Seeker I can upload my PDF resume.”

    3. “As a Job Seeker I can upload my OpenDocument resume.”

    In this simple example, the original backlog item did not include information about the types of files that the job seeker can upload, but upon splitting, the Product Owner was required to provide additional detail (three file types) to make each smaller item unique from the others.

    Another source of detail is constraints, conditions of satisfaction or acceptance criteria that are discovered through market or technical research. Continuing the previous example, the Development team suggests to the Product Owner that there be a limit on the file size of the uploads of 50MB and that the Job Seeker gets an error if the automated text analysis discovers any abusive language (e.g. swear words).

    Although adding detail is part of Backlog refinement, it is still important that Product Backlog items not become precise specifications and that that level of detail only comes out when the team starts work on the items to create tests and functionality during the Sprint.

  2. Add estimates to Product Backlog items.

    There are two types of estimates that go on Product Backlog items: estimates of effort and estimates of business value. The Development Team is responsible for estimating effort. The Product Owner is responsible for estimating business value, and can include other stakeholders in that process. The estimation techniques used should have the following characteristics:

    1. Collaborative and consensus-based whenever possible so that it is difficult or impossible to blame an individual for a bad estimate. Scrum rests on empiricism which means that we care about reality and accept that the only way we know the future is by getting there and seeing what it’s like.

    2. Extremely fast so that we don’t waste time on trying to achieve perfect estimates. The Pareto principle (the 80/20) rule applies: 80% of the effectiveness comes from 20% of the effort of estimation… so just leave off the other 80% of the effort.

    3. Use a relative or comparative scale rather than “real” units so that everyone knows that they are just estimates, and aren’t reality. We semi-arbitrarily put a numerical value on a particular Product Backlog item and then compare every other one relative to that initial choice.

    The estimates help the Product Owner and the Development Team make good business decisions about the work they are doing.

  3. Add order to Product Backlog items.

    The Product Owner makes final decisions about the order and is accountable for that order leading to good business results. Both the detail and the estimates that come out of refinement are important factors to consider in ordering items. The Product Owner uses this information plus any market data, stakeholder feedback from the Sprint Review, and even new innovative or creative ideas all together to make decisions about the order of item. The Product Owner can change the order at any time.

Refinement is easiest when the Product Owner can also keep the whole Product Backlog in mind at the same time. This allows the Product Owner to see the big picture while dealing with tactical changes. There are two important techniques that help the Product Owner to do this:

  1. Keep the overall number of Product Backlog items small. Although this is not always possible, a good rule of thumb is that thirty to forty is ideal, and after about eighty items it gets extremely difficult to keep it all in mind at the same time.
  2. Write each Product Backlog item on a single 3×5 note card. This seems to be a reasonable limit to the amount of detail to write down before an item gets pulled into a Sprint Backlog. Again, this is not always possible, but if the Product Owner and the Development Team are working together for large amounts of time every day, then verbal communication can easily take the place of writing excessive detail for each item. The physical note cards allow the Product Owner to literally lay out the whole backlog and see it all visually.

The Product Owner should consider attending in-depth training. Two good options are the Certified Scrum Product Owner or the Professional Scrum Product Owner offered by the Scrum Alliance or Scrum.org respectively. Two good books to consider are “Agile Estimation and Planning” and “User Stories Applied” both by Mike Cohn.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. — The Scrum Guide

During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. — The Scrum Guide


 
If you find this useful, please consider contributing with our
Value for Value” model.

 


 

Berteig Consulting

Empower Your Entire Organization with BERTEIG Consulting in Agile, Scrum, Kanban, SAFe and LEAN.

Aimia
Bruce Power
Capital One
CBC
Comcast
Equitable Life of Canada
FreshBooks
Suncor