Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *

Industry

Tell us why you're considering making a switch:

Blog

Scrum Artifacts - An Introduction

14 Sep 2018

Scrum is, at its very core, a superbly stripped down and simple framework, despite what you may have heard from people who experienced various kinds of Scrum-like mutant situations.

Scrum prescribes the bare minimum of roles, events and artifacts needed to enable and support an empirical approach to developing, delivering and sustaining complex products.

In this article, we will be focusing on Scrum artifacts, why they exist and how they tie in with the rest of the Scrum framework.



CONTENTS

The Three Scrum Artifacts

Product Backlog

Product Backlog Items

Evolution of Product Backlog

Product Backlog Refinement

Sprint Backlog

Sprint Planning - Creating the Sprint Backlog

Changing the Sprint Backlog

Tracking Sprint Progress

Increment

Adding Value to Previous Increments

Definition of Done

Commitment to Transparency

Transparency as Scrum Master’s Responsibility


 

The Three Scrum Artifacts

Scrum recognizes and prescribes three Scrum artifacts which maximize transparency and promote a shared understanding of the work. These three artifacts are the Product Backlog, the Sprint Backlog and the Increment.

Product Backlog

The Product Backlog is an ordered list of everything that is needed to develop, deliver and sustain a product. Only one Product Backlog exists for a product, listing all of the features, requirements, functions, enhancements, fixes, learning and experimentation and anything else that will contribute to the product.

Product Backlog Items

All of these are expressed as Product Backlog items which have the following attributes:

  • Description
  • Order
  • Estimate
  • Value

In addition to these, Product Backlog items will often also entail test descriptions which will be used to determine if the items are truly completed (“Done”).

Evolution of Product Backlog

Early in the development of the product, the Product Backlog will contain only the best-understood, big-picture requirements and it will evolve over time as new information becomes available.

Woman writing app concept on whiteboard

This new information will come from a variety of sources - the evolution of the product itself, external and internal stakeholder input, user feedback, marketplace changes, the Development Team’s observations and more.

Product Backlog Refinement

As a result of this, the Product Backlog is constantly being refined so as to best serve the Scrum Team and the product development process. The Scrum Team as a whole decides on how and when to do Product Backlog refinement.

It should also be pointed out that the level of detail of Product Backlog items will depend on their priority. Those items that will be worked on in the next Sprint or two will be described in great detail, while those down the line will not, adhering to the just-in-time Agile principle.

While the entire Scrum Team can and should be involved in maintaining and refining the Product Backlog, it remains the sole responsibility of the Product Owner who ensures it is ordered, available and transparent to everyone involved, including any external stakeholders.

ORGANIZE YOUR PRODUCT BACKLOG IN VIVIFYSCRUM

Sprint Backlog

The Sprint Backlog is a set of all Product Backlog items that the Development Team pulls in for the upcoming Sprint, plus a plan for completing the items, realizing the agreed-upon Sprint Goal and thus delivering a “Done” Increment.

Sprint Planning - Creating the Sprint Backlog

The Sprint Backlog is created at the Sprint Planning meeting, following (more or less closely) a number of steps:

  • The Product Owner suggests the objectives for the upcoming Sprint, together with the Product Backlog items whose completion would help achieve the objectives
  • The Development Team forecasts how much they can do within the Sprint
  • The Scrum Team defines the Sprint Goal
  • The Development Team pulls in the Product Backlog items they believe will help them meet the Sprint Goal (taking into consideration the Product Owner’s input)
  • The Development Team creates the plan for working on the Product Backlog items

Man putting Sprint Backlog on whiteboard

Changing the Sprint Backlog

The Sprint Backlog evolves as the Sprint goes on and new information is learned and the team learns about what will have to be done to meet the Sprint Goal. This may include adding new work or removing that which has been discovered as unnecessary. It is absolutely crucial to point out that only the Development Team can make changes to the Sprint Backlog.

Tracking Sprint Progress

Besides ensuring that the work of the Development Team is transparent and that the team shares the same understanding of the work, the Sprint Backlog is also useful for tracking the progress of the Sprint and projecting whether the Sprint Goal will be achieved by the end of the Sprint.

The most popular way to do this is by using the Burndown chart which compares the planned completion of work and the actual completion as achieved by the Development Team.

A relatively recent addition to the Scrum Guide also recommends that the team chooses at least one process improvement agreed-upon at the last Retrospective and adds it to the Sprint Backlog.

Increment

The Increment is the third Scrum artifact and it represents the sum of all Product Backlog items “Done” during the Sprint and the value that was added to the product with previous increments.

Since this definition still causes some confusion, even within the Scrum community, we should probably clarify it somewhat.

Adding Value to Previous Increments

In short, this definition clarifies that the work done within the last Sprint should always add to the value delivered by the previous increments. In other words, you would not deliver a functionality that does not work (or add value) before another functionality that should have been developed earlier, or a functionality that does not pass regression testing and breaks the existing application.

The Increment must be “Done” by the end of the Sprint and in useable condition, even if the Product Owner does not decide to actually release.

Definition of Done

We have already used the identified “Done” a number of times in the article, in reference to “Done” Product Backlog items and “Done” Increments.

In Scrum parlance, “Done” does not simply mean that something is completed. It means that it meets the Scrum Team’s Definition of Done.

A team’s Definition of Done is a formal definition of what it means to truly complete a Product Backlog item and an Increment. The Scrum Team defines it on its own and it is essential that everyone understands it.

Going over checklist

If the organization has defined conventions, standards or guidelines concerning the Definition of Done, the Scrum Team should consider these as a minimum requirement.

In most cases, the Definition of Done will be expanded as the team becomes better, all for the purposes of delivering an even higher-quality product.

GET STUFF DONE WITH VIVIFYSCRUM

Commitment to Transparency

Complete transparency is a must in order for Scrum artifacts to fulfill their role - to guide the decisions which optimize value and minimize risks to the team, the process and the product. In other words, if the Scrum artifacts are not absolutely transparent, the decisions made based on their state can be wrong and lead to all kinds of problems.

Transparency as Scrum Master’s Responsibility

The Scrum Master is the one who ensures that everyone involved (Product Owner, Development Team, other stakeholders) is aware of how transparent the Scrum artifacts are.

In fact, one of the most important responsibilities of a Scrum Master is to identify artifacts that are not 100% transparent by inspecting them, listening to the parties involved, noticing patterns and noticing any discrepancies between the expected and achieved results.

It is also important that the Scrum Master guides the others and leads the change that will ultimately result in full transparency of Scrum artifacts.

This is a journey that can take a while, but it is a necessary one if Scrum is to work.

Closing Word

Scrum artifacts are an inseparable part of the Scrum framework and they require collaborative work from all the members of the Scrum Team if they are to contribute to the process.

Stick with us as we will be diving into details about the different Scrum artifacts over the next couple of weeks.

 

Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.