Blog

Not Done? Not Scrum!

Why you won't get any benefit from Scrum if you don't create Done Increments every Sprint – and how to fix this issue!

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 3 product development key-risks
  • 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."1 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 7 of 10 Scrum Teams don't create Done Increments regularly. This is a serious issue!

7 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 3 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"1. 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.1

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 3 key-risks associated with product development.

The 3 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.
Can we build the product? Will users like it? Will users pay for it?

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 3 key-risks of product development:

  1. Feasibility risk: The risk of not being the right team or not having the skills 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 want. Everything we do before learning from the behaviour of our users is just based on the assumption that we will create something useful. This assumption is so commonplace that it even has a name: Humphrey's law. It asserts that "Users don't know what they need until they see what they don't need". In order to learn whether our product is useful, 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.

 
That said, delivering usable Increments every Sprint is the single most important requirement for controlling the three 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 3 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 Guide1

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:

This is the quality of our product This is the work we do to ensure this quality

The chicken is fresh and fully cooked, so that our guests can enjoy it without getting sick.

Get chicken from the fridge. Make sure it smells fresh. Cut it into a piece not thicker than 3 cm. Take a clean pan. Put in a spoon of fresh butter, and heat the pan to 230° C. Fry chicken piece for 3 minutes on each side. Cut the piece in half to check that it is done. If needed, fry for another minute on both sides and check again.

 
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:

Quality category This is the quality of our product This is the work we do to ensure this quality

functionality

  • description of specific quality

  • ...

description of work

usability

...

...

reliability

...

...

security

...

...

performance

...

...

compatibility

...

...

maintainability

...

...

portability

...

...

compliance

...

...

 
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:

Quality category This is the quality of our Increment This is the work we do to ensure this quality

specific category

description of specific quality

description of work

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

Quality category This is the quality our Increment should have but DOES NOT yet have This is what keeps us from committing to and delivering this quality.

specific category

description of specific quality lacking

description of reasons

 
 
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 3 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:

  • Download our template of a great and well-structured Definition of Done (DoD).

 

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.

Let's talk

Author:

References:

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