Why Scrum Requires Completely “Done” Software Every Sprint

In the Scrum.org Headquarters there is a picture of Ken Schwaber — one of the founders of Scrum — pointing at a sticky saying “Done”. This picture underscores the most essential rule in Scrum: create “Done” software 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 Development Team, but requires further testing and stabilization in the next Sprint. Or work is considered “Done” by the Development Team, but the install package still needs to be created. Or work is considered “Done”, but acceptance testing hasn’t been done yet.

But “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. In this post I underscore how essential this rule is to Scrum.

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.

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 the Development Team. And it requires an effective workflow to do all this within a single Sprint.

It may be tempting to limit “Done” to what a Development 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 Development 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 Development Team will move items to “Done” on their Scrum Board when it meets these criteria.

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

• 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 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.

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:

1. It draws time and energy from the Development 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;
2. 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”;
3. 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;
4. 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.

Recommended for You

Webcast, December 18th: Optimizing Customer Engagement with User Intent

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 on one of their remote sites. They involved users from the very start. They also worked hard to release “Done” software every Sprint, but decided not to roll out to the remote site, effectively keeping the software running in a pre-production environment. When they did roll out, they discovered that hardware issues at the remote site caused so many issues in the software that users revolted and 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;

Not only do these examples illustrate how limiting “Done” reduces your ability to minimize the risk of complex work, it also illustrates how releasing to users early and often is the best way to mitigate risk. It also illustrates clearly how defining “Done” should be a collaboration between Development Teams and Product Owners, integrating both technical and business considerations.

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”. 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:

• 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 organizational impediments;
• 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 Scrum.org, designed to make the gap transparent and trigger a conversation about the consequences of undone work

• 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. Less really is more with Scrum;
• 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.