In the last post we explored three levels of my four level model for Done-ness Criteria. Now I’ll wrap up the model and explore some other aspects of DoD. I hope it inspires you to review, reevaluate, and potentially changes YOUR Definition of Done. Enjoy!

Release-Level Criteria or Release Goal(s)

If you’ve ever been part of a team that delivered software in more waterfall environments, a common practice is to create release criteria. These are project constraints requirements that are usually established at the beginning or early on in a project. Often they are consistent from project to project or release to release, because they quantified organizationally important criteria. For example, quantifying whether you could release with specific levels of bugs (both in priority and count) or quantifying how much testing (coverage) needed to occur prior to a release.

One of the unfortunate parts of many agile adoptions is that these sorts of criteria have been dropped. I think they’re incredibly valuable in defining meta-requirements or key constraints for the teams to adhere to within each release. Typically they exist anyway within the organization, but calling them out creates a focus on them in planning, execution, and delivery. They’re particularly important in at-scale delivery—so that multiple teams are maintaining a consistent focus on the overall release goals.

• Who contributes these?  Usually they’re defined outside of the team proper. Either being defined by the Product Ownership team or Chief Product Owner as part of establishing the definition of a release. More often, they carry-over from release to release. They are typically “not optional”, so the organization needs to be willing to block a release or drop a feature if it does not meet the Release Goals.

• Some examples:  I’ve already mentioned allowable defects in the release and test coverage as solid examples. Global performance targets or usability constraints are often mentioned in applicable projects—so there is often a focus on non-functional requirements.  Process constraints or commitments might also be mentioned, for example, the fact that each User Story needs a minimum of 70% automated test coverage before being considered a candidate for your release train.

Getting Done-Ness into your DNA

Creating a list of your Done-Ness Criteria is only the first step. Just because you have created and communicated them, doesn’t mean that everyone is supporting them. The next step is establishing a culture where everyone aligns with and personally supports the criteria. Not just when things are going smoothly, but when the going gets tough as well.

You know that your done-ness has seeped into your culture when the team sees no other recourse but to do things the right way. I’ll share this example from iContact that illustrates this cultural transformation—

We were a SaaS e-mail marketing software product and our customers used us 7×24. In fact, our weekends were often quite busy as SMB owners worked on their next week email campaigns. There was one weekend where a nasty mail sending component bug cropped up. It brought down our ability to send email, which clearly affected all of our clients. Not only that, when this happened, we would queue the mail. So this started created an endlessly increasing pool of mail that would cause delays even when we fixed the bug.

So the pressure was on.

Our teams would normally assign a “support engineer” for weekend support. The engineer in this case was notified of the problem, looked into it, and devised a repair. As part of our DoD, we’d agreed that no fix or repair could be checked-in without a paired code review. Now keep in mind—this was a holiday weekend, so people were on vacation. The support engineer determined that he needed a review with two others who were experienced in this area of the mail sending stack.

He found them via text messages and phone calls and they all committed to a distributed/remote code review session on Saturday afternoon. They discussed a few issues and changes related to the repair, then he completed those adjustments and release the repair.

When I came in on Monday morning I was amazed at how committed the team was to doing a proper review. It would have been the easiest thing in the world to have either checked-in an un-reviewed repair OR waited until everyone was back on Monday. But the support engineer and their team were committed to our customers and to their Definition-of-Done. It was in their DNA.

Why Done?

So after all this discussion, you might be asking yourself – why all of this focus on done? Why does it matter?

It matters from several perspectives:

• It helps with your estimates. Pre-agile methods, I’ve used done-ness like criteria in my teams because I felt that if we didn’t have clarity around what went into completing our work, how could we estimate our work. That’s the very point we’re focusing on here. Clear understanding of what is expected in completing our work.
• It helps with your quality. It provides guidance to the team surrounding what makes each step or deliverable complete. It focused on quality of the steps. And it amplifies consistency – so that every deliverable meets a consistent level of completeness.
• It helps your Product Owner and Customer gain confidence as the team delivers. And it’s not just confidence on the individual stories. It’s confidence on the overall plans and teams ability to meet their commitments with consistent quality.

Is it a panacea for any of the above? Of course not. But it is a key driver for some of the core behaviors that agile tries to amplify in teams. That’s why you hear so many agile coaches “harping” on it.

Wrapping Up

I often emphasize Done-Ness as a place for the organizations leadership team to influence the behavior, focus, and results of their agile teams. I encourage them to get engaged with established a deep, broad, and relevant set of criteria for their teams. I ask them to align their DoD to the business, customer, and constraints. I sometimes call them “guardrails” because of my view that they can keep the team “safely on the road” in their delivery of business value and results.

Since I see so many sparsely defined DoD’s it the real world, I usually ask for organizations and teams to over define them – risking a bit of prescriptiveness. I’d rather have more clarity than less guiding the teams.

Hopefully this article has helped clarify a view to what done looks like in agile teams. Now go take a look at your own and see if you need any adjustments?

Stay agile my friends,

Bob.

References

• I believe it was 2010 when I attended the annual Agile Conference and Salesforce shared on their instance of agile. One of the specific practices they explored was their Definition of Done. I’ve actually captured their DoD circa 2010 in this slide deck (slides #
• An example of what I’d call first-level criteria from a developers POV –
• I like Mitch’s take on DoD in this article. He covers multiple levels and suggests ways to formulate your DoD as a team –
• A quick guide from Rally –
• A video from Crisp –
• Another video –