What Are You Defining as 'Done'?

The actual agility an organization achieves is rooted in how sophisticatedly Scrum is being employed. Beyond the mere adoption of Scrum, enterprise agility is much accelerated if the organization re-emerges its structures around Scrum. With re-vers-ify I remind people that structures need to be re-imagined, rather than predicted or copied, often upon re-imagining Scrum.

Through Scrum, teams and organizations create, deliver, maintain, and evolve great products and services. Through Scrum, teams and organizations create the opportunity of potentially releasing a version of product no later than by the end of each Sprint, where a Sprint takes no more than 4 weeks, and often less. This provides an organization with foundational agility and the potential to thrive in its market while creating a motivating working environment.

The state of an Increment of a product by the end of a Sprint is named “Done” in Scrum.

In order for everyone to understand what “Done” means, teams have a definition of Done in place. The definition of Done holds the shared understanding of what it means for work to be complete and ensures transparency over the completeness of the work.

At several points in time this provides crucial clarity:

• When forecasting work is deemed feasible for a Sprint.
• When assessing whether work on Product Backlog items and the product Increment is complete.
• The progress of development throughout a Sprint.
• When considering the opportunistic value of the product functionality offered in the Increment (not having to turn the inspection into a quality interrogation).

Without a Definition of Done, Scrum Cannot Be Applied Effectively

Ideally, a professional organization defines quality requirements to be incorporated into a product. Regardless, Scrum professionals adhere to an appropriate definition of Done. Always. No unfinished work is part of the Increment. No unfinished work is put into production. Ever. Meanwhile, committed professional teams keep looking for ways to improve product quality as reflected in the definition of Done.

Many teams across the world seem to be unable to create actual, releasable Increments of the product. The code is entered and potentially tested, within a team. But the actual Increment remains scattered and hidden in long-lived branches. Or the work delivered at the end of a Sprint still needs to be integrated with fellow product teams. Or - even worse - it is to be shipped to different departments for that purpose. In those cases, Scrum reveals important information over critical organizational impediments that prevent the teams from creating actual, releasable versions of a product. There is a substantial amount of “Undone Time,” the time it takes to go from an undone piece of work to a Done Increment. This time impedes the agility that the organization desperately needs. It kills the option of opportunistic releases.

The purpose of a Sprint in Scrum is not to just result in a piece of work that can be shipped to another team, functional group, or department. An Increment is expected to be in a useable condition, ready for production. When released, nothing breaks. No unpredictable amounts of open work accumulate in the system, waiting to be handled at some unknown point in time, meanwhile corrupting everybody’s understanding of the progress and quality. The actual release decision depends on how useful the product is, a decision that lies with the Product Owner, the sole representative of users and stakeholders to the Development Team(s).

An Increment must at least be integrated across teams and systems to have it in a production-deployable state. Most often, what teams define as “Done” are all the development activities (of which, in general, a lot are testing) that need to be performed to consider an Increment as “Releasable.”  

Imagine, however, any non-software industry. Can you imagine ‘quality’ being expressed in terms of the machines, tools, and practices used? This is not a matter of ‘how’ to create quality, but, rather, a definition of quality.

Quality Is Defined Through the Characteristics of a Product

Quality is in the qualities that a product should exhibit. A “Done” product in Scrum is not just a product on which rigorously proper development standards were applied, and therefore can be released. A “Done” product is a product that exhibits your organization’s definition of product qualities.

Valuable Increments are at the heart of Scrum, as I already indicated in my book “Scrum – A Pocket Guide” (2013).

Shifting the balance toward creating Valuable Increments is truly enacting Scrum, and living by the highest Agile principle.

• From the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• From the Scrum Guide:

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

So, do you have a definition of Done? If so, what are you defining as “Done”? Is it ‘Releasable’, or ‘Valuable’? Is every Increment you create valuable? Why not? Does your Scrum Master know? Your management? And what are you doing about it?