Committing to the Sprint Backlog

As we discussed in Chapter 10, ​Sprint Planning​, the sprint planning event is where the whole Scrum team gathers to define the work for the next sprint by creating a sprint goal, a sprint backlog, and a forecast. At the end of this event, the development team should have a plan for the first few days of the sprint that details how they believe they can accomplish the sprint goal. That plan is in the sprint backlog (flip back to the intro of this chapter for details of what should be in this plan.) But many organizations insist on a more robust plan that leaves little or no room for change.

We frequently hear Scrum teams and organizations say that the sprint backlog is a commitment—that everything in the sprint backlog must be completed by the end of the sprint, and that sprint planning is the only opportunity the development team has to create a robust execution plan. This way of thinking about the sprint backlog shows that an organization is craving certainty, but certainty doesn’t exist in complex projects.

In Scrum, the development team commits to achieving the sprint goal. But given the complexity of the work that dev teams face, it’s impossible for them to commit to completing everything in the sprint backlog.

Have you ever looked at a problem and initially thought it would be simple to solve, but then started working on it and discovered that it was actually a monumental task? For example, imagine a bug that on the surface seems like it may only take a couple of hours to fix. But as you dive into the code, you find it to be something much more far-reaching than you expected. That “couple of hours” estimate balloons and turns into days or even weeks. That’s the nature of complex work: It emerges, meaning that as you start the work, you find new work because it’s impossible to predict all the intricacies of complex projects.

Let’s think about why and how the sprint backlog emerges (changes) by examining what’s in it:

• The What: A set of product backlog items that the development team has selected for the sprint, and an accompanying sprint goal. The PBIs contain requirements that describe what the increment may look like and what business value the development team intends to deliver to meet the needs expressed in the PBI. Bringing new PBIs into a sprint while it’s already in progress can be disruptive, and should trigger a conversation between the product owner and development team.

• The How: The development team’s plan for delivering the work. This may be in the form of tasks attached to PBIs that describe a technical implementation plan, or it could be the PBIs themselves. Remember, the development team doesn’t have to create tasks—they’re an optional Scrum practice that dev teams can use.

• A Forecast: An estimate of how much total work exists in this sprint and the amount of work remaining. Scrum is agnostic on how you estimate work. You can use PBI counts, task counts, Fibonacci numbers, zebra stripes, or whatever. We recommend not using hours because doing so implies certainty.

• Retrospective Improvement(s): At least one continuous improvement item that the Scrum team discussed during the sprint retrospective.

The development team needs to consider volatility when creating a plan based on the contents of the sprint backlog. Developers will come up with questions related to requirements and business functionality as they perform the work. The answers to those questions can change the dev team’s implementation plan and forecast. And retrospective improvements change the way a Scrum team works and can impact how a dev team builds increments. So, as you can see, the sprint backlog is inherently changeable.

What’s of utmost importance is that the sprint goal remains intact. You can have a new sprint goal every sprint, but once a sprint begins, the sprint goal must remain static for the duration of that sprint. If there is ever a circumstance where the volatility of the sprint backlog brings into question the development team’s ability to accomplish the sprint goal, the dev team must immediately initiate a conversation with the product owner.

The sprint backlog emerges in the same way as the product backlog: It changes as the development team performs work. As Scrum masters, it’s our job to promote the healthy emergence of the sprint backlog by helping the development team learn how to work under complex conditions. We must also work with the larger organization to make sure everyone understands that complexity is best dealt with through emergent plans. Although we need a plan, plans are never perfect and must be flexible.

So how do you go about changing this perception of the sprint backlog as a commitment? As a Scrum master, you should work to help the whole Scrum team and folks in the wider organization understand that the Scrum team is laboring in the complex domain of work. Way back in Chapter 1, ​A Brief Introduction to Scrum​, we briefly mentioned the Cynefin Framework^[14] and the Stacey Matrix,^[15] which describe various domains of work. We know this sounds pretty academic, but getting familiar with these frameworks can help you understand (and explain to others) why the dev team’s work emerges. Here are four domains of work which are mentioned in both these frameworks:

• Simple: In this domain, explicit rules are defined upfront and, so long as those rules are followed, the outcome will be certain. Think about ordering a pizza for delivery: All the supplies come from the factory and, when an order is sent in from a customer, so long as the requests in it are followed, the outcome is certain—a happy customer.

• Complicated: In this domain, explicit rules are defined upfront, but they require experts to define them. Think about what it takes to build a house. During planning, experts need to plan the foundation, how framing will work on top of that foundation, electrical wiring, etc. If those experts’ rules are followed, the house will be built correctly.

• Complex: In this domain, when we start, we don’t know yet what we don’t know. The best practice is one where the rules emerge and change as we go. Empirical process control, with inspection, adaptation, and transparency points, is required to change those rules. Software development falls under this domain.

• Chaos: When coping with the chaos domain, all one can do is act, sense, and respond. Emergency services such as paramedics, police officers, or emergency rooms fall under this domain.

As a Scrum master, you should be able to understand and describe these domains. That knowledge will help you give people throughout your organization a better understanding of complexity. It will help you have better conversations around the changes that happen in the sprint backlog, and how the plan created in sprint planning will change because of the complexity the development team faces.