What are the various Scrum artifacts and how do you explain them to your team?

In this article, you will learn the different Scrum artifacts with examples and real-world scenarios. This will help you to gain a better understanding of the important aspects of Scrum. You can use this knowledge to further help your Scrum team to learn and imbibe these concepts. If you are an experienced Scrum Master handling Scrum teams then, this article can refresh your knowledge or if you’re an aspiring Certified ScrumMaster (CSM) certification candidate then this can provide you with information on Scrum artifacts concepts to prepare for your CSM certification exam.

Introduction to Scrum Team

Before we discuss the various Scrum Artifacts, let’s briefly understand who makes up a Scrum Team so that it becomes easier to learn about Scrum artifacts.

A typical Scrum Team always consists of three roles: the Product Owner, the Developers, and the Scrum Master.

In simpler terms, let’s use a soccer analogy to understand a Scrum Team. The Product Owner is like the captain of the team, they ensure the right strategy is in place for the game, direct the players and decide how to constantly improvise their game plan on the field. The Developers are the players on the team, the contributors on the field, who score goals, adapt to the strategies, and improvise their quality by the end of the match. Finally, the Scrum Master is the team coach, they monitor everything that’s happening on the field and off the field. They provide all the necessary guidance and coach the team whenever the performance is going sideways.

Each of these three Accountabilities has specific rights and responsibilities that are classified for the game. Similarly, Scrum Teams in organizations are self-managing, have accountability, and contain less than 10 members who are the key contributors to generating value like winning a game or tournament. For a soccer team, the value is that they score the goals with minimum to no fouls and win the game. Whereas, for a Scrum Team in a software team the value is to develop a piece of software with quality and little to no bugs in the final production.

What are Scrum Artifacts?

According to the Scrum Guide, “Scrum’s artifacts represent work or value. They are designed to maximize the transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.”

We understood that in the previous section that the Scrum Team aims to achieve a certain value or accomplish a work. Scrum artifacts are a representation of this value. In Scrum, three artifacts are defined to help Scrum Teams plan, organize, develop and manage work or value produced by the team.

Scrum artifacts ensure that everyone in the team knows what the expectation is, the criteria, and the strategic actions the team takes. Scrum artifacts have individual commitments that are specific, and provide transparency and measurable pointers. We will discuss the commitments in the subsequent sections.

The following are three Scrum artifacts:

• Product Backlog
• Sprint Backlog
• Increment

How do you explain Scrum artifacts to your team?

Product Backlog

An ordered list of items called Product Backlog Items (PBIs) that are needed in a product based on the product goal. It is constantly evolving and is never complete. Although it is an ordered list, the order of the items can change, therefore it is dynamic and has varying levels of details.

Using our soccer team analogy, we can say that the Product Backlog is like a roadmap with various stages to reach or plans that are required to win the FIFA world cup or any such tournaments. In a software environment, it can be any software product or an improvement in the product or service that delivers value in the end.

The Product Owner maintains the Product Backlog and the Scrum Team (specifically the Developers) uses it as the source for further defining the work. The Developers are responsible for identifying, sizing, and developing the value of the work taken from it. And the commitment to the Product Backlog is the Product Goal.

Before we discuss Product Goals, let’s understand something called Product Backlog refinement. Scrum Guides defines it as “the act of breaking down and further defining Product Backlog items into smaller more precise items.” This activity helps to make appropriate preparations to meet a particular goal, which is the Product Goal.

You can think of the Product Backlog refinement as an ongoing team meeting to discuss and come up with training routines, diet plans, and practice to win the tournament.

And the Product Goal is equivalent to winning the FIFA world cup.

Sprint Backlog

A list of items that the team commits to achieve in a given time frame which in Scrum is referred to as a Sprint. Sprint Backlog items contain detailed, visible, and actionable plans to achieve the Sprint Goal. Sprint is a timebox maximum to a month. As you may have guessed, Sprint Goal is the commitment for the Sprint Backlog.

In the case of our soccer team, Sprint Backlog can be compared to achieving a certain milestone in a specific timebox such as a specific number of days or a week, or a month.

Now, the Sprint Goal is to achieve these milestones in this timebox. For example, sticking to a high-protein diet plan during the practice week, early morning kicking practice sessions for two weeks, improving the goal-scoring skills by 1 point every other practice match, or scoring three goals by each forward and midfield player in three league matches.

For a software application, it can be a certain functionality that needs to be created by the Scrum Team adhering to the best practices. The Sprint Goal is created by the Scrum Team during the Sprint Planning event and afterward gets added to the Sprint Backlog. Sprint Goal does not change but allows everyone to collaborate and work with a Focus.

Increment

A deliverable from the Scrum Team which meets a specific condition that is set and agreed with the Product Owner. The increments are produced during each Sprint and presented to stakeholders by the Developers. The commitment to an increment is the Definition of Done (DoD).

According to the Scrum Guide, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” This means the developed value isn’t considered complete and releasable without meeting DoD.

In our soccer team analogy, an increment is like every action that gets the team closer to achieving the Sprint Goal and eventually the Product Goal. For example, winning all the “Group matches”, winning the “Round of 16” and so on. Also, by ensuring that the team achieves these without compromising on the requirements such as minimizing the on-field injuries and fouls. Because this will impact the team performance, which in turn affects the Sprint Goal. Hence it is crucial to meet DoD and achieve the Sprint Goals.

Similarly, in a software environment, if a particular application feature works as expected but doesn’t comply with standards mentioned in DoD then it is not considered an increment.

FAQ