Product Evolution through the Artifacts of Scrum

The transparency amplified by the three Scrum artifacts helps in creating an emerging product. The artefacts are interlinked and their three commitments add further clarity. Let’s explore how.

The Scrum framework has three artifacts each providing a specific perspective of an emerging product:

• The future of the product is shown in the Product Backlog (PB);
• The Scrum Team’s current focus, the present tense of the product is captured in the Sprint Backlog (SB);
• All previous decisions, the past of the product is encapsulated in the Increment.

Let’s take a look at each and how they are interlinked, starting with the Product Backlog.

Product Backlog

When you operate in the complex world where your options are seemingly endless, you might feel overwhelmed and rightly so. Product Backlog, which is a list of possible improvements for a product, may play a big role in this because of one of its qualities: emergence. It is like a garden — organic. It grows, then is pruned, items are merged or deleted, it is alive.

As product development is a collective effort, I would like to think any stakeholder or team member should be allowed to have a bright idea of how to improve the product which they could add to PB — although creating Product Backlog Items (PBIs) is a clear accountability of the Product Owner (PO).

At the same time — to keep things in balance — it is the PO’s accountability to order PBIs and merge or delete them. A Product Owner, like a gardener, attempts to counterbalance the emergence through this activity, bringing clarity and order. When making decisions, the PO is assisted by the Product Goal — if a PBI cannot be mapped to the Product Goal, there is no reason for it to be on the PB.

As more is learned about a product and the direction it needs to take, the PB is refined as needed, which means that PBIs might be broken down to smaller, more manageable chunks of value, gaining clarity as far as their description, order and size and other, domain-specific attributes are concerned.

Whilst Scrum Master serves the PO by helping find techniques to manage the PB effectively, ultimately PO remains accountable.

Sprint Backlog

Sprint Planning, which is the first event of the Sprint, is the time when some PBIs will become part of the Sprint Backlog. Before we get there, however, two things must happen, namely:

• From a business perspective, the Scrum Team must have enough information on the most important PBIs to be able to discuss how they map to the Product Goal.
• From a technical perspective, Developers need to understand the technical constraints enough to ensure that the most important PBIs can be completed within one Sprint.

To meet the constraints above, PO needs to bring enough clarity for the PBIs in question so that the Scrum Team can refine and right-size them. Through refinement, PO’s intention is to enable and facilitate the self-management of the Scrum Team around the work to be done.

At Sprint Planning, Developers are accountable to create the Sprint Backlog using the product insight of the PO and the facilitation skills of the Scrum Master if needed. Just as PO is helped by the Product Goal to make decisions related to the PB, Developers are assisted by an emergent Sprint Goal — their commitment — to make similar decisions regarding the Sprint Backlog.

Ultimately, this artifact is the combination of three things:

1. The Sprint Goal, the commitment of the Sprint Backlog — highlighting why the sprint is valuable.
2. The Product Backlog items selected for the Sprint — highlighting what Developers think needs to be delivered to meet the Sprint Goal based on what they know.
3. Thirdly, a plan — highlighting how Developers think they will deliver the selected PBIs.

With the exception of two constraints, all aspects of the Sprint Backlog — a plan by the Developers, for the Developers — are owned by Developers: They decide how to turn PBIs into Increments of value, and they are also accountable to use the Daily Scrum to plan and update the Sprint Backlog as more is learned with the intention of stepping closer to the Sprint Goal. (And yes, it also implies changing items on the SB if they no longer map to the Sprint Goal.)

The two constraints that Developers need to respect regarding this artifact are:

• Developers may adapt the Sprint Backlog in a way that the focus of the Sprint, i.e. the Sprint Goal, remains intact.
• The Sprint Backlog will collapse if the Sprint is cancelled due to the Sprint Goal becoming obsolete. This option, which is rarely exercised, sits with the Product Owner.

Increment

As the Sprint commences, items in the Sprint Backlog are started and completed through the hard work of the Scrum Team. As an item meets the Definition of Done, which means the work has been completed to an agreed quality standard, a usable Increment, a new version of the product is born. The new Increment, which is fully integrated with all previous Increments, is a stepping stone towards the Sprint Goal.

Similarly to the relationship between the artefacts and their commitments detailed above, the Definition of Done helps Developers decide whether a PBI has become an Increment or not. As the Sprint progresses, more than one Increment may be created.

During Sprint Review, the Scrum Team and stakeholders inspect the outcome of the Sprint: the latest Increment — similarly, they inspect whether the Sprint Goal was met or not.

It is important to note that having a stable Increment of Done is arguably more important than achieving the Sprint Goal itself. Having a Done Increment means that at least a stepping stone towards the Sprint Goal was made. This creates transparency that enables inspection — this opportunity would be lost without a Done Increment.

Summary

The ultimate raison d’etre of a Scrum Team is to turn a selection of the work into an Increment of value. From the perspective of a piece of work (a PBI), the process looks as follows:

• The PBI is created and while being ordered and refined, it constantly needs to pass the test against the Product Goal.
• A refined and right-sized PBI might be selected at Sprint Planning as an item that can help the team achieve a Sprint Goal. The Sprint Goal becomes the second test for a PBI.
• As soon as the work on the PBI can be considered Done as agreed by the quality test, the Definition of Done, a new Increment is created. This is probably the most important moment in the life of the Scrum Team.
• The Increment is inspected at Sprint Review so that future adaptations can be made to the Product Backlog. These adaptation decisions can again be helped by assessing how they test against the Product Goal.
• Repeat.

Agree? Disagree? Have different thoughts? Please leave a comment.

Have you found value in this post? Please hit the clap button — and don’t forget to follow scrumtimes or me, the author, to stay in the loop. Thanks!