Not Done? Not Scrum!

Summary (TL;DR;)

• If you can't create Done Increments every Sprint, this is your #1 issue to fix!
• Done means more than what is written in the Scrum Guide
• Without Done Increments, you won't get any benefits from Scrum
• You need Done Increments to capture product value
• You need Done Increments to manage the 4 key risks of product development
• A Definition of Done first and foremost describes quality, not just work
• A well-structured DoD creates transparency, commitment and quality
• There's a way to fix this problem and create a great Definition of Done
 

Introduction

"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems."¹ Scrum Teams generate value by creating and delivering Done Increments.

Now, the inconvenient truth is that most Scrum Teams do not create Done Increments regularly, meaning one or more Increments every Sprint. Based on our experience as Professional Scrum Trainer (PST), Scrum Masters and Product Owners, we can say that about 9 of 10 Scrum Teams don't create Done Increments regularly. This is a serious issue!

9 out of 10 Scrum Team don't create Done Increments regularly!

Why? If your Scrum Team has this problem, you will not get any benefit from using Scrum. For example, you will not be able to maximize product value and manage the 4 key risks of product development. In fact, if you have this problem, it is the first thing you need to fix!!

In this article, we will explain why not creating Done Increments regularly is a serious issue and how you can solve it.

Let's get started.

What Done really means

In Scrum, everything happens within Sprints, the "heartbeat of Scrum"¹. In every Sprint, a Scrum Team aims to create a new stable version of their product, called the Increment.

An Increment is the latest stable version of a product.

An Increment must meet the "quality measures required by the product", and "in order to provide value, the Increment must be usable". A Scrum Team makes a formal description of this state of the increment transparent in their Definition of Done.¹

This is straight from the Scrum Guide, but it is NOT what Done means!
There is one more thing to add!

An Increment can only begin to create value when it is delivered to its users. When the Product Owner decides that it's the right time to deliver the Increment, it is important that it can be delivered without further effort. An example of further effort would be handing over the Increment to another department to add their work or approve the Increment.

The Increment can be delivered to users without further effort.

Further effort to deliver the Increment would increase time-to-market and might result in a lost opportunity to capture value – and it would mean undone work!

That is why Done really means:

1. An Increment meets the quality measures required by the product.
2. In order to provide value, an Increment must be usable.
3. An Increment can be delivered to users without further effort.

Done really means usable by the user and deliverable to the user without further effort.

This understanding of what Done really means is essential if you want to create a powerful competitive advantage by using Scrum to optimize value and manage the 4 key risks associated with product development.

The 4 key risks of Product Development

Product development, like many other development efforts, takes place in the complex domain. Complex means that to a large degree outcomes remain uncertain until we see them materialize. Here are some examples of uncertainties in product development:

• We can't say for sure whether we can build the product. We might learn through our work that we can't work as a team or don't have the skills or technology required.
• We don't know in advance whether users will find our product useful. They might tell us in advance what they need, but experience shows that only when users can really use a product, they learn whether it does what they really need.
• We won't know whether users will "pay" for the product until they do – which they will usually do only when they have proof that the product is indeed useful to them.
• We cannot accurately determine the impact (footprint) of the product on our environment (society and planet). Only through the development, operation and actual use of the product will we gain more insights and certainty about it.

Can we build the product? Will users like it? Will users pay for it? Will it be sustainable?

That is where Scrum can be a big advantage!

Scrum enables teams to learn more about and adapt to these uncertainties early and frequently. By developing Increments in each Sprint and delivering the Increment (reminder: the latest stable version of the product) to users early and frequently, Scrum creates short and frequent feedback loops. These short and frequent learning loops help a Scrum Team manage the 4 key risks of product development:

1. Feasibility risk: The risk of not being the right team or not having the skills, capacity, time, environment or technologies required to build the product.
   
   How we can manage the feasibility risk with Scrum: Creating Increments in each Sprint is a fast way of learning whether we have the skill and technology to build something usable. Each Increment is an undeniable proof of a working (part of our) product.
    

2. Desirability risk: The risk of building a product that users don't want.
   
   How we can manage the desirability risk with Scrum: Delivering Increments to users early and frequently is a fast way of learning whether we have built something useful that users really want. Everything we do before learning from the behaviour of our users is just based on the assumption that we will create something actually useful. This assumption is so commonplace that it even has a name: Humphrey's law. It asserts that requirements of a product will not be completely known until after users have used it. To avoid working on an ill-defined problem and instead create a useful product, the Increment must first be usable by users and and secondly delivered to users.
    

3. Viability risk: The risk of building a product that has no value to its producer – us.
   
   How we can manage the viability risk with Scrum: Delivering Increments to users early and frequently is a fast way of learning whether users are willing to pay for the product or service. Only when they pay for the product (with money, their data, etc.), do we have the undeniable proof that we are creating value for us. In order to learn whether users are paying for our product or service, the Increment must first be usable by users and secondly delivered to users.
    

