Why you need a “Definition of Done”

OH

Customer: Strange, I don’t see the new merged list feature we discussed about last month.
Developer: No, it is not there yet.
Customer: But it was marked “done” in our last meeting?
Developer: Yes, sure, it is done, it is just not deployed yet.
Customer: Ah. And so, when will it be do-… Errr, available?

You can replace the Customer with a Project Manager, but if this conversation looks familiar, read on. This situation is a stereotypical demonstration of the absence of a clear and common Definition of Done (DoD) in the team.

What is a Definition of Done?

While the term look specific to Scrum, the concept itself does exist in most agile methodologies. +1 to Scrum to make it explicit, so I’ll quote a part of their definition:

“A common understanding of completion by those working on the story”

Of course, “those working” does not limit itself to the developers, but takes into account all stakeholders, and first of all the customer (or customer representative).

Why it matters

Post-it Pacman (Photo credit: Siddhi)

Well, first of all, it avoids the kind of conversation outlined above – and thing can get much worse than that. Most problems will be far more implicit than this conversation – hence much more severe.

The baseline is: agile is all about measuring progress. How can you measure progress if we don’t agree on what “Done” means.

For the more visual of you: when can I move this post-it (or issue or ticket) from the column “in progress” to the column “done”?

DoD experience

I have the chance to work/having worked in several teams with different environments – which made me realize that DoD are quite team/environment specific, so what is good for my team may not be right for yours.

At 8th color, we manage the whole cycle from spec to deployment between the three of us. Our DoD actually include:

specified
coded
unit tested
reviewed (using our own PullReview & then by another programmer)
merged into develop

Note that while the feature need to be “production ready” (documented, any attached configuration specified, etc), the “put in production” itself is not on the list – for a good reason (see stuck stories below).

Things to consider

Even with all the differences between teams, there are still some general things to consider:

DoD should require only tasks unders team’s control.I.e., if the deployment is done by another team, then your “done” cannot require deployment. Why? Because it would mean for the team to take responsibility for tasks they have no power on.

As per the solution, either set your DoD to the last task between passing the ball (ie, the “next team” has received the package and all related informations according to the rules in place between the two teams), or find a way to integrate someone from this “next team” into your stakeholders. This is especially a good idea if the “next team” are end users. In other words, if you need a user approval for marking a task as done, let’s bring one as stakeholder.

Yes check (Photo credit: Wikipedia)

Avoid having too many states. This might be slightly controversial. While “done” checklist can beuseful (I sort of gave mine above), avoid multiplying the various story “states”. Ie, avoid the big board with 8 columns like: “to do, dev, unit test, review, functional test, integration test, user validation, deployed”, with the post it moving from column to column. This creates several problems like diluting responsibility, obfuscate progress (as task may go back and forth for example between review and development) and more generally voids all the advantages of having a DoD (shared definition). I try to keep a three- (todo, in progress, done) or four- (todo, in progress, user test, done) column board.

Almost there (Photo credit: myrrh.ahn)

Progress vs Customer involvement. Try to avoid elements that “stick” stories. Typical example:you may have end users testing your app, but they may not be available during all the sprint, but only in the end for a Sprint Review. Or you may be able or authorized to deploy only once per sprint. In those situations, don’t put those action in the DoD, as it will result in all tasks moving then getting stuck just before “done”. Again, measuring progress will become almost impossible, and this impact the team perception and morale. I do have this limitation in one team, and I’m looking to remove it – by finding a way to get tests before the end of the sprint, hence releasing (and deploying) features as they are done.

Finally, remember, those are guidelines and some experiences, but the most important thing for your DoD is that it fits your team, not mine. Again, I’m not using the same DoD in every team I’m a part of – and that is fine.

Conclusion

If you are agile and don’t have an (explicit or implicit) DoD, you have a risk, and are missing a good opportunity to set the team on the right track. Why not plan a “DoD” definition session with the team and related stakeholder? One hour with some post-it should get you pretty much done, and increase your team collaboration for cheap.

If it is implicit, why not explicit it (just to check that everyone is on the same level)?

Lastly, when reviewing this post (yes, we also do “post reviews”), I got two insightful comments:

Stephan:

“It’s not done if it’s not in production and monitored, actively operated and maintained.

Devops done definition : until your last user dies and your legal duties are over.”

Christophe: