One slightly peculiar question that comes up over and over again with new Scrum teams is: what is the definition of done? And, how do we determine what our team definition of done is?
It is a peculiar question, because if we weren’t practicing Scrum the answer would be obvious. In fact, the Lean and Extreme Programming communities more or less agree on what “done” means without any real discussion: Done == deployed in production, in the hands of real customers.
When Scrum folks talk about the “Definition of Done,” however, they mean something slightly different. There is an important assumption here: software can reach an intermediate state called “done” where it is not yet “released,” but is “potentially shippable.”
Potentially shippable is an equally peculiar idea. In theory it ought to mean that to release or not to release is purely a business decision at this point. The software is complete, accepted, and tested, but it is not released. In practice it often means that the main development activities have been completed but there is some amount of intangible work to be done that may or may not fit inside of a Sprint (e.g. QA testing, deployment to various environments, formal release process, etc.) This is a poor, but common, way to address the “Definition of Done.”
Potentially shippable software is actually a useful idea. From a technical excellence point of view the goal should be continuous delivery, but from a business perspective continuous delivery might not be feasible. In fact, in some domains big-bang delivery actually has inherent value (e.g. any COTS, especially commercial games, and various forms of online media.) [actually, even in those environments continuous delivery is useful, but only after the initial release hits its date...] What we want is for continuous delivery to be attainable, so that it becomes a business decision not to do it. Thus, XP has long had the concept of always releasable software.
So, how do Scrum teams define done? I suppose the real answer is, however they want to, but I suggest the following: Start with everything that it would take to release the software to production. Then, to the extent that it is infeasible to do all that stuff, scale back to something that can be accomplished within a Sprint. Then, continuously improve (i.e. inspect and adapt) until the definition is once again everything that it would take to release the software to production.
Nice blog entry, especially the reasons why you’d not want to do continuous deployment. The only risk is that for the sake of expediency “scale back to something that can be accomplished within a sprint” might actually leave out stuff like capacity testing which validates your architecture. I’d suggest that in order to say you were done, you would need to have showcased from a staging environment that was more or less identical to production, and tested the software meets all its requirements (including capacity, availability, security etc). For COTS this means deploying to a number of environments representative of those customers would use.
Hi Jez:
Really, my advice is to work diligently to achieve a state where software is always releasable. The suggestion to scale back to something that seems achievable is meant to be pragmatic in the short term. However, saying that something is “done” when it isn’t released is a process smell. The intent should be to treat that like you would technical debt and pay it down ASAP.
Unfortunately Lean and XP do have the same problem. This results from the fact that “deployed in production, in the hands of real customers” does not automatically imply “done”. Oodles of features are deployed at customer sites, but yet still buggy or inefficient or unusable for other reasons.
Hi Michael:
1) If you are deploying things into production that are buggy, inefficient, or unusable then the “definition of done” is likely not your problem. In fact, I’m willing to bet that the problem occurred well in advance of the point you declared it “done.”
2) To Jerry Weinberg’s point (see the follow up post, re: Agile Learning) “done” would be when our bodies are cold in the ground. That isn’t what we are talking about. “Done” in Scrum means “potentially shippable,” as I clearly said.
3) “Done” is not really part of the vernacular in Lean or XP. The comparison is between “delivered” and “potentially shippable.”