4. Sustainability risk: The risk of developing and operating a product that will not contribute positively to our environment.
   
   How to manage the sustainability risk with Scrum: By creating an Increment early and frequently, we can inspect our assumptions about the resources required to develop and operate the product and, if needed, adapt the product to improve its footprint. By delivering the Increment to users, we can learn how the product is actually used and what footprint it actually leaves. In order to manage the sustainability risk empirically, we need to create an Increment and deliver it to users frequently.
    

That said, delivering usable Increments every Sprint is the single most important requirement for controlling the 4 key risks of product development. In fact, if we were to reduce the purpose of Scrum to a single statement, it would be

Create and deliver Done Increments regularly!

The essence of Scrum: Create and deliver Done Increments regularly!

Controlling these 4 key-risks creates a competitive advantage over companies whose feedback loops are longer and who therefore take longer to learn if they can create a usable, useful and valuable product.

A Definition of Done helps you make that happen.

The Definition of Done

"The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product." – The Scrum Guide¹

In simpler terms, a Definition of Done describes the quality of the usable Increment.

When we join a Scrum Team, we more often than not get to see a Definition of Done (DoD) that doesn't describe quality, but the work that the team performs. It's not wrong to also describe the work in the DoD, but this does really not make the quality of the product transparent, especially not for stakeholders who are not the product development experts. Therefore, a Definition of Done first and foremost describes the quality of the product.

Let's use an example to make the difference between work and quality a little clearer: Picture a guest in a restaurant. She orders a grilled chicken burger with lettuce and mayonnaise on a homemade bun. Naturally, she expects the meat to be fresh and cooked through, the lettuce to be crisp and clean, the mayonnaise to be fresh and free of germs, and the bun to be baked crisp.

That's the quality she expects.

The Definition of Done describes the quality of the usable Increment.

She doesn't need to understand or even know how the kitchen crew works to produce that quality. But for the kitchen crew it can be helpful to have a checklist to ensure their quality standards.

Here's an excerpt from a Definition of Done for that chicken burger:

 
As you can see, a good Definition of Done describes the quality of the product AND the work the team does to ensure that quality.

A good and structured Definition of Done

You could use some of the following quality categories, if applicable, to structure your Definition of Done and make the quality of your product even more transparent:

 
As you can see from this list, most of these categories describe non-functional properties of a product. The Definition of Done is a good place to describe non-functional properties that apply to the entire product (and each of its Increments) and not just to individual functional properties managed in the Product Backlog.

Making the quality of the product transparent is the minimum requirement for a Definition of Done. A good structure helps. Making the work transparent that produces that quality can also be helpful, especially for the team. Both quality and work are inputs to a good Definition of Done.

From a good to a very good Definition of Done

Here's our suggestion on how to turn a good Definition of Done into a great Definition of Done:

Make the "Done Deficit" transparent!

We know that many Scrum teams struggle to create the quality that their product needs right from the start. If that's the case, it's important to be transparent about the quality that the product does NOT currently have, even though it should have it. We call this the "Done Deficit". This will help your Scrum Team and your stakeholders collaborate to remove these deficits and create the quality the product really needs so that it's usable by users and can be delivered to users without further effort.

But make no mistake: Making the Done Deficit transparent is not an excuse for not creating Done Increments regularly – it is just a station along the way to Done Increments! You need to remove the Done Deficit to create value and manage the key risks!

Making the Done Deficit transparent is just a station along the way to Done Increments!

Here's how this would look like:

Done means:

 
 
Done Deficit – Our Increment should have this quality, but we can't deliver it yet:

 
 
And that's how a great and well-structured Definition of Done looks like.

What if you don't have a Definition of Done

If your Scrum Team doesn't have a formal description of what Done means (Definition of Done), you might experience these problems:

• You find it hard to refine Product Backlog Items so they are ready for a Sprint.
• You struggle to forecast Product Backlog Items in Sprint Planning that aren't ready.
• Without confidence in your forecast, you're uncomfortable commiting to the Sprint Goal.
• You won't know how much work is required to complete a Product Backlog item.
• The quality of the product is unclear if you don't know how much work to complete.
• If quality is unclear, you and stakeholders won't know what you inspect in Sprint Review.
• You can't assess progress towards the Product Goal if results of Sprints aren't clear.
• Your projections of future delivery dates based on past data have no empirical basis.
• The Scrum Team can't improve its effectiveness in creating the right product quality.
• Your stakeholders might lose their trust in the Scrum Team.
• Your Scrum Team may lose confidence with themselves and with each other.
• You and your users might not get a lot of value from the product.

In essence, you won't be able to optimize value and manage uncertainties, like the 4 key risks of product development mentioned before – not Done, not Scrum!

So, if you'd like to create a Definition of Done, you won't have to start from scratch. We have a Definition of Done template for you.

Definition of Done Template

Use this template to create a great and well-structured Definition of Done for your product:

Need help getting to Done?

In one of our next blog posts, we’ll show you a workshop to help a Scrum Team and even multiple Scrum Teams working on the same product to create their Definition of Done.

In the meantime, if you need help creating Done Increments regularly through a great Definition of Done, let's talk.

References:

1. scrumguides.org (accessed: 11-Feb-2022)