The three scrum artifacts are:
- Product backlog
- Sprint backlog
- Product increment
These scrum artifacts play a pivotal role in helping the scrum team deliver their best work.
Some teams consider the burnup and burndown charts as a part of the scrum artifacts. While these agile metrics are equally important, they represent only the historical details of the work done.
So what exactly are the artifacts of scrum? How do they connect to the scrum framework?
In this post, we’ll dive into each artifact in detail and look at how the scrum artifacts connect to the scrum framework.
What are scrum artifacts?
Scrum framework requires a cross-functional self-organizing team to work together. For this to be efficient consistently, the scrum team needs to have all the right information on what work should be done.
This is where the scrum artifacts come in.
The three scrum artifacts ensure the scrum team stay aligned as they work towards achieving the goal.
Scrum artifacts are the places where the team negotiates what work should be done, what their goal is, and how they’ll achieve the goal.
Even as new, unexpected things pop up, the scrum framework made sure the scrum artifacts also evolve to represent the new reality. It could be either the development team uncovering a technical roadblock. Or it could be a shift in market condition (hello work from home!).
All of this is taken into consideration through scrum ceremonies with the help of a scrum board.
Each scrum artifact answers one primary question:
Product backlog : What should the team work on in the next sprint?
Sprint backlog : What should the scrum team work in the current sprint? How will they achieve it?
Product increment : What will they team ship at the end of the sprint?
The three agile artifacts ensure it breaks down large bodies of work into smaller, focussed work. This allows the scrum team to focus on the relevant work and ship the most important work.
The scrum artifacts together promote:
Scrum Values: commitment, courage, focus, openness, and respect
Pillars of Scrum: transparency, inspection, and adaptation
Minimizes unnecessary work
Let’s take a closer look at the function of each agile artifact.
Product backlog
The product backlog is practically a giant list of everything you’d want your team to build.
The product backlog includes new features, enhancements, bugs, and small tasks that need to be worked on to improve the product.
The work items (which are mostly either user stories or bugs) in the product backlog often comes as an input from the customers. Sometimes, depending on the organization, even team members add their inputs to the product backlog.
Of course, this means the product backlog will be an endless list. Unless you have an army of developers and designers on your payroll, you will not be able to build everything that’s on the product backlog. This is where the product owner will play an important role.
The product owner will be responsible for prioritizing the items in the backlog. By talking with the customers and internal stakeholders, the product owner collects feedback and data points to make data-backed decisions that will positively impact the product.
It is the product owner’s responsibility to keep in mind the business goals and the product roadmap while prioritizing the product backlog. Each item in the product backlog goes through what’s known as backlog grooming.
It looks like this:
- Review each backlog item carefully.
- Remove duplicate items and unwanted items.
- Edit or rewrite the user stories based on the newly available information.
- Add story points to each of the prioritized items. This usually isn’t an accurate estimate, since the developers usually have a better understanding of the complexities involved. That’s it’s always better to involve a developer during this process so that the estimates aren’t off by a large margin.
- Add acceptance criteria for the prioritized list of items.
This product backlog will act as an input to the sprint planning meeting. This makes it critical that all of the above-mentioned steps must be done before the beginning of the next sprint’s sprint planning meeting.
During the sprint planning meeting, the product backlog is presented to the entire scrum team where the product owner describes each prioritized item in the product backlog. He/she shares why they are the highest priority and how it connects to the business goals and the roadmap.
From here, the sprint backlog is derived. Let’s look at it in detail.
Sprint Backlog
The second artifact in scrum is the sprint backlog. As I mentioned previously, your team will not be able to build everything added in the product backlog.
This is where the sprint backlog comes in.
The sprint backlog is the most fundamental part of the scrum sprint. It’s practically a filtered, prioritized version of the product backlog. The sprint backlog allows your team to focus on the most important work and commit to shipping it at the end of the sprint.
So, how does the team decide on the sprint backlog?
Once the product owner describes the product backlog and why it’s a priority during the sprint planning meeting, the development team will ask questions to understand the product backlog better. This helps the development team to come up with a more accurate estimation of how long each item would take to complete.
As you can see this is a collaborative effort by the entire scrum team. The product owner answers all questions the development team has. The scrum master facilitates the meeting. And the development team gives an estimate of what can or can not be done within the sprint duration.
Once the estimation points are added to all the items by the development team, the entire scrum team negotiates on what should be included in the scrum backlog.
It often looks like this:
After looking at the estimation points added by the development team, the product owner realizes that all prioritized items can not be built within the current sprint. This requires the product owner to make sacrifices.
Some product owners may try to squeeze a few items in, but the development team should push back and let the product owner understand that it will not be possible to build a shippable version by the end of the sprint.
This back-and-forth negotiation goes on until the team comes to a shared commitment on what will be shipped at the end of the sprint. Ultimately, the development team will own the sprint backlog since they’re the ones who will be working on them.
This makes it essential that the development team push back if they believe they can not deliver a shippable version at the end of the sprint.
Product Increment
The product increment is the output of the Sprint and the sprint backlog. Everything that was committed in the sprint backlog is delivered by the development team as an increment to the product.
The product increment should be a usable and potentially shippable version of the product.
This means the product increment should not require any more testing nor further development. It should ideally be in a position where if the scrum team wants, they can ship it to production for the customers to use the product.
In theory, it sounds simple. However, in practice, the scrum team must ensure everyone has a clear understanding of what the product increment will be at the end of the sprint.
A shared understanding of the definition of product increment sets the right expectations for the development team. It helps them estimate better and work with clarity. And once the sprint is completed, it can also help during sprint retrospectives.
If there is no shared understanding of what “done” looks like, the scrum team should make sure they have one before the sprint begins.
Other Scrum Artifacts
Earlier in this post, I mentioned some teams call burnup and burndown charts as a scrum artifact as well. Let’s look into them.
The burnup and burndown charts represent the quantity of work remaining in the sprint versus time remaining in the sprint.
The burndown chart shows the number of work items remaining while the burnup chart shows the number of items completed.
These agile metrics can be used to view the team’s progress, identify roadblocks during daily scrum meetings, unearth problems during sprint retrospectives.
Top comments (0)