Imagine your team has done everything that was required. They're happy. At the same time the client is angry because the work is incomplete. Or picture this: you're approching the project launch, everything's implemented but just before go-live it turns out that there's still loads of work with configuring, deploying and securing the application. The launch gets delayed. Say "hi" to poor, assumed or undefined definition of done - source of many miserable failures.

At a glance definition of done (DoD) seems a small part of the process. You may think "I know done when I see done". It's not that obcious in real life. That's why Scrum requires us to explicitly define when something can be deemed DONE. Many teams and customers often don’t bother defining it. They assume something. The thing is that the team assumes something different from the client. For example the team considers the code in the repository as implemented feature. The customer can expect the code to also be tested and deployed on server X.

Risks of Not Having Good Definition of DONE

What can go wrong when you don't make your DoD explicit.

  • Delays. Poor definition of done tends to hide work from our plans. This work needs to be done anyway - someone has to configure the server, deploy the application, etc. Nasty feature of this invisible work is that it tends to reveal itself just before the deadline.
  • Stress. Having big chunk of work being exposed late in the project will result in lots of stress for the team and everyone around.
  • Quality problems. What happens when you discover there's too much work and too little time? You cut corners - skip tests, limit functionality, remove features...
  • Poor cooperation. If it's unclear when work is done, then it's not clear who should take over it, when and what should happen next. Imagine the unpleasant surprises for the ones who should pickup the work but are not aware of it till the very moment it needs to happen. You don't want to be forced to go and urgently request an admin's week of work, when they're busy with their own projects.
  • Problematic handover. Handover is always a tricky part because it results in information loss. It's often source of delays because others are almost certainly busy with other things. By defining what DONE means you can make the handovers explicit and expected by people involved. Put that application deploy on everyone's calendar well ahead.
  • Undelivered value. What's the use of features implemented in the code if they cannot be used? They may be waiting for the testing department, or admins... Heck, they can often be implemented and nobody knows they're done already.

Benefits of Defining What DONE Is

Here's what you gain by adopting a common Definition of Done:

  1. No gaps. Know when the work of the development team really ends. Make them certain that they've done their job, that there's no surprises towards the end. Save the team from working overtime or cutting corners.
  2. Explicit handovers. By agreeing to the DoD together you make explicit what is the final product of development, where is it, how is it delivered, is it tested, who delivers it and what will happen next. Failure with any combination of those may end up in unexpected work.
  3. Clear responsibility. It needs to be clear who does what. Who’s responsible for which part of work.
  4. Accurate estimates. Having a clear definition of done ensures the team can account for all the work required to deliver the project. Including tests, documentation and deployment. Make your plans more robust and realistic.
  5. Delivery on time. Having good control over handovers, no gaps in the project delivery and estimates of all the work necessary causes less delays and much lowered stress before deadlines.

Remedies

Call it however you want if you're not doing Scrum, but make sure you agree with the team and the customer how you cooperate. Build a checklist that you could use in new projects:

  • what do we deliver?
  • where do we deliver the code (output of our work)?
  • who is responsible for testing?
  • do we deploy it anywhere?
  • who do we let know the work is shipped?
  • how client and stakeholders can see the current state of the project?
  • what level of documentation is required? Who will use it?
  • ...

Those are just some ideas how to avoid gaps and delays when shipping the work. You may need your own set of questions specific to your kind of work and your environment. In every case spending just a little time to define when work is DONE and what it means will save you a lot of headaches down the road!

Good luck with you projects and be sure to subscribe to future posts (RSS)!

This a 5th post in my series on keeping the benefits of Scrum even if you can't do it 100%. Previous ones were about:_

  1. Lack of retrospectives
  2. Poor planning
  3. Scope changes
  4. No client demos