The New, New Sprint Backlog

The 2011 Scrum Guide, published earlier this month by Ken Schwaber and Jeff Sutherland, makes some bold changes regarding the definition and structure of a Sprint Backlog. Professional Scrum Trainer David Starr explains these changes with help from Professional Scrum Trainer Ryan Cromwell:

The 2011 Scrum Guide makes some bold changes regarding the definition and structure of a Sprint Backlog. Clarity about Sprint Backlogs is long overdue, and these changes should help many who struggle with the concept.

The Scrum Guide 2011 states:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.

This is a significant departure from earlier understandings of a Sprint Backlog, and opens new possibilities for those practicing Scrum. This less prescriptive approach enables Scrum Teams to experiment within the Scrum framework and find the right planning model that works for them. This ultimately puts the Scrum Team in charge of their own process and allows Scrum itself to flex and accommodate advances in technology and practices.

What was the Sprint Backlog, anyway?

Several times during the last year, I asked people knowledgeable in Scrum (even published experts) to have a look at the following diagram, showing the decomposition of Product Backlog items to Sprint Backlog items. This simple model is a classic way to envision the work within a Sprint.

I then asked viewers to draw a circle around the Sprint Backlog.

“What do you mean?”, they asked.

“Just draw a circle around the Sprint Backlog,” I requested.

After the inevitable pause, the person would draw on the paper and hand it back having chosen what they believed was the “correct” definition of a Sprint Backlog. Variations included those shown below.

A: Least popular

B: Most popular

C: Chosen by Ken Schwaber

This obvious confusion around the definition of a Sprint Backlog had significant implications. I have even spoken with a very capable Scrum trainer who chose B and invented a new term for the PBIs selected for the Sprint.

Of course, applying the definition from the 2011 Scrum Guide, we can see that C is the correct choice and that the plan for realizing success in the Sprint was represented by the Sprint Backlog items, or tasks, themselves. That is to say, the tasks were the plan.

This technique is the traditional way Development Teams sum remaining work and track progress toward completion, but prescribing this as the only way to do so is overly restrictive.

Compounding Issues

Given the disparity in responses, something clearly needed to be done to ensure a common understanding of a Sprint Backlog. There were other discussions underway that would also have an impact on the issue as the new Scrum Guide came together.

Simpler Work

Many Scrum Teams have found themselves in a Sprint Planning Meeting faced with a bug or some other small-sized Product Backlog item being considered for inclusion within a Sprint.

The canonical example of something like this is a label change on a page or form. This is arguably one of the simplest possible changes a Development Team might be asked to implement. The inevitable question asked by a Development Team member accepting this Product Backlog item into the Sprint is, “Do we really have to make a task (Sprint Backlog item) for this?”

Until now, the answer was typically, “Yes.” Sprint Backlog items were required for each Product Backlog item. This means teams could often end up with a small Product Backlog item and a single corresponding Sprint Backlog item because “that’s how it’s done.” Typically, this was to satisfy some electronic tracking tool or over-prescriptive Scrum Master, but the wasted effort of creating and managing the placeholder Sprint Backlog item was spent nonetheless. In this all-too-common situation, Scrum over-prescribed a solution, thereby inhibiting self-organization of the Scrum Team.

Implicit in the 2011 Scrum Guide’s definition of Sprint Backlog is the notion that teams may do what makes sense in situations like these. There is no specific “that’s how it must be done” with regard to creating a plan for delivering Product Backlog items selected for the Sprint.

New Ways of Defining Done

To further complicate the question of “What is a Sprint Backlog?” many teams have been successfully experimenting with new and exciting ways of representing “Done” within a Sprint.

One emerging technique is seen in Development Teams using ATDD (Acceptance Test Driven Development), a technique in which all requirements are represented by automated tests that must pass in order to be considered complete. For teams using ATDD, might a valid Definition of Done for Sprint Backlog items simply be that all associated tests created during the Sprint must pass? This approach is growing in popularity as tools, knowledge, and experiences mature in ATDD and BDD (Behavior-Driven Development).

In some less than thoughtful teams, the Definition of Done for a Sprint is seen as the completion of all tasks, or Sprint Backlog items. This letter-of-the-law approach to defining done takes attention away from the Sprint Goal, delivery of which is the true Definition of Done for a Sprint. “Perhaps,” some teams conjecture, “the only real measure we need is completion of the Sprint Goal itself.”

Conclusion

The 2011 Scrum Guide explicitly enables Development Teams to select Product Backlog items for a Sprint and create a plan for delivering them that may be unique for the Development Team. This empowering flexibility enables creative and intelligent decisions that make sense for the Development Team in planning and delivering the Sprint Goal. The plan itself might come in the form of an automated test run report, a Sprint Goal measure, or some other new way of seeing the work that has not yet even been discovered.

The 2011 Scrum Guide offers some exciting opportunities for Scrum Teams to find new and more effective ways of working. With the changes to the definition of the Sprint Backlog, teams may find Scrum more appropriate to processing simpler work items, or they may find a perfect application for new and emerging engineering practices.