Learn more about Velocity Partners

Introduction

There are several terms used for it within agile contexts. Sometimes you hear:

• Done
• Definition of Done or DoD
• Done-Ness Criteria
• Acceptance Criteria
• Release Criteria

Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.

The more done’s the more emphasis on completeness. Although I don’t think I’ve heard more than four done’s used in a row.

Done-Ness

Consider done-ness to be the criteria that constrains the teams’ work. If the team were building a bridge, then it would be the engineering rules, practices, inspection steps, local regulations, and completion requirements that would permeate everything the construction team would do. In many ways, the Definition-of-Done should seep into every aspect of agile team collaboration. If agile were a game then DoD would be the “rules” of the game…and the rules would be read, understood, and consistently applied.

I’ve always been a strong proponent of a 4-layer view to done-ness. In his worldview, these layers build upon one another, moving from individual-based work, to story-based word, to sprint-level work, and ultimately to a release. I’ll often use the term “guardrails” to indicate the guideline nature of the criteria in guiding the teams’ efforts.  Now let’s review each of the four levels—

Work Product

This is the layer of the individual contributor. For example, your front-end developers should define some rules, conventions, and standards for how they design, develop, test, and deliver their UI code. The adherence to these standards should be defined specifically as done-ness criteria. This same logic applies to each functional role within your agile teams. Everyone should define a set of criteria that surrounds professional delivery of their work products within the team.

• Who contributes these?  Usually there are two sources. Probably the most powerful is each team defining its own engineering rules. So there is a strong sense of uniqueness as you move from team to team. The other source is more organizational. Say for instance we’re working at a large web design shop where there needs to be consistent UI coding conventions and standards across the teams. I would expect “someone” in the organization to define these—and then for each team to adhere to these broader done-ness criteria in addition to their own.

• Some examples:  I literally gave one above, in that you might have UI development standards. Another example could be coding standards for you primary language or technology stack. Still another could be process based, for example, an “agreement” at a team level to try to “pair” as much as possible on each user story OR to have a “pair review” prior to checking in each story.

Story Level

This is the work delivery level. If you were using user stories, then done-ness in this context would surround defining a rich and meaningful set of acceptance tests per story and then holding yourself accountable to delivering to those functional constraints.  Remember, acceptance tests are incredibly useful as design aids and test aids when the team is sorting out the nuance of each story. I consider that the most important part of the acceptance tests—the business logic design hints.

You should also develop clear quality goals at this level. It may sound prescriptive, but I like the criteria that all bugs that have been found in the development of a story to be fixed prior to declaring that story complete. These aren’t legacy bugs, but bugs created and found during the development of the story. I can’t tell you how many times teams run into problems at the end of the sprint in delivering a completed story with no known bugs.

• Who contributes these? The Product Owner is ultimately responsible for defining the functional conditions of acceptance for each story. However, there are also inputs from the organizational side. For example, agreeing that each story will receive a solid pair-based code review or that a complete set of automated unit tests (TDD) will be developed and running before checking in and “declaring victory” might be decided as overall quality criteria that impacts every team.

• Some examples:  I gave several above. Clearly the story has to meet the Product Owners established acceptance criteria. I also like the notion of the Product Owner signing off on each story. That is, they review it, demo it, and determine that it is indeed—done. Then they physically sign-off on the story. Usually story done-ness also surrounds the design integrity, process steps to develop and test the story, and known bugs.

Sprint-Level Criteria or Sprint Goal(s)

This level is focused towards how well the team has met all of the goals and criteria they set forth when the planned their Sprint. A large part of these criteria are typically driven by a successful sprint review or demo. I like the notion of “connecting the dots” between the sprint goal and the sprint review, so the team should think about the goal as a cohesive demonstration of business value from the customers’ point of view.

In my classes I often get asked, can a sprint have multiple goals, i.e. deliver on multiply focused activities? The answer is probably yes, but what the question is really looking for is the ability to say:

The goal of this sprint is to deliver 524 hours of work towards these specific 12 User Stories that are sized at 27 Story Points.

I think this is an incredibly poor goal because of the tactical, work effort focus. For example, there is no “customer” or no “demo description” in this goal. I’d much prefer goals that have a clear connection to the customer, value, and their challenges embedded within the goal. Having 2-3 separate goals articulated in this way seems fine too.

• Who contributes these?  Truly it’s the responsibility of the Product Owner to define or establish a goal for each sprint. I usually encourage them to bring a tentative sprint goal into sprint planning and then align that with the team and the agreed sprint work as part of the sprint-planning meeting. It then becomes a shared and achievable goal.

• Some examples:  If, for example a team were working on an ATM project, then a few related sprint goals might include:  Complete single customer sign-on and account interrogation to include balance and transaction lists for the past month. Another one might be:  Complete and demonstrate all deposit based activity (single/multi/business) account transactions with receipt printing.  Only check deposits will be supported. I hope you see the connection to real-world customer usage scenarios. I’ve found these goals, which have open-ended functional details, to best inspire the team to “solve a problem” versus “deliver a set of stories”.

Wrapping Up

In this first post, we explored three levels of Done-ness. In the next and final post I’ll wrap up with the fourth level, focused towards releases, and also provide additional guidance around the concept. I hope you hang around for the conclusions – as this is one of the more important focal points in your agile teams.

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 #
• Scaled Agile Framework (SAFe) guidance –
• 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 –