TL;DR: Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service’s thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people’s hand.

The Scrum Guide™ describes DoD as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

They recommend that having a clear DoD helps Scrum Teams to:

• Work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
  • Clarifies the responsibilities of story authors and implementors.
• Enables the Development Team to know how much work to select for a given Sprint.
  • Encourages people to be clear about the scope of work.
• Enable transparency within the Scrum Team and helps to baseline progress on work items
  • Helps visualize done on posters and/or electronic tools.
  • Aids in tracking how many stories are done or unfinished.
• Expose work items that need attention
• Determine when an Increment is ready for release

Also according to them, DoD is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.

According to the LeSS  website– DoD is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse DoD with acceptance criteria, which are specific conditions an individual item has to fulfil to be accepted. DoD applies uniformly to all Product Backlog items.

Examples

If you search online, you’ll find sample DoD for user stories more or less like this:

1. Short Spec created
2. Implemented/Unit Tests created
3. Acceptance Tests created
4. Code completed
5. Unit tests run
6. Code peer-reviewed or paired
7. Code checked in
8. Documentation updated
9. 100% Acceptance tests passed
10. Product Owner demo passed
11. Known bugs fixed

Another example:

1. Upgrade verified while keeping all user data intact.
2. Potentially releasable build available for download
3. Summary of changes updated to include newly implemented features
4. Inactive/unimplemented features hidden or greyed out (not executable)
5. Unit tests written and green
6. Source code committed on server
7. Jenkins built version and all tests green
8. Code review completed (or pair-programmed)
9. How to Demo verified before presentation to Product Owner
10. Ok from Product Owner

Do you see the problem with DoD? If not, read on:

Problems:

• Checklist Driven: It feels like a hangover from checklist driven project management practices. It treats team members as dumb, checklist bots. Rather than treating them as smart individuals, who can work collaboratively to achieve a common goal.
• Compliance OVER Ownership: It drives compliance rather than ownership and entrepreneurship (making smart, informed, contextual decisions.)
• Wrong Focus: If you keep it simple, it sounds too basic or even lame to be written down. If you really focus on it, it feels very heavy handed and soaked in progress-talk. It seems like the problem DoD is trying to solve is lack of maturity and/or trust within a team. And if that’s your problem, then DoD is the wrong focus. For example, certain teams are not able to take end-to-end ownership of a feature. So instead of putting check-points (in the name of DoD) at each team’s level and being happy about some work being accomplished by each team, we should break down the barriers and enable the team to take end-to-end responsibility.
• Contract Negotiation OVER Collaboration: We believe in collaboration over contract negotiation. However DoD feels more like a contract. Teams waste a lot of time arguing on what is a good DoD. You’ll often find teams gold plating crap and then debating with the PO about why the story should be accepted. (Thanks to Alistar Cockburn for highlighting this point.)
• Output Centric: DoD is very output centric thought process, instead of focusing on the end-to-end value delivery (outcome/impact of what the team is working on.) It creates an illusion of “good progress”, while you could be driving off a cliff. It mismanages risks by delaying real validation from end users. We seem to focus more on Software creators (product owners, developers, etc.) rather than software users. Emphasis is more on improving the process (e.g. increasing story throughput) rather than improving the product. Ex: It helps with tracking done work rather than discovering and validating user’s needs. DoD is more concerned about “doing” rather than “learning”. (Thanks to Joshua Kerievsky for highlighting this point.)
• Lacks Product Engineering Mindset: Encourages more of a downstream Service’s thinking  rather than a product engineering mindset. Unlike in the services business, in product engineering you are never done and the cycle does not stop at promoting code to high environment (staging environment). Studying whether the feature you just deployed has a real impact on the user community is more important than checking off a task from your sprint backlog.

What should we do instead?

Just get rid of DoD. Get the teams to collaborate with the Product Management team (and user community, if possible) to really understand the real needs and what is the least the team needs to do to solve the problem. I’ve coached several teams this way and we’ve really seen the team come up with creative ways to meet user’s need and take the ownership of end-to-end value delivery instead of gold-plating crap.

Often companies undervalue the part-time coaching model.

What do I mean by part-time coaching model?
A coach is onsite, working hands-on with the team for a week and then offsite (accessible via email & phone, but off the project) for a week. Basically, the coach is available on-off either alternative weeks or a some other timeframe.

Personally I’ve experience the following advantages of a part-time coaching model:

From the company & its employees’ point of view:

• When I’m not there full time, teams realize they cannot fully depend on me. I’m not the bottleneck for making decisions. The teams start to take ownership and make more decisions on their own (usually by consulting me, but not waiting on me.)
• When I steps out for sometime and come back to the team, I bring a slightly fresh perspective and can pay attention to weak signals. Many times we get so engrossed in what we are doing, that we might miss out paying attention to something else.
• Coaching can be intense. Having a little time off from coaching helps the teams get a breather. Which makes the overall coaching more sustainable.
• As coaches we expect things to change much faster rate than usually they do. If we are there full-time, it might start to bother us. But with the on-off model, the slower rate of change seems more acceptable. Similarly the team does not feel pressurized to accept change at a rate that might not be sustainable or acceptable to them.
• The management seems to get more confidence in the whole engagement, because they can see things are not blowing up when the coach is not around.
• Last but not the least, it does have a good financial incentive for the company.

From the coach’s point of view:

• Having some downtime is good for the coach to build/upgrade their skills.
• Can help achieve a better work-life balance.
• From a risk management point of view, it allows a coach to take on multiple part-time client.

Hopefully, all of this leads to a more effective coaching engagement.

A lot of people think, if they can write some code, they qualify as a software developer.

IMHO don’t call yourself a developer if you don’t take ownership and responsibility for solving the overall, real business/user problem.

A good developer

• understands the overall problem and its context.
• has good problem solving skills (we are in the business of creative problem solving)
• has empathy for the users and is a user and business advocate.
• takes ownership by being a part-of the team and having a sense of belonging.
• makes investment into continuous learning & improvement

[Agile and Software Craftsmanship movements has made great strives in this direction. However some Agile folks don’t get it. We can’t draw a line and say this side is business and that side is development. Its ONE team working towards a common goal. Unfortunately, I’ve seen a lot of teams who end up creating artificial boundaries between people wanting the software and people building it.]

Anyway, having the ability to just writing some code does not qualify you to be a developer.

Almost a year ago, I wrote something more insightful: Programming in the 21st Century