A Scrum Dilemma: Who does the “other work” that is not part of the Sprint Backlog?
I recently came across this interesting question on LinkedIn:
…in the scrum guide it says “the scrum team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, and development, and anything else that might be required,” and later it says “the sprint goal is the single objective of the sprint.” It also says that the sprint backlog “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 implication is that there isn’t any other work going on in the sprint that isn’t related to the sprint goal, but at the same time, the team is responsible for operations and everything else mentioned above.
So my question is, according to scrum theory, where does all the other work go that the team is responsible for that is not in the sprint backlog?
One of the common questions that often arise is regarding the Scrum Team’s responsibilities and how they manage other non-sprint-related work, such as Business As Usual (BAU) tasks, maintenance, and operational activities. This confusion arises from the statements in the Scrum Guide that emphasize the importance of the Sprint Goal and the Sprint Backlog while also highlighting the Scrum Team’s accountability for various product-related activities. In this blog post, we will delve into Scrum principles to shed light on this apparent contradiction and attempt to clarify the Scrum Team’s responsibilities.
The Scrum Team’s Responsibilities
According to the Scrum Guide, the Scrum Team is a self-organizing and cross-functional unit that collectively assumes accountability for delivering a potentially releasable product increment at the end of each Sprint. Their primary responsibility is to work towards achieving the Sprint Goal, which is the single objective of the Sprint.
Sprint Goals and Sprint Backlog
The Sprint Goal is a concise description of what the Scrum Team aims to achieve during the Sprint. It serves as a guiding beacon for the team, aligning their efforts towards a common purpose. The Sprint Backlog, on the other hand, is a dynamic, real-time representation of the work planned for the Sprint to achieve the Sprint Goal. It includes all the Product Backlog Items (PBIs) that the team commits to completing during the Sprint.
The apparent confusion arises from the understanding that the Sprint Backlog exclusively encompasses all the work that the Scrum Team undertakes during the Sprint. While it is true that the Sprint Backlog captures the tasks and PBIs directly related to the Sprint Goal, it does not necessarily cover all the other product-related activities that the Scrum Team might be responsible for.
The Scrum Team’s Extended Responsibilities
As stated in the Scrum Guide, the Scrum Team is responsible for “all product-related activities” beyond the Sprint Backlog. This includes a wide range of tasks, such as stakeholder collaboration, verification, maintenance, operation, experimentation, and development. For instance, in a Two-Pizza Team setup like Amazon, where a small team handles an entire service or product, the Scrum Team is responsible for operational tasks such as monitoring, responding to incidents, and ensuring the service’s availability.
Striking the right balance
To balance the operational work and maintain a sustainable pace of development, some teams adopt a rotational role approach. In Amazon Two-Pizza Teams, one (or more) team members might take on the “rotational” role of being “on-call” for a specific week, handling operational incidents and issues. However, the capacity of the “on call” person is not considered during Sprint Planning. This approach ensures that operational responsibilities are distributed fairly within the team without impacting their commitment to the Sprint Goal.
To conclude, the Scrum Team’s responsibilities encompass both Sprint-related work, which is captured in the Sprint Backlog and aligned with the Sprint Goal, and other product-related activities that go beyond the Sprint Backlog. By leveraging self-organization and cross-functionality, the Scrum Team collaborates to deliver value while also taking ownership of product maintenance, operations, and other essential tasks. Scrum principles empower teams to be adaptable, responsible, and self-managing, ensuring that they strike a balance between Sprint Goals and other necessary product-related activities for successful and sustainable product development.
