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
Sprint Planning - Creating the Sprint Backlog
Adding Value to Previous Increments
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.
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
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.
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.
