The Static Product Backlog

We often see product owners doing everything possible to create the illusion of control and predictability on a project. They create detailed plans and try to fill each and every sprint with PBIs in advance. The PO then creates a Gantt chart to track progress. The product backlog may change ever so slightly so long as the team doesn’t deviate too far from the original plan. Incorporating user input is exhausting for the Scrum team and often discouraged by the product owner because the plan has no room for change.

Joe asks:

How many product backlog items does a team need before getting started?

A product-development effort should be backed by a strong vision that guides and informs the Scrum team as they decide what to do next. So long as there are enough product backlog items to bring into the first sprint and formulate a sprint goal, the team should start working. Waste as little time as possible creating a plan for how to start. Be okay with learning as you go and letting the product backlog emerge as you complete your initial PBIs and deliver increments of product.

A static product backlog that doesn’t evolve as the team gains experience implies that outcomes are certain—but as anyone who’s worked in software knows, outcomes are never certain because circumstances always change. Believing that outcomes are certain traces back to industrial era-type thinking (Taylorism) that we mentioned in Chapter 2, ​Why Scrum Goes Bad​. That type of thinking will eventually create tension, angst, and failure. You can’t plan complexity perfectly. Your goal when starting on a project should be to create a product backlog that contains just enough work to get started with a sprint. The product backlog will grow and change over time as your users and customers provide feedback on the Scrum team’s work.

Joe asks:

When does the development team look at the product backlog?

The Scrum Guide states that product backlog refinement should consume no more than 10% of a development team’s time during a sprint. This guidance helps prevents Scrum teams from looking too far ahead. That said, your Scrum team will look at the product backlog throughout the sprint. If you’re using two-week sprints, your team should spend around eight hours doing refinement each sprint.

Scrum was created to facilitate complex, adaptive problem-solving. When you’re working on a complex product like developing an embedded control panel or updating a consumer healthcare website, more is unknown than known about what the project will require. It’s only by doing the work and getting feedback from your customers that you can know what needs to be built next, and this complexity should be reflected in the product backlog. As the team inspects, adapts, and creates product increments, requirements will emerge. In other words, your teams will learn things and have opportunities to update the product backlog with new information. Don’t squander these opportunities in favor of clinging on to false certainty.

Humans like feeling as if the future is certain and we know what tomorrow will bring. Product backlogs often reflects this craving for certainty. Having an exhaustively detailed product backlog that attempts to create certainty feeds this craving but limits the Scrum team’s ability to adapt. That will cause the team to build a less valuable product, will limit their creativity, and will set false expectations for stakeholders. Embrace complexity and the lack of certainty that comes with it.

If your PO tries to keep anyone from changing the product backlog, have a chat with them about how it’s impossible to predict the future, and how vital it is for the team to be able to adapt to changing conditions. Over the course of our 20-year careers in software and product development, we (your humble authors) have never seen a project hit its estimates perfectly. In every case, adaptation was far more valuable than trying to make perfect predictions.

Your product owner may need some help getting the initial product backlog built or adapting a product backlog that has been static for far too long. In that case, here’s a Liberating Structure^[12] that can help. It’s called 25/10 Crowd Sourcing, and it’s an idea-generating exercise where the product owner, development team, stakeholders, and users can come together to generate a product backlog.

Invite everyone to a meeting space where there’s enough room for people to move around. Then start the exercise:

1. Give each person a blank index card and something to write with.

2. Ask the participants to silently answer the question, “What’s the most important feature this product needs to be successful?” Have them write down their answer on one side of the index card. Tell them to hold their cards up in the air when they’re done so you can see when everyone is finished.

3. Ask everyone to walk around the room and trade cards—without reading them. They should simply mill around the room and exchange cards. Give them 30 seconds or so do to this.

4. Ask each person to rate the idea on their current card from 1 to 5 (with 1 meaning “nope, this isn’t an important feature” and 5 meaning “What a wonderful idea. I’m in!”) and write that score on the back of the card.

5. Using the same set of cards, repeat steps 3 and 4: Have everyone trade cards and then rate the idea on their current card. Repeat these steps three more times until every card has five scores on the back. At the end of each round, verify the number of scores (which should be the same as the number of completed rounds) by asking each participant to count the number of scores on the back of their current card. At the end of round five, ask the participants to add up the scores on their current card. The result will be a number from 5 to 25.

6. Ask everyone to line up based on the score on their card, and then have the people holding the top ten ideas read their feature out loud, starting with the highest-ranked features.

7. Ask the participants what caught their attention, whether any new ideas for features came to mind during the activity (don’t forget to capture these ideas!), and whether they have any input on the highest-ranked items.

Congratulations: you’ve got a solid foundation for your product backlog! Now it’s up to the product owner to adjust the order of features as needed and start refining the highest-ranked PBIs.

And now that your team has a solid product backlog, it’s time for the development team to get to work turning those PBIs into high-quality increments.