Understanding the “why” behind the Scrum framework can help Scrum teams improve their ability to deliver value to the organization. We previously discussed the purpose behind each Scrum event and the purpose behind each Scrum accountability. In this article, we’ll take a deep dive into the purpose of each Scrum artifact.
The Scrum artifacts
As the Scrum Guide points out, the framework’s artifacts represent work or value and maximize the transparency of key information. The artifacts allow everyone to review and adapt work from the same information base.
The artifacts include:
The Product Backlog
The Sprint Backlog
The Increment
Let’s look at each artifact to discover why they are part of the Scrum framework.
The Product Backlog: Everything we know the product needs
The Product Backlog is a visible, ordered list of everything we know we’ll need to do to deliver the product and what the team will work on next. The Product Owner is accountable for the content and order of items in the Product Backlog, whereas the Developers size those items.
I can’t overstate the value of having this single source of information for what work comes next. Think of how many organizations struggle with prioritizing projects, initiatives, keeping-the-lights-on work, operational work, upgrades, technical debt and more. In many instances, different people are accountable for the success of each of these types of work. At the same time, the resources to deliver the work may reside in various parts of the organization.
The Product Backlog offers simplicity by providing a single source of “truth” with one person deciding on the order of work items. It’s like solving a Gordian knot with a single swipe!
Having a single Product Owner responsible for balancing the needs of the various stakeholders in the organization cuts through the confusion which holds many organizations back from delivering value.
But beware! The product definition must be sufficiently broad to enable that single list of items. If we define the product too narrowly, we will still have multiple competing priorities. The organization may have created several siloed teams in such a situation. Sometimes teams become siloed based on technology resulting in the organization having multiple Product Owners and Product Backlogs, delaying value delivery due to handoffs and decreased team focus. (See our article What to consider in your transition to Scrum for guidance on how to avoid siloed teams.)
Sprint Backlog: The why, what, and how
The Scrum Team creates the Sprint Backlog during the Sprint Planning event. It contains a list of the Product Backlog items (PBIs) the Developers have selected to deliver in the upcoming Sprint. The Sprint Backlog also includes a plan for delivering the selected Product Backlog items and a Sprint Goal summarizing the purpose of the Sprint.
As more and more teams have gone remote, the adoption of Scrum has increased dramatically. I believe that there is a correlation between the increase in remote work and the increased adoption of Scrum. The Scrum artifacts – particularly the Product Backlog – provide the transparency necessary to enable remote teams to better coordinate their work and review the progress of work during the Sprint. At any time, a Developer – or anyone with access to the Sprint Backlog – can see how work is progressing not only on their items but on all items which have been planned for the Sprint.
In addition, the fact that Developers own the Sprint Backlog reinforces their autonomy in controlling how to approach the work of the Sprint. During the Sprint Planning event, the Developers select the PBIs they agree they can deliver in the upcoming Sprint. No one—not even the Product Owner—can demand the team deliver more than they have deemed reasonable in a Sprint. By reinforcing the autonomy of the Developers in controlling their work, the Sprint Backlog promotes self management. This self-management increases the effectiveness of Scrum teams because Developers control how work is delivered.
The Increment: The stepping stone toward the Product Goal
If I had to sum up the purpose of Scrum in a single sentence, I would say it is to deliver a valuable increment of usable product every Sprint. It sounds easy, but moving an organization to incremental delivery involves a significant mindset change. Think about a traditional team working on value delivery for a goal several months in the future. That team is thinking about their end goal only. By contrast, teams using incremental delivery think not only about the end (product) goal but also about how to deliver value along the way by producing functionality each Sprint.
It is Incremental delivery that provides many of Scrum’s benefits. Teams using incremental delivery reduce risk because they can change direction more easily. They deliver customer value sooner as a result of how they approach their work, and the element of transparency ensures that partners and stakeholders can always see what the team is working on, which promotes communication and understanding. Incremental delivery is at the heart of Scrum, yet its value is often overlooked.
Many people think that by using all of the events, they are “doing Scrum.” But, if a team is not delivering a usable increment of functionality every Sprint, they have not fully embraced the Scrum framework and are not realizing all of its benefits.
Conclusion
When I work with teams to improve their Scrum practice, it often involves unpacking the “why” behind the framework. When we understand the purpose behind the events and artifacts, we can commit to them more wholeheartedly to reap their benefits. In this article, we examined the purpose of the Scrum artifacts, which maximize the transparency of information. Transparency allows us to inspect and adapt how we work for improved outcomes.