The 3 Scrum Artifacts and How They Can Help You
Scrum artifacts play a vital role in building a picture of Scrum team progress, so let’s talk about what exactly that role involves and why it’s useful.
The three Scrum artifacts are the product backlog, the sprint backlog, and the product increment. There are other reference points the team uses to plan their work—burndown, burnup, and Gantt charts, for example—which could be considered Scrum artifacts, too. I don’t count them, though, and I’ll explain why.
First, here’s an overview of the three Scrum artifacts and how they fit together. After that, we’ll take a deep dive into each Scrum artifact. By the end, you’ll understand what makes them effective (hint: transparency is key).
What are Scrum artifacts?
Scrum relies on small teams of cross-functional members who can self-organize in order to get work done. For this to happen, the Scrum team must have a shared understanding of the work to be done. That’s where Scrum artifacts come in.
Scrum artifacts keep all team members coordinated as they work toward the sprint goal. Even as major or last-minute changes crop up, Scrum artifacts evolve to capture (through Scrum meetings and using tools like Scrum boards) the key information the team needs at certain checkpoints to get to the finish line.
In a basic sense, each Scrum artifact answers a question:
- Product backlog: What will the Scrum team work on next sprint?
- Sprint backlog: What will the Scrum team work on this sprint and how will they get it done?
- Product increment: What will the Scrum team have made by the end of this sprint and how will they know it’s “done”?
Picturing the Scrum workflow with Scrum artifacts in focus, you can see how the team tracks potential software changes as they are planned, created, and implemented.
Scrum artifacts break down the workflow for Scrum teams, allowing them to concentrate on small amounts of relevant work that will result in shippable increments. By shippable, I mean ready to be released without further work. The product increment has to be “done,” which isn’t as simple as it sounds (more on that later).
As the team plans the work to be “done,” Scrum artifacts serve as highly visible representations of work (or value) that:
- Promote transparency of key information
- Provide opportunities for inspection and adaptation
- Minimize unnecessary work-in-progress
As I said before, Scrum artifacts evolve with every new piece of team intelligence. This could be developers uncovering technical problems. Or it could be new regulations or changes in the market. For artifacts to actually be useful means constantly adjusting them to changing conditions.
Let’s take a closer look at how they function.
Product backlog
The product backlog is essentially a master list of all the changes that could be made to a product. These changes might be enhanced features, fixes, or technical work needed to keep the product functional and competitive.
We think of these changes as input from users about what they want or need the product to do. Sometimes they are called user stories or backlog items. For the Scrum team, these user stories represent work that needs to get done. The product backlog collects all this potential work in one place to give everyone a shared roadmap of the work ahead.
Of course, the number of potential software changes that could be made to a product is virtually limitless. What’s limited is the team’s capacity to deliver them. In that sense, the product backlog is a space where the team, chiefly the product owner, can coordinate a workload that is both manageable and conducive of positive product results.
Part of managing the workload is prioritizing it. The product owner is responsible for ranking backlog items by importance to make sure the Scrum team works on the most appropriate user stories first. By interfacing with customers and other external stakeholders, the product owner is best positioned to collect data on and make decisions about what to build next.
At the same time, maintaining an effective product backlog is a team effort. The development team collaborates with the product owner to refine the backlog. Product backlog refinement, also known as backlog grooming, may include:
- Prioritizing: As circumstances change, backlog items shift in value and priority. Is the team slated to work on the most needed items, given what they know right now?
- Estimating: During the sprint, the team may discover that estimates for which items to prioritize were way off. Before the next sprint, you’ll want to revisit any estimates you arrived at using old models or data.
- Adding: New user stories have to be translated into new backlog items. There might also be technical debt the product owner can’t see that needs to be accounted for in the backlog.
- Refining: The more is understood about a backlog item, the closer it is to being ready for the Scrum team to take on. Do they understand the scope of the item, including an agreed upon definition of done?
The product backlog is a dynamic artifact—it evolves as more users test new use cases. Then it distills infinite product possibilities down into a single, viable, ordered list that promotes transparency into organizational priorities.
Sprint backlog
The second Scrum artifact is the sprint backlog. Think of it as a subset of the product backlog plus tactical information. It includes the specific backlog items the Scrum team will deliver during the current sprint and a plan for how to deliver them.
So, how to decide which backlog items to include?
The development team forecasts its capacity—how many backlog items they can complete during the sprint—and estimates an appropriate number of highly prioritized items from the product backlog. From there, these items are broken down into smaller tasks the team can start working on.
Like the product backlog, the sprint backlog is fluid. As issues arise and priorities change, the development team adjusts the sprint backlog as necessary. If tasks are found to be unnecessary, they are dropped.
The difference is that the development team alone controls the sprint backlog, and while the product backlog looks to the future, the sprint backlog provides a present-day snapshot of the progress being made and the work left to do.
That said, it’s the Scrum master’s tool of choice for helping the team inspect, adapt, and plan accordingly.
How close are estimates to actual results? Do functionalities promised by the development team meet end user needs? Do all stakeholders understand what the development team means when they say “done”? The sprint backlog helps guide the team in these and similar areas.
Product increment
The product increment is the output of the sprint. It constitutes a useable, potentially releasable version of the product. In theory, no further development or testing is required and the product owner could release the increment immediately.
In practice, as you’ve heard a few times now, the product increment needs to get “done.” If there is no convention for what constitutes as “done,” Scrum teams are responsible for defining one.
Again, this definition is fluid, but always in sight. No matter where they are in the sprint, the team needs a shared reference point to work from. Any “done” increment needs to be understood and agreed upon by all development team members and must align with the potentially releasable functionality expected by the product owner.
Product increments are additive, which means that they build on previous iterations of the product. By the end of several sprints, the Scrum team will have delivered multiple product increments, each improving on the next in the endless quest to meet user needs.
Teams that are just starting out may have to work for a while to develop a predictable cadence. Over time, they will better understand their capacity and cross-functionality to better estimate backlog items. The hope is that these product increments satisfy an ever more fine-tuned definition of done.
Other Scrum artifacts?
Some people consider burndown charts and other visual measurement tools to be Scrum artifacts. Yes, these agile metrics capture team progress at a given point in time, which can be incredibly helpful for coordinating tasks. But can they really be classed as Scrum artifacts?
I say no. They’re no less valuable, just different. Scrum metrics are byproducts of the work done by the team. Whereas Scrum artifacts are the places where the team negotiates its direction, its strategy, and its tactics. Metrics are snapshots in history; artifacts are living repositories of ideas.
Which brings me back to the key to their success: transparency. Because artifacts are always changing, they should always be visible.
When the whole team is committed to the transparency of its artifacts, everyone can contribute their technical knowledge in a helpful way. Developers who feel safe talking about potential problems will benefit product owners looking to accurately manage the work.
