The Liberators
Published in

The Liberators

Why Scrum requires completely “Done” software every Sprint

And anything less means you’ve got work to do

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

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 organization, how critical the software is to the business, the level of involvement of users, the technologies in use and many other factors.

It may be tempting to limit “Done” to what a Development Team can actually do
  • Unit tests have been written and are passing for the item;
  • The code is merged and has been checked into the develop-branch;

“Done” and Undone Work

This Development 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:

  • 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 Development Team to resolve complicated merge conflicts during the next Sprint;
  • The feature doesn’t scale correctly on some mobile devices, requiring the Development 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 Development 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 Development 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 Development 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.
  1. Because undone work is not discovered during the current Sprint, it is unclear and unpredictable how much of it will occur. This decreases the transparency 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”;
  2. 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 product increment;
  3. 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”.

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.

Three examples to illustrate the point

  • I recently witnessed a Scrum Team that had spent months customizing software for complicated machinery. They involved users from the very start and worked hard to release “Done” software every Sprint. For practical reasons, they decided not to roll out to the actual machinery, effectively keeping the software running in a pre-production environment. When they did roll out, they discovered that hardware issues caused so many issues in the software that users reverted to the old software. After months of work, the team was confronted with the possibility that the project had to be cancelled altogether — effectively negating the investments up to that point;
  • I once participated in a Scrum Team that was building a product that was supposed to change the market we were operating in at the time. The Product Owner was wholly convinced of this and continued to pour money into its development, spurred on by positive feedback from the internal organization. But the product was never exposed to actual users throughout the first year of development. When it was finally deployed, the expected demand for the product didn’t pan out, effectively wasting the investment;
  • We recently spend a week with a Development Team to build the website for The Liberators. Although very small by comparison, we noticed how both the Product Owner and stakeholders could only provide useful feedback to Product Backlog Items that were really “Done”. It was hard to give feedback to any of the earlier stages — from wire-frames to designs, and from looking over the shoulder of a developer creating pages to acceptance versions with placeholder texts and images;

A complete definition of “Done” is your most powerful risk detector for complex work

Definition of Done as a “risk detector”

In Scrum, 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 goal.

Of course risk never entirely drops to zero. It remains complex, unpredictable work. One could easily add another column called “Value Validated” and increase the distance between ‘Releasable’ and ‘Released’. But we didn’t want to over-complicate this picture for the sake of this post.

Now what?

Obviously, creating “Done” increments every Sprint is a tall order for any Scrum Team. But there are things that help:

  • Make the gap between what you can do and what is needed for “Done” 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;
Participants running the “Done” Exercise from the PSMII Class by, designed to make the gap transparent and trigger a conversation about the consequences of undone work
  • It’s not about Scrum, but about reducing risk and maximizing 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 maximize the value we can deliver to stakeholders. Furthermore, it is the best way to make everything holding you back — like team composition, organizational procedures and bottlenecks — transparent and (therefore) resolvable. And yes, this transparency should hurt.

A hard truth

The hard truth is that if you are unable to deliver a “Done” increment (at least) every Sprint, you aren’t there yet. You can congratulate yourself on your journey towards Scrum, but don’t fool yourself by calling it Scrum. Because your ability to detect risks is still very limited, you will see very little benefits of the empirical process that the Scrum Framework is all about. But the good news is that keeping a ruthless focus on creating “Done” software every Sprint will make everything getting in the way of this highly visible.

You can already support us with $1/month. Find out more on



The Liberators: Unleash The Superpowers Of Your Team

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.