Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
10  
When the client calls it done. –  Matt S Aug 22 '12 at 15:50
7  
No one is ever going to skip updating the documentation? –  JeffO Aug 22 '12 at 15:53
1  
Does your organisation as a whole have a problem with some people thinking things are done when other people think there are still things to do? If not, then you don't really need to spend any time here. If they do, well, you have a starting point for your list –  AakashM Aug 22 '12 at 16:11
    
@MattS: If you have to wait for the client to call it done, you have a lot of stories awaiting completion. There must be some sort of "development complete" or "ready for UAT" status for a story which in colloquy is "done as far as the team knows". –  KeithS Aug 22 '12 at 17:07
    
Pick a system and stick with it. Kaizan it occasionally. This is a case where consistency improves productivity. The hard part is being the process (dictator for life) in the beginning until everyone sees the benefits (yes, yes, sell it). –  Paul Aug 22 '12 at 20:14
add comment

4 Answers

up vote 9 down vote accepted

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.

share|improve this answer
    
Excellent point you make about new team members, Nasir. –  Carson63000 Aug 22 '12 at 22:36
    
Thanks. We face this situation fairly regularly, and oldies such as myself forget at times too. –  Nasir Aug 23 '12 at 10:33
add comment

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.

share|improve this answer
    
That all sounds very good in theory, but how do you come up with one that's relevant? E.g., I don't need a checklist to brush my teeth every morning, yet I still do it. The points you list (tests pass, peer reviewed...) feel like tooth-brushing, so where's the added value? –  Tobias Aug 23 '12 at 8:36
    
@Tobias The value comes in the repeatability. You now can visualize your process and share it with others. You can also visualize it to identify areas for improvement (things that people do that aren't on the list, things that don't need to be on the list, things that people don't do that are on the list). –  Thomas Owens Aug 23 '12 at 10:33
add comment

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

share|improve this answer
    
Code quality metrics is an interesting idea we haven't thought about yet. The rest (coding style, CI green after merge) is already part of "the obvious parts". –  Tobias Aug 22 '12 at 16:32
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.