Scrum Artifacts: Product Backlog, Sprint Backlog and Product Increments

By Sruthy

By Sruthy

Sruthy, with her 10+ years of experience, is a dynamic professional who seamlessly blends her creative soul with technical prowess. With a Technical Degree in Graphics Design and Communications and a Bachelor’s Degree in Electronics and Communication, she brings a unique combination of artistic flair…

Learn about our editorial policies.
Updated January 24, 2025

Introduction to Scrum Artifacts:

In the previous articles of this series, we were introduced to agile and the different agile methodologies. We also learned about how the various methodologies are different in their own way.

In our last tutorial, we went into the details of Scrum where we discussed the Scrum roles like Product Owner, Scrum Master, and the scrum team and saw what their individual responsibilities were. 

In this tutorial, we continue with Scrum and move further into the details about the different scrum artifacts.

Scrum artifacts

Different Scrum Artifacts

3 types of scrum artifacts include:

  • Product backlog
  • Sprint backlog and
  • Product increments

Now we will see what these terms mean and how to create these artifacts.

Scrum Artifacts-types

Product Backlog

To put it in simple terms, a product backlog is a list of all the things that are required in the product. It’s the final document to be referred to by the scrum team for anything related to the product. It’s an ordered list of items which is owned by the Product Owner (PO).

The PO is responsible for creating, maintaining and prioritizing this list. The POs use this product backlog to explain the top requirements that need to be done during the sprint to the scrum teams.

The items in this list may or may not be in a technical language. It can even be a layman’s language, but it should contain all the product requirements and the accompanying changes. Also, having a product backlog doesn’t mean that the scrum team will only have this artifact to follow.

They can create their own detailed artifacts but those won’t contradict or replace the product backlog. They will rather be in an alignment with the product backlog requirements.

Below is an Example of what a typical product backlog can look like:

StoryEstimatePriority
I want to login41
I want to logout22
I want to change password13
I want to update address34
I want to add a new home phone number15

This brings us to the question, how to create a good product backlog?

A product backlog should ideally follow the below rules:

(i) It should be prioritized – The items in the product backlog should be ordered as per their priority. This priority can be decided by the PO and the scrum team together. The prioritization factors can be any like benefit from the story point, the effort involved in the creation, complexity, customer priority etc.

It helps the team in understanding what needs to be delivered first.

(ii) It should be estimated – The stories should always be estimated as per the agreed definition, whatever that might be. This can be used for prioritization as well.

(iii) It should be high level – The stories in the product backlog are meant to be high level and should not go into the details. Creation of detailed user stories as per the requirement is up to the scrum team and not the PO.

(iv) It should be dynamic – The product backlog is not a final static document. It should be revisited as the PO receives inputs from the scrum team and the customer requirements become more and more clear. Thus the document requirements are not frozen right at the beginning because there are additions/      deletions/modifications expected as the project progresses.

The last point is the most relevant one. The purpose of a product backlog is to be an active requirement source. It is not to be created at the beginning and then kept at a storage location.

Instead, it is meant to be shared again and again as the changes keep coming up. New requirements might come up as the progress is made and that might change the priority of the backlog items as well. There will be situations where a new requirement is dependent on another item in the backlog so the item priority might need to be reshuffled.

Or there might be a critical user story which might have to be implemented first because the customer wants to see that before the others even though it might not be high on priority as per the factors decided by the PO and the scrum team.

Thus the product backlog is an ordered list of business requirements owned by the PO and visited on time again and again as the project progresses.

Sprint Backlog

You might remember that the scrum teams work in short iterations of 2 to 4 weeks called a sprint. During these sprints, the scrum team identifies the items from the product backlog created by the PO, which they plan to deliver as a part of the next iteration. The items which the scrum team selects to work upon become a part of the sprint backlog.

Thus they decide what functionalities are going to be there in the next iteration of the product. The scrum team is the one who decides what will go into the sprint backlog as they are the ones who are going to work on it.

Thus they are the ones who should be estimating the effort involved in implementing those stories and deciding how much they can deliver.

The team not only picks the items from the product backlog to work upon, but they also put an estimate on how much time it will take for them to develop that functionality. They also add to the high-level user stories by creating detailed tasks required to achieve the sprint goal.

The scrum team can also keep updating the sprint backlog as and when required during the sprint, but it is only the scrum team who can make changes to the sprint backlog.

A typical Sprint Backlog will look as shown below.

Sprint Backlog

The team can ideally update this once a day and the scrum master can use this information to create a sprint burndown chart. This burndown chart will help the team see how much work is still remaining for the sprint and the team can plan their work accordingly. They can even add or remove tasks if required.

Some best practices while creating a sprint backlog can be:

#1) Make group decisions – It should not be the scrum master or any other scrum team member deciding the backlog. Rather, it should be the whole team together deciding on which items to include in the sprint backlog and how to plan for them.

Every member of this cross-functional team brings their own skills and it is essential that we utilize their experience to create the best possible backlog.

#2) Don’t assign tasks – As it has been repeated multiple times in the agile literature, never assign tasks to the team members. A scrum team is supposed to be self-sufficient and they should know how to organize their work on their own.

So instead of assigning work, we should let the team pick work for themselves and decide amongst themselves on how they want to proceed.

#3) Definition of done – It should not just be agreed upon by the stakeholders, but also be made clearly visible to the team at all points whenever they have to take any decision regarding the sprint goals. This will serve as a reminder of what exactly needs to be done before they can deliver a working shippable product.

#4) Keep updating the backlog – It is imperative that as the sprint evolves, the team will gain a greater understanding and hence they should accordingly update the sprint backlog to reflect this greater understanding as well. It should not become a static document at any time.

#5) Add any task – The task need not just be related to coding but it might be essential to deliver a shippable product. Hence mention such tasks in the backlog as well.

Product Increments

This brings us to the last scrum artifact which is the product increments. As defined by the scrum guide, an Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. As we know well by now, Scrum is an iterative process.

The result of each iteration is this product increment and each such product increment helps the team to take a step closer towards delivering the end product.

What this means is that whatever was the result of the sprint is an increment. Obviously, for the result to be considered an increment, it should first meet the pre-defined definition of done i.e. the end result should be a usable product which is capable of “shipping”.

It can be checked, used and tested to ensure that it is indeed “done” as per the definition and if the Product Owner wishes, it can be released to go live as well.

The most important thing to deliver this product increment is to have a shared understanding of the “definition of done” which is understood by all.

The scrum team should never be in a doubt whether what they are doing will be accepted or not. If there is any doubt, the definition of done should be complete enough to guide them on how to proceed further. Based on this definition only, the scrum team decides how many product backlog items to pick for the sprint.

This is the minimum as what is expected out of the sprint.

Conclusion

From this tutorial, we have understood what are the 3 scrum artifacts, who owns them along with some of the best practices which would help us create better quality artifacts. In our next tutorials of this series, we will discuss the Scrum events and see how to execute those events.

In our upcoming tutorial on ‘Scrum Events,’ we will be discussing each of the Scrum Event in detail!

PREV Tutorial | NEXT Tutorial

Was this helpful?

Thanks for your feedback!

Leave a Comment