The Sprint Backlog – An Actionable Plan to Deliver Value

The sprint is a container for Scrum events. It contains all the work a Scrum team will do to create an increment (which is formed when it meets the quality measures required for the product as defined by the team’s definition of done). The sprint is the heartbeat of Scrum. 

In her blog, 5 Powerful Things About the Sprint, Stephanie Ockerman covers how the sprint provides:

• Focus (where ideas are turned into value)
• Predictability (deliver a ‘done’ increment of work)
• Control (to inspect an increment and adapt)
• Freedom (for Scrum team to self-manage, collaborate, and experiment)

The first event of a sprint is sprint planning, which lays out the work to be performed for the sprint. The output of sprint planning is the sprint goal—a concise statement of what the team intends to accomplish during the sprint—and the product backlog items selected for the sprint, also known as the sprint backlog.

Why create a sprint backlog?

The Scrum Guide describes the sprint backlog as a plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

The sprint backlog is solely owned by the developers, but the Scrum team collaborates over the work on it. For example, if the developers believe the work in the sprint backlog needs to change to better meet the sprint goal, developers would collaborate with the product Owner when making that decision. The sprint backlog is still owned by the developers.

The sprint backlog contains a commitment—the sprint goal—which provides the ‘why’ for the developers. It enhances transparency and focus against which the team can measure progress.  The sprint goal helps to answer questions like:

• Why is it worthwhile to run this sprint? 
• What assumptions/hypotheses do we want to test?
• What is it we are trying to achieve? 
• How does it get us closer to our product goal? 

How to create a sprint backlog

During sprint planning, developers collaborate with the Product Owner to craft the sprint backlog, which describes how they intend to deliver the increment. The sprint backlog is an actionable plan for delivery.

The developers decompose work (often expressed as user stories) into smaller items (often expressed as tasks). Tasks are small items of work that can be completed in a short timeframe (typically one or two days). 

Tasks are more precise, in detail and in scope, than user stories. When creating tasks, avoid vague statements such as ‘coding’ or ‘implementation’, thinking that you can just refer to the parent user story for the details. Instead, create meaningful descriptions of the tasks to make the scope of work very clear.

A blog by Victor Dantas offers a very good example of how to break a story down to a task level for a requirement for a web app: 

As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it.

And with the following acceptance criteria:

“Given that I am a registered user and logged out… if I go to the login page and enter my username and password and click on Log in, then the data associated with my user should be accessible.“

By getting all the developers together in sprint planning to brainstorm on what is needed, you’re likely to hear things like:

• “We need a new UI element for Sign-up and Login”
• “We need to develop encryption functionality for the password”
• “We need to create a table in the database for user information”

Now, to do things in a more structured way, let’s ask the developers:

How can we break this down into executable, scope-bound tasks? Here, the team may agree on the following tasks for the user story:

• Define Sign-up/Login form style and develop new CSS class
• Develop HTML and Javascript Sign-Up/Login presentation layer code
• Develop Javascript sign up form validation code 

Now you can see how the sprint backlog gets formed and grows during sprint planning.  However, during sprint planning, you will not create the perfect plan. The sprint backlog is an adaptive plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

Consequently, they will update the sprint backlog throughout the sprint as they learn more and, as such, they create, re-order, add more detail, and delete as needed. 

Sprint backlog misconceptions and anti-patterns

Developers cannot change the sprint backlog during the sprint as it is a commitment

The myth is that the sprint backlog is fixed during the sprint and that developers must implement all the work items in the sprint backlog because they have committed to deliver them. If not, the sprint is a failure. Changes to the sprint backlog are not allowed and no work can be added or removed from it, as this creates a lack of focus and there is a risk of ‘goal’ creep. 

That’s not the case. 

The sprint backlog should not be static

The sprint goal is an objective set by the Scrum team during sprint planning. The sprint goal describes what the Scrum team wants to achieve during the sprint (to test an idea, hypothesis or run a test) and how it intends to be closer to the product goal.

Remember, Scrum was created to ‘help people, teams and organizations generate value through adaptive solutions for complex problems. The Scrum team—more particularly the developers who craft the sprint backlog—cannot predict the future and create the perfect plan. Complex work is highly unpredictable, so they cannot set a detailed plan in stone during sprint planning. The developers should refine the work that needs to be done based on what they learn once work begins. 

For example, let’s assume the developers create a new feature and change several existing features during the sprint. All this needs testing, regression testing, and code refactoring, which they expected; they could not anticipate the effort and amount of work required. So, the developers will need to add work items to the sprint backlog. Nevertheless, they remain committed to the sprint goal.

The sprint backlog changes based on ‘inspect and adapt’

The sprint backlog supports empiricism—the idea that knowledge comes from experience and deciding based on what the team observes (The Scrum Guide 2020). The Daily Scrum gives developers an opportunity to inspect and adapt their progress to the sprint goal and make any adjustments to the sprint backlog. 

A metric developers can use in a Daily Scrum to help support empiricism and manage the sprint backlog is Work Item Age. Work Item Age looks at current active work (the amount of elapsed time between when a work item started and the current time). Work Item Age is a leading indicator related to unfinished work items. It is a great metric; it enables transparency to which work items are flowing well and which are stuck in the mud and not progressing as expected. Using Work Item Age in combination with cycle time can help developers to focus on those items of work which are at most risk of missing the teams’ service level expectation, and make the necessary adjustments.

The Product Owner controls the sprint backlog and therefore can pull work items in and out whenever they feel like?

If a Product Owner pulls and adds work items into the sprint backlog at will, and developers just shrug and continue working, the developers are no longer committed to the sprint goal and lack ownership of the sprint backlog that is rightfully theirs. They have just become a feature factory and no longer align with a sprint or product goal, or value creation.

Developers own the sprint backlog and must maintain accountability

The Scrum Guide states that developers are always accountable for:

• Creating a plan for the sprint—the sprint backlog
• Instilling quality by adhering to a definition of done
• Adapting their plan each day toward the sprint goal
• Holding each other accountable as professionals

The Product Owner owns the product backlog

The Product Owner is accountable for effective product backlog management, which includes:

• Developing and explicitly communicating the product goal
• Creating and clearly communicating product backlog items
• Ordering product backlog items
• Ensuring that the product backlog is transparent, visible, and understood

To learn more about the sprint backlog and other important aspects of Scrum, check out our popular FAQ, What is Agile and What is Scrum?

Jags Singh