Increments and Done

Intermediate

difficulty

Stage 2

Agile IQ® Level

Quality

Practices

Scrum

Framework

Introduction

In the Scrum.org™ Headquarters there is a picture of Ken Schwaber — one of the founders of Scrum — pointing at a sticky note that says “Done”. This picture underscores the most essential rule in Scrum: create an Increment of Done every Sprint.

But many teams struggle with this rule. It is tempting to fall into “shades of Done”:

An increment is considered Done by the team, yet it requires further testing and stabilisation in the next Sprint.
Work is considered Done, but the install package still needs to be created.
Work is considered Done, but security, audit and compliance standards have yet to be tested.

Done doesn’t support adjectives like “nearly”, “pretty much” or “almost”. An increment is Done or it isn’t — there is no gray area. And there is a very powerful, compelling reason behind this: the Scrum Framework only helps to reduce the risk of wasting money and effort when you deliver “Done” software every Sprint. A new version of your product that is, or with the proverbial press of a button can be, released to users.

If you are unable to deliver a “Done” increment during a Sprint, you are not doing Scrum.

Ken Schwaber

Defining "Done"

What constitutes Done depends greatly on context. Building a website for an external customer will require different work then when you’re working with different Scrum Teams on mission-critical software for internal users. It depends on the quality guidelines that already exist within your organisation, how critical the software is to the business, the level of involvement of users, the technologies in use and many other factors.

Suppose that you are building a new feature for your product as part of the current Sprint. Building this feature requires a workflow of all sorts of tasks, from writing code to creating unit tests, from creating a design to testing it on mobile devices and from testing it with users to integrating it with work done by other teams. And ultimately deploying it to your users. Necessarily, this requires all sorts of skills in Developers, and it requires an effective workflow to do all this within a single Sprint.

It may be tempting to limit “Done” to what a team can actually do

Many teams starting out with Scrum are unable to do this because of technical and organizational impediments. It may be tempting to limit the definition of “Done” to what a team can actually achieve in a Sprint. Thus, they may end up defining “Done” as no more than:

The code has been peer reviewed by another developer in the team.
Unit tests have been written and are passing for the item.
The code is merged and has been checked into the develop-branch.

More specifically, the team will move items to “Done” on their Scrum Board when it meets these criteria.

“Done” and Undone Work

This team may think they are delivering a “Done”-increment every Sprint. After all, they can tick all the boxes in their definition of “Done”. But are they really? But with a Definition of Done that is mostly focused on working code, the resulting software will be hard to review by the Product Owner. Any feedback on this intermediate result will be incomplete at best. A number of things may happen in the next Sprints, after the team considers work Done, when other steps in the workflow are completed. Some examples are:

When reviewing the feature, the Product Owner determines that an essential element promised to stakeholders is missing, requiring changes during the next Sprint.
While testing the feature, a user discovers a breaking bug that needs to be fixed during the next Sprint.
Integration of the code with work done by another team for the same product fails, requiring the team to resolve complicated merge conflicts during the next Sprint.
The feature doesn’t scale correctly on some mobile devices, requiring the team to fix the feature in the next Sprint.
When trying to deploy the feature to production, the install fails. After investigation during the next Sprint, the team discovers that the issue is caused by a missing dependency.
A security scan uncovers that the feature is susceptible to SQL Injection, requiring the team to fix this during the next Sprint.
After deploying the feature, it is discovered that latency on the network is too high to make the features work well for users.
Because of missing support documentation, the team receives several support calls about the feature that are easy to answer, but nonetheless take time away from the current Sprint.
The feature isn’t turns out to be unusable by people with poor eyesight — an important group of users — requiring tweaks in the current Sprint.

Fundamentally, this work is not discovered during the current Sprint, but during future Sprints. This makes them examples of undone work: work that is required to truly complete an item on the Product Backlog and is not covered by the Definition of Done.

Undone work has four consequences:

It draws time and energy from the team away from the focus and work in future Sprints. The bigger the gap between what a team defines as “Done” and what is actually needed— the more disruptions and interruptions will happen in future Sprints due to undone work. It will become progressively harder for the Scrum Team to make any kind of meaningful forecasts about work in future Sprints.
Because undone work is not discovered during the current Sprint, it is unclear and unpredictable how much of it will occur. This decreases thetransparency of the Increment and the features being developed. More specifically, it will be harder to answer questions from stakeholders about whether or not a feature is Done.
Scrum Teams fool themselves into believing that they are successful by “staying busy”. They pull a lot of work into their Sprint Backlogs, their velocity may be excellent, everyone is working very hard all the time. But at the end of a Sprint, there is no potentially releasable Increment.
The risk of software development remains high as both the state of the Increment and its features, but also the amount of undone work remaining, is not transparent. We still can’t validate assumptions about features or the product as a whole because it isn’t really Done.

Taken together, this will erode trust in the Scrum Team over time as stakeholders and management lose confidence in what the team — and Scrum — can deliver.

The bigger the gap between what a team defines as “Done” and what is actually needed — the more disruptions and interruptions will happen in future Sprints due to undone work.

Christiaan Verwijs, Scrum.org™ Professional Scrum Trainer

Definition of Done as a “risk detector”

A complete Definition of Done is your most powerful risk detector for complex work. It helps you reduce the risk of undone work by making transparent all that is needed to create Done Increments every Sprint. It will also make very transparent all the impediments that are getting in the way of achieving this outcome.

Actions

Encourage team ownership of the Sprint Goal

Maintain a ruthless focus on “Done” software. If you can’t deliver a potentially releasable increment in a Sprint, don’t fill the Sprint Backlog with work to give the impression that you’re creating value. Instead, populate the Sprint Backlog with whatever is needed to create potentially releasable increments. This may involve setting up infrastructure, learning skills or technologies and removing organisational impediments.
Make the gap between what you can do and what is needed for Done to be transparent. Don’t go the easy way and limit your definition of Done to what you can realistically do. Instead, identify what you should be doing to achieve a Done increment and offset it with what you are currently capable of doing. List all the things getting in the way as impediments that need to be resolved, and keep reminding everyone involved — in particular management — that you will only really start reducing risks when the gap decreases.
Make it smaller & simpler. The simplest truth in Scrum, and everything Agile, is to make it smaller and simpler. This is why refinement is such an important activity in the Scrum Framework. If its impossible to go through all the required steps for a piece of software, make it smaller and focus on getting those smaller bits through the entire pipeline in one Sprint.
It’s not about Scrum, but about reducing risk and maximising value and making impediments transparent. It might be tempting to throw your hands in the air and consider what Scrum asks of you impossible. But in the world of complex work — which software development is—an empirical process (like Scrum) is the best tool we have to reduce risks and to maximise the value we can deliver to stakeholders. Furthermore, it is the best way to make everything holding you back — like team composition, organisational procedures and bottlenecks — transparent and (therefore) resolvable. And yes, this transparency should hurt.

References

Verwijs, C (2018) Why Scrum requires completely Done software every Sprint. Online at: https://www.scrum.org/resources/blog/why-scrum-requires-completely-done-software-every-sprint

All fields are required.