The complete guide to scrum artifacts

Artifacts in scrum are important, as they are a core part of the framework. Scrum professionals use them to focus on the outcome and the value of their product, while beginners often struggle with their purpose and focus on the output, potentially leading to big problems for the team.

In fact, looking at the team and how they deal with these artifacts provides deep insights into their journey of adopting agile principles.

This article will help you understand the scrum artifacts — the product backlog, sprint backlog, and product increments. We’ll also discuss common misconceptions of each of them.

Table of contents:

A brief overview of key principles in scrum

Scrum is a framework for agile software development. It helps teams practice agile principles and values by constantly delivering high-value product increments.

Based on agile empirics and iterative incremental development, scrum is helping teams and organizations optimize their way of working — liberating powers to make improvements and deliver products in complex environments.

In its essence, the scrum framework consists of:

• Three core roles
  • Scrum master
  • Product owner
  • Developers (the development team)
• Five scrum events
  • The sprint
  • Sprint planning
  • Daily scrum
  • Sprint review
  • Sprint retrospective
• Three artifacts
  • Product backlog
  • Sprint backlog
  • Product increments

The three roles combined are called the scrum team.

The framework is based on three empirical pillars:

• Transparency
• Inspection
• Adaption

To implement the scrum framework properly, everyone on the scrum team must commit to the five scrum values:

• Commitment
• Focus
• Openness
• Respect
• Courage

Introduction to scrum artifacts

The scrum framework defines three artifacts that represent the work of the scrum team or the value the scrum team creates. These artifacts maximize transparency and are available to everyone in the organization.

Each artifact also contains a commitment that enhances transparency, makes expectations clear to everyone, and helps with the inspection and adoption of the artifact. In other words, the commitment helps the team and stakeholders live the scrum values and support agile empirics.

We’ll go into detail about each of the three artifacts below:

1. Product backlog

The product owner owns the product backlog. It’s used as a single source of truth for the scrum team and all stakeholders to identify what needs to be built and why. It is a prioritized list of all the product backlog items.

A product backlog item can have different characteristics and serve different purposes. For example, it can describe a feature or represent a bug. Depending on the team, a product backlog item can also be a spike ticket or epic.

The scrum guide defines a product backlog item only as a definition of “what the product needs as an improvement,” leaving the term deliberately vague and up to the reader’s interpretation.

The product backlog is not static, but adaptable. It is continuously improved, refined, and reprioritized by the whole scrum team. The product owner makes sure that the items in the backlog are valuable, feasible, and usable through close collaboration with stakeholders and the development team.

It is best practice to refine the items in the backlog with the team in refinement sessions. These sessions can happen in separate meetings or sprint planning. In sprint planning, the team decides together on a sprint goal and pulls the highest backlog items (according to the sprint goal in the sprint backlog).

Commitment: Product goal

With the product goal, the product owner describes the future state of the product. This description is used to communicate the goal to the scrum team and stakeholders. It may be adapted when more is learned but delivers stability and direction for development.

Common misconceptions about the product backlog

When introducing scrum to new teams and companies, I’ve encountered lots of different misconceptions about the product backlog. Here are the most common ones with explanations of why they’re not true:

It’s only maintained by the product owner

The product owner is the owner of the product and thus the owner of the product backlog. But, the product backlog is maintained and updated by the whole team. In refinement meetings, the whole scrum team enhances the information in the backlog and also reprioritizes the items.

It’s is a fixed list

A static, fixed list would not be agile, since that would mean that we have to plan everything from the beginning. That’s a plan-driven approach and the opposite of agile and scrum. In fact, the backlog is a flexible, adaptable, living artifact that may (and should) adapt as the team learns more.

It’s only for features

The backlog consists of many different items like feature tickets, bugs, spikes, and epics. The scrum guide doesn’t define exactly what a backlog item is, so it is up to the team to find their own definition.

It has to specify the exact requirements

A team can decide how detailed and specific a product backlog item has to be. Some teams may decide to use a definition of ready; others may be happy with loosely documented items. In sum, the backlog is more of a prioritized list of goals and work.

It’s only used in sprint planning

The backlog provides transparency and insight for stakeholders and the team. It is maintained frequently and used for inspection and adaptation during the sprint. It gives everyone an idea of how the scrum team works towards the product goal.

2. Sprint backlog

The sprint backlog is a combination of the sprint goal, the set of backlog items the team selects to reach that goal, and the actionable plan to reach that sprint goal. It is created in sprint planning by the whole scrum team but owned by the development team.

In the planning meeting, the entire scrum team — the product owner, scrum master, and development team — will decide which sprint goal they want to pursue next. They define the “why” of the sprint.

In line with this sprint goal, they inspect the product backlog and select and plan the most suitable items for the sprint  —  the “what.” With the help of their experience from previous sprints, the team can also create a concrete implementation plan and, thus, also define the “how.” Teams often use the average velocity of the last sprints to make a forecast of what and how much they can achieve in this sprint.

Once the sprint backlog has been created, the team starts to work and executes the plan. The team commits to the sprint goal and to delivering the agreed value at the end of the sprint. The sprint backlog is thereby updated and refined regularly during the sprint.

With burndown or burnup charts, the team can monitor their performance and figure out if they are still on track (or if they need to modify their plan).

The sprint backlog is open for everyone and provides a clean and transparent view of the work of the development team. This creates trust in the development team and increases transparency.

