The Scrum Team, with the support of the Product Owner and the Scrum Master, provides product Increment. By using the Scrum framework, the team gains the necessary tools to prioritize and track the progress of work.
Go To:
What are Agile Scrum artifacts?
The Cambridge dictionary describes the artifact as “an object, such as a tool, that was made in the past”. Some of the definitions by Dictionary.com also defines an artifact as “a substance or structure not naturally present in the matter being observed but formed by artificial means”.
The Scrum Guide describes: “Scrum artifacts as reflecting work or value”. Using a simpler nomenclature, the Scrum artifacts show the actual work we have done in the project and what we plan to do. In the following article, I will try to explain what they are and why there are artifacts in Scrum. For a better understanding, I will use quotes from the latest version of the Scrum Guide published in 2020.
Also read: How to Sprint plan?
Artifacts and Agile: What is the difference between Agile and Scrum?
To start with, however, let’s distinguish two concepts that, despite the growing popularity of agile methods of work, are still sometimes confused. Participants of training often ask me the question – do we need all these artifacts to be agile? Let’s remember that Agile is rather a way of thinking and a general concept that defines an agile approach to software development. Scrum, on the other hand, is a framework created and constantly improved to facilitate the delivery of value in a complex world.
 |
What are the names of the 3 Scrum artifacts?
Scrum distinguishes 3 artifacts: Product Backlog, Sprint Backlog, and Increment. Although the Product Goal, Sprint Goal, and Definition of Done are directly related to artifacts by ensuring clarity and focus, they are not Scrum artifacts themselves.
What is a Product Backlog?
According to Scrum Guide, Product Backlog is “an ordered and emergent list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team”. Simply put, the Backlog uses tasks to describe all the work that needs to be done throughout a project. A Product Owner is responsible for managing the Backlog. This may include such activities as:
- creating new elements of the Backlog – tasks,
- prioritizing and organizing the elements of the Product Backlog – for a better understanding of work, at the top, there are tasks with a higher priority, and below those of low importance or requiring further detailing during the Refinement,
- ensuring accessibility and transparency – a situation in which everyone interested knows where the Backlog is and what it describes.
The Product Owner may transfer or delegate management of the Product Backlog to another person, but in the end, PO is responsible for this area. The Scrum Guide also indicates, which is extremely important, that the Product Owner is one person and not a committee or group of people. The Product Owner should take into account the requirements and expectations of stakeholders and the external environment in their work, but ultimately the Product Owner makes decisions regarding the Product Backlog. Why is it so important in everyday project work to emphasize that the Product Owner is one person? This allows you to avoid the dispersion of responsibilities and internal fights over which area of the product is more important.
Improvement or Refinement
I must also mention the improvement, that is, the Refinement. In common understanding, it is considered as a meeting during which Product Backlog is discussed, divided into smaller parts, and specified. However, by definition, it is a continuous process that is not reflected in a single, specific meeting.
The Product Backlog is inseparably linked to the Product Goal, which describes the future state of the product. According to the Scrum Guide, “The purpose of the Product is reflected in the Product Backlog”. In practice, it is a guideline and signpost for developers as they plan work and during the work itself.
What is a Sprint Backlog?
The authors of the Scrum Guide precisely stated that: “The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)”.
It is important to understand the above definition. In the common and at the same time incorrect understanding, the Sprint Backlog is defined during the Sprint planning meeting at the beginning of each Sprint as a defined scope of work, the implementation of which is undertaken by the Development Team. Meanwhile, the definition states exactly that the Sprint Backlog consists of selected elements of the Product Backlog (what), as well as the Sprint Goal (why) and the delivery plan (how).
To picture this – imagine that the Sprint Backlog is a kind of bag in which there are tasks and a plan on how to deliver them. The goal of the Sprint, in turn, is the signature on the bag itself.
Remember that the Sprint Backlog is not a “pact with the devil” signed with developers’ blood, but a living artifact that may evolve with the progress of work throughout the Sprint. Over time and with a better understanding of work and requirements, as well as due to unexpected internal and external dependencies (holidays or sick leaves), it may turn out that the Development Team will update the Sprint Backlog in such a way as to achieve the Sprint Goal. The Development Team is responsible for the preparation and implementation of the Sprint Backlog.
To sum up, the Sprint Goal set during Planning is a commitment of the developers but gives them freedom and flexibility in terms of what the team should do to achieve the unchanged Sprint Goal.
What is Increment in Scrum?
The Increment can be depicted as a Lego block, thanks to which we add another brick to the construction of our castle. Just as the Lego bricks need to match, the Increment needs to fit and be verified so that it was entirely usable, that is, to deliver value to the user or customer.
More than one Increment may be delivered per Sprint. Although Sprint Review supports the empirical approach, we cannot assume that only at the Review meeting is the Increment presented and delivered. The increment worked out during a Sprint may be greater than one and may be delivered before the Sprint is completed.
Like with Lego bricks – we can choose one big brick from the bucket, or take several small trying to build a construction using more elements.
Definition of Done and Product Increment
The Increment is inseparably linked to the Definition of Done. This is a kind of set of conditions that must be met to recognize the work done. The definition of Done is a standard that affects the quality and value of the work of developers. If any of the elements of the Sprint Backlog does not meet the Definition of Done conditions – it cannot be presented to the customer and considered as part of the Increment.
Nothing prevents developers from applying stricter conditions than those set out in the Definition of Done. This happens when the team wants to put more focus on the value delivered. The Definition of Done can be considered as a minimum criterion against which one can “level up but never down”.
The Definition of Done can be considered as a quality guarantee for stakeholders or the client, which ensures that the Increment received by them is fully operational and meets the quality criteria.
Main artifacts of Scrum framework – the summary
According to the Scrum Guide, the Scrum framework includes Scrum Teams and related roles, events, artifacts, and rules. All these elements are important, and the Scrum artifacts I have described allow for transparency, provide an opportunity for adaptation and inspection, and therefore favor the strengthening of the Scrum pillars in the project.
Scrum Master at Inetum. He believes in empiricism and iteration and teaches Scrum Teams independence and responsibility. Outside of work, Łukasz is a mountaineer and climber, as well as the operator of the Tuudi.net portal.