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”:
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
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:
More specifically, the team will move items to “Done” on their Scrum Board when it meets these criteria.
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:
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:
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
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.
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.