Sprint Backlog

The Scrum Guide – 2020

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is 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. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

We learned in the previous sections that the Product Owner and the Developers negotiate which backlog items would fit into the Sprint (referred to as ‘what’). But what is the mentioned plan? The Guide leaves it up to the team. The evolution of the Guide led to the surprising situation that even though the physical board with the cards is a visual identifier of Scrum, the official guide does not even refer to it in any way. It is not a compulsory part of Scrum anymore, but learning about the basics is still a good idea.

The Plan Part of the Sprint Backlog – the ‘how’

The popular agile approach for making a plan is creating a task breakdown list for every Product Backlog Item and estimating the tasks in hours. If the Scrum Team uses a Kanban board – which is actually a Scrum board in Scrum – these tasks are in the To-Do column. When the developers start the work on a particular item, they place it into the In Progress column, and when finished, into the Done column. For that one, it should obviously meet the Definition of Done. However, the name of the columns and the number of work phases are up to the Developers.

As mentioned in the Scrum Guide, the Sprint Backlog is a plan by and for the Developers. They are the experts who should be able to create, maintain and execute a plan. In terms of transparency, the Sprint Backlog is not necessarily open to all stakeholders and the entire organization. From a development point of view the more transparent the plan the better. From a business point of view, we only need to know the status of Product Backlog items, so highly sensitive issues can remain secrets. To be fair, this is an atypical situation, e.g. when data mining supports an ongoing litigation process. In contrast, working on ‘disruptive new technology’ is not a good excuse to reduce transparency.

The Sprint Backlog is subject to change, but it is important to point out that Product Backlog items (the ‘what’ part) are not supposed to be added or removed during the Sprint. As mentioned in the Sprint chapter, if the Scrum Team agrees on a Product Backlog level change, there is no reason to deny the team to do so, but the Guide excludes unilateral changes. In contrast, tasks (the ‘how’ part) evolve throughout the Sprint.

Task Ownership and Code Ownership

In the Agile world, the entire team owns the codebase and the tasks. Apart from situations when team members are highly specialized in certain technologies, tasks are never assigned to a single team member. Anyone can pick a task that is not yet in progress, and anyone can modify a task even if it was previously thought to be Done. Work in progress, however, practically means ‘no touching’ for everyone else, the task has a temporary owner. In practice, developers often use an avatar to mark their tasks.

Commitment or Forecast?

In the first Scrum Guide, the Developers made a commitment to deliver the Product Backlog items of the print. It was often interpreted as ‘the team promised to deliver everything they planned for the Sprint’. From the 2011 version, the team made a forecast but was not required to make a “promise” which may not be possible to keep. (In fact, as Ken Schwaber explains, the word ‘commitment’ was never meant to be a promise but rather a mission. However, most people understood it as a promise.) One of the main principles of Agile is expecting unforeseen changes, circumstances and complexities. Requesting the Developers to make a hard commitment is an unfair contradiction to this principle. The 2020 version further clarifies that “The Sprint Goal is the single objective for the Sprint”, hence the Developers do not even commit to delivering individual Product Backlog items. On the other hand, they are committed to reaching the Sprint Goal.

Monitoring Sprint Progress

Up until 2020, the Guide sacrificed a small chapter to this topic. Since it is more a matter of tools and techniques, there is really no need to elaborate on this in the Scrum Guide. However, this is still important for the readers, learners, and practitioners, therefore we should not drop it from the commentary.

We can monitor the Sprint’s progress in various ways, for instance:

• By updating the Sprint Backlog daily;
• The team has a Daily Scrum meeting where they discuss the status;
• There are many agile practices a team can choose from to visualize progress. The Scrum Board gives an immediate impression through the position of the tickets. The burndown chart is a popular solution to visualize the progress of work.

Warning: The burndown chart is not a Scrum artifact, it is an arbitrary technique. Because of its popularity, it is included in the lesson as an example. However, test questions would penalize identifying the burndown chart as an element of Scrum.

A Thought on the Physical Scrum Board

Before the widespread use of web-based Scrum tools, the physical board was the only viable solution to have a board at all. Even with the appearance and spread of digital boards, the visual power of a physical board and its practicality during Daily Scrum remained unmatched. On the other hand, while the physical boards are ideal ‘information radiators’, using a digital issue tracker tool is almost impossible to avoid. The unfortunate result is that many teams maintain 2 versions of the Spring Backlog. The future of the physical board as a good practice is questionable:

• Ecology: The physical duplicate of a digital registry is a waste of paper and other resources;
• Info-security: Organizations spend billions of dollars a year to secure access to their systems and to protect their information assets. Publishing large amounts of potentially sensitive information in a shared open space, where visitors and third-party office maintenance personnel can read everything, is a questionable practice. Clean desk policy does not go well with information-rich physical Scrum Boards.
• Teams are less and less co-located. Some experts work offshore, some from home, some from another building. In the post-COVID-19 world, it will be difficult to justify and reinstate physical boards and find the time to regularly update them.

Key Takeaways

• The Sprint Backlog is the Developers’ artifact.
• The Sprint Backlog should be updated regularly to reflect the status of the work.
• The objective of the Sprint is the Sprint Goal, not the items in the Sprint Backlog.
• It can be renegotiated during the Sprint.
• The Spring Backlog should be detailed enough to start a Sprint, and detailed and modified as more is learned.