Commitment: Sprint goal

The commitment of the sprint backlog is the sprint goal. With the sprint goal, the team commits to delivering a certain business value at the end of the sprint. The goal provides guidance and flexibility for the team during the sprint and can be seen as a sub-goal on the way to fulfilling the product goal. It acts as a guiding star for the development team and is the team’s single objective during the sprint.

The scrum guide does not define a concrete form of what a sprint goal should look like. However, there are some best practices to formulate a sprint goal. A well-known form is defined by Steve Trapps as:

Our focus is on <outcome>

We believe it delivers <impact> to <customer>

This will be confirmed when <event happens>

This template will help you create a measurable sprint goal that focuses on the outcome for users.

Common misconceptions about the sprint backlog

As with the product backlog, there are many misconceptions about the sprint backlog. Here are the most common misconceptions I have come across in the last few years.

It has to be a detailed plan

The sprint backlog is a dynamic plan that can change during the implementation of the sprint. If the changes are too big and would alter the sprint goal, however, the team has to renegotiate the sprint backlog and sprint goal with the product owner.

It’s a backlog and thereby owned by the product owner

In sprint planning, the whole scrum team crafts the sprint goal. The product owner provides valuable insights and enables planning through the product backlog. But, the development team owns the sprint backlog. They are responsible for making their work transparent to the stakeholders and the rest of the scrum team.

It’s set in stone after planning

During the implementation, the development team learns and may adapt the sprint backlog.

The sprint backlog is only available for the scrum team

Everyone should be able to understand the current state of development. That is why every stakeholder should be able to inspect the sprint backlog.

It’s a list of tasks

The sprint backlog is a composition of a list of tasks, the sprint goal, and a plan to reach the sprint goal. It should make the value of sprint transparent to everyone.

3. Product increments

A product increment is a concrete stepping stone toward the product vision and the product goal. Each increment extends the previous increment with the added value of the sprint. The goal of each sprint is to extend the product and create additional value for the user.

At the end of the sprint, this added value must be available and usable for the user. In the sprint review, the team usually presents the improvements and increments to stakeholders and collects feedback.

To ensure a certain level of quality and standardize the done state of an increment, the scrum team uses a definition of done. This is why the definition of done is the commitment of an increment. With this definition of done, it should be easy for everyone to identify if work is truly finished and can be added as part of an increment or not.

Commitment: Definition of done

The definition of done is the product increment’s commitment. It’s a contract between the development team and the rest of the organization. It formally defines the state of the increment to meet the required quality of the organization.

If it meets the requirements of the definition of done, the product backlog item can be considered done and a new increment is created. The team can tailor the definition of done to their needs but the requirements of the definition of done can never be lower than the definition of done expected by the organization.

Common misconceptions about product increments

There are several common misconceptions. Here are my top five:

It must be releasable at the end of the sprint

The scrum guide doesn’t define that an increment must be releasable at the end of the sprint. However, it might be a part of the organization’s definition of done that the increment must be releasable.

It must be completed at the end of the sprint

The sprint must have added business value and the increment must have added value. However, in the agile world, the product is constantly evolving and a bigger feature must not be completed within one sprint.

The definition of done is a static set of rules

The definition of done can adjust to the needs of the product and the team, but can never be less strict than the definition of done of the organization.

It can be rejected in the sprint review

The sprint review is not a gate for the stakeholders to control the release of an increment.

Work can be added to the increment even if it doesn’t meet the definition of done

The scrum guide is very clear and strict about this. If work doesn’t meet the definition of done, it cannot be included in the increment and cannot be presented in the sprint review. Instead, the product backlog item goes back into the product backlog at the end of the sprint.

Final thoughts: Focus on the outcome, not the output

More experienced scrum teams have learned that the artifacts should focus the team on the outcome. However, this is not always obvious.

In the Scrum Guide, the word outcome appears only once. “The purpose of the sprint review is to inspect the outcome of the sprint and determine future adaptations.”

Output represents the results of the work that a team has produced in the sprint. But these deliverables say nothing about the effectiveness and benefits generated by that work. The task of the scrum team is to generate added value in the sprint. Therefore, the team must also focus on the outcome, i.e., on effectiveness. The question is therefore, “Does the increment generated have an additional positive effect on the user?”

A simple example is a pastry chef. Should the pastry chef focus on the shape and color of the cake or on the fact that the cake tastes good? Are you, as a customer, satisfied if the cake looks great but is way too salty?

To achieve the outcome for the sprint, the added value must be documented and addressed in all artifacts:

• The product backlog should document the value for the users
• The sprint backlog and sprint goal should describe which benefit the team should generate and explain how the team plans to create this added value
• The increment should be evaluated by stakeholders and the scrum team based on its added value and benefits

It should not matter whether the team has baked two or three cakes, but whether the cakes taste good and fulfill their purpose. A “get well soon” cake at grandma’s birthday party is more likely to have negative effects than to add value to the party.

Use templates like the sprint goal template or the user story template to document added value.

“As a [persona], I [want to], [so that].” This will help your team focus on the outcome and understand the purpose of their work and the product.

Featured image source: IconScout

The post The complete guide to scrum artifacts appeared first on LogRocket Blog.

from LogRocket Blog https://ift.tt/Qe4DbSc
Gain $200 in a week
via Read more