What is “done” about?
I’ve written before, many times, that Agile Software Development is about working software. Most recently, I wrote about the software increment and how it is part of creating a productive culture. The point, in a nutshell, is this:
The Scrum Team communicates within itself, and with its stakeholders, primarily through production of a Product Increment which is open to inspection. Observing the Increment, the stakeholders, the Product Owner, and the Development Team have a common understanding of how things are going. They use this as the basis from which to improve.
Compare these two summary status reports which we might get from two different teams:
We have added five more of the Product Owner’s top priority backlog items. These new items, and all previous items, are passing all tests. The current system is integrated, and can be viewed at http://somewhere.com/version.3.1 at your convenience.
We have the new database records 95% defined and will begin integrating them into the application over the next few weeks. The proposed UI has been prototyped and can be viewed at http://somewhere.com/proposedUI.3.1 at your convenience.
Which of these teams gives us more valuable information about product status? Which one seems more likely to be ready by the shipment date? What would your questions look like for each of these teams?
If you’re like me, you’d feel pretty confident in Team 1, and feel quite uncertain about Team A. What’s the difference? Team 1 has a good Product Increment, and Team A does not.
The notion of “Done” in Scrum is about the state of the Product Increment. The Scrum Guide states it very clearly, in these sentences among others:
Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done.” It must be in usable condition regardless of whether the Product Owner decides to actually release it.
Definition of “Done”
Which brings us to the question: What is this “Definition of Done”? Let’s again look at some sentences from the Scrum Guide. I’ve highlighted some key phrases:
Those performing the work and those accepting the work product must share a common definition of “Done”.
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done.” It must be in usable condition regardless of whether the Product Owner decides to actually release it.
It’s all right there. The Definition of Done is a shared understanding, a common definition of what it means to be done. In each retrospective, the team plans ways to increase product quality by adapting the Definition of Done. They are trying to build an increment, each Sprint, that is in usable condition and that includes all the value that has been created since the beginning of the project.
Let’s go over that in a different order. The Scrum Team is supposed to be delivering a usable increment in every Sprint. It turns out that this is hard to do. The Team must learn and agree upon what is meant by usable, and then learn how to build something, every couple of weeks, that meets that understanding. Every couple of weeks, they are supposed to improve that understanding, thereby improving the quality of the next increment.
What is it, then?
The Definition of Done is a common understanding. It is an agreement, not so much in the sense of contract as in the sense of everyone truly on the same page. It evolves, every Sprint, as the Team gets closer and closer to being able to produce an integrated tested Product Increment in every Sprint.
The Definition of Done is never done, because it is always possible to improve the Team’s effectiveness, always possible to improve the product’s quality. The Definition of Done is an ongoing expression of what it takes to build the best possible product in every Sprint.
Is DoD an Artifact?
Should DoD be written down, passed around, made into an official artifact of the project? I don’t think so. To do so will almost guarantee that it becomes a political football, a thing to measure, and a bludgeon. You can write it down, post it on walls, create shrines to it, if you wish.
But what it is supposed to be is a common understanding among all the team members, their Product Owner, and all their stakeholders, of the current meaning of quality in the Product Increment. A common understanding cannot be created by publishing a document: it comes from working together to create understanding, not to hammer out a piece of paper.
Oh, you can do that if you wish. It might even help you build the common understanding you need. But the minute you start treating it as a contract is the minute that it stops working as an agreement for you. Now, go do as you wish.
And remember: the point is to build a working increment of product that you can all observe, assess, and improve.