What does a good "definition of done" for a mature team look like?

Question

When looking at examples of definitions of done in various sources, they usually include points like

• code completed
• unit tests run
• code peer-reviewed or paired
• code checked in
• documentation updated
• …

In our team, we have a similar list, but nobody ever looks at it because those points seem so blatantly obvious that it wouldn't occur to anyone to skip any of these steps. So we were wondering whether that's mainly a tool for teams transitioning to an agile process and whether we shouldn't just get rid of it.

On the other hand, lots of literature claims that all high-performing teams have a strong definition of done. This kind of hints that we might miss an opportunity to improve here.

So what are examples of strong definitions of done of a mature team? What kind of points do they include typically?

Answer 1

The guidelines are there for everyone. In a mature team, as you mentioned, everyone is doing it, so it does not mean there is no place for it. Suppose, a new member joins, who has not been exposed to this methodology before. Having the structure in place, would be vital for him. He wouldn't have to bother other members, or wouldn't "forget" a deliverable.

In my opinion, List everything, including the obvious. Perhaps, have a "short cheat list" for non-obvious ones if it helps those who want a shorter list, but consider the case of new members hopping on.

It is an iterative process, every time you see something you can improve, add it in the definition of done. Overtime, you will develop a list which is relevant to your company. Anann has already mentioned some which are worthwhile.

Answer 2

Just because the points are blatantly obvious doesn't mean that people will always carry them out. Let's take two other examples - pilots and surgeons. A cockpit of a commercial airliner or an operating room has multiple people, with a good deal of education and experience between them. However, things still go wrong - steps are done out of order, something is forgotten, something is done incorrectly. I've seen a number of sources site that a large number (up to 70%) of aircraft incidents attributed to pilot error could have been prevented with a checklist. In the medical world, up to 29% of malpractice lawsuits in the Netherlands could have been prevented with the use of a checklist, according to researchers. Although these people have been trained, and in hindsight would probably easily identify what they did wrong, something happened that caused them to lapse. I haven't read it yet, but The Checklist Manifesto is supposed to be relevant. It's written from a medical profession, but the advantages of making a checklist or flowchart visible as a reminder of what to do are applicable to any profession.

So, step one would be to create a list of things that are part of your definition of done and make it visible. It doesn't matter how obvious that task is, if it needs to be complete for the story to be considered done, it needs to be on that list. The list needs to be somewhere visible to the team. Note that it doesn't have to be anything fancy or formal - perhaps just a series of questions that everyone needs to ask themselves before a story can be called done.

Step two is to decide what goes on that checklist for your definition of done. Everything that you need to do to complete a task should be specific, unambiguous, acceptable, and realistic. It also needs to be within a context of time for consideration of done. For example, you don't need to include "modify code" or "modify design" in a definition of done - if you didn't need to change a work product, there was no need for the story.

I would suspect that a good checklist to serve as a basis for a definition of done would be:

• Have all associated unit, integration, system, and acceptance tests been updated?
• Has the work product been transformed into its releasable form? For example, code built, documentation in the exportable file format, etc.
• Have all associated work products been peer-reviewed? Examples of work products include source code (production and test), comments, design documents, test procedures, and user manuals.
• Have all associated tests (at all levels of testing) been executed and pass?
• Has the code been merged into the integration repository?

Of course, you'll need to come up with a good definition of done that includes any other activities that your team and your customer feel add value. If it's on the checklist, it should be something that needs to be done to add value to someone (the team, the customer, the user). By clearly enumerating what you do, you can also identify and eliminate extraneous activities to improve the process.

Answer 3

This actually sounds like you are one lucky guy:

In our team, we have a similar list, but nobody ever looks at it because those points seem so blatantly obvious

Your team is already "mature" ;-). But there is always room for improvement!

To your question:

So what are examples of strong definitions of done of a mature team? What kind of points do they include typically?

On top of your list, you could add:

Various code quality metrics: - Instability, Abstraction - LOC vs DLOC (documented) - etc...

The rule of thumb could be that the metric should not get worse with your commit. On top you could formulate a "done:withExcellence" if someone actually makes the metrics get way better. Although this (metrics getting better) is usually not part of development phases (new features) but refactoring phases.

In one of my past companies we had a definition of "done" that said that your metrics need to stay below certain thresholds, if you go above, you are not done yet. (Cyclomatic Complexity should never go above 15, unless you have a very very very good excuse, like complicated calcs.)

Same goes for Checkstyle type of violations, especially if you have a custom rule-set to check on your teams code-style. If you are in violation of the coding standard, your are not done yet.

Then you could not only execute UnitTest, you could measure code coverage. If not at least 50% are covered, you are not done. Although this is kind of a flaky defintion of done, since you should have tests for the core/main/critical methods, and not necessarily for 100% of your code base.

Oh yea... and if you have (you should) a CI server with automated branch integration... you are only done if your commit in the DEV Branch merged with the current LIVE-Branch and causes no errors either. (Unit Tests, etc.)

hmmm... that's all I can remember right know from past companies/projects, which hasn't been mentioned in your list.

I hope that gave you some ideas ;-)

Cheers,

anann

Answer 4

In a TDD/BDD environment, the definition of "done" (technically "Code Complete", as Matt S's definition of "really 'done'" is correct) is pretty simple:

• All automated tests pass (those automated tests should include new ones written for the story in question to verify the required functionality or behavior exists and works)
• Code review passed (at least one senior dev on the team is content to let your work become part of the codebase, and that you didn't "cheat" or "hack" your way through the story)
• Commit successful (including the build bot passing all automated tests, code coverage metrics, style cop checks, etc)

At this point, you can move on. These three points are critical, but they're all that the average team coder must be concerned with. Written or unwritten, they are inviolable in a TDD environment. Documentation, when the coders are the ones doing the documenting, is an additional point. In my last Agile team, documentation was handled by the BAs/QAs; they knew what the client wanted, had run the UATs, and thus were best able to document the new feature in a way that was meaningful to the client, so documentation was not part of the coder's definition of "done", though it was part of the team's definition.