Have you ever been in a situation where someone asks you about the progress of a feature and you say it's done, only for them to ask, "done or done done?" If you've been there, you know that the difference between "done" and "done done" can mean weeks and weeks of additional work.
"Done done" means that it's completely done and ready to ship, while "done" means that it's not really done at all. This ambiguity can cause a lot of confusion and can derail your project.
You want to have clarity about what it means to be Done and all the things that you need to do to achieve Doneness.
The Magic of a Written Definition of Done
To avoid this confusion, it's crucial to have a written definition of "done". This definition is everything that it takes to call a feature done. It helps eliminate ambiguity and serves as a conversation starter within your team.
When you go through the exercise of defining "done" with your team, you'll find that there's a huge difference of opinion about what it actually means. This is why it's important to write it down and make sure everyone is on the same page.
The Difference Between Software Development and Software Delivery
One thing you'll notice when defining "done" is that software developers tend to think that software development begins and ends with them. However, what we're really trying to do is deliver software, which is a lot bigger than just writing code.
Software delivery focuses on the big picture of getting software to the point that it can actually be used. This is relevant because code by itself isn't useful. You've probably heard someone say, "well, it works on my box," which is an indication that the software isn't really done because it only works in one place.
A Sample Definition of Done
When developing your written Definition of Done, you'll need to discuss a lot more than just coding. Here's a sample Definition of Done that I use with teams:
Code is written with unit tests
Unit tests have a minimum 75% code coverage
Code has been merged to Main/trunk/master
Code compiles and unit tests pass as part of an automated build
Database schema objects and upgrade script are under source control
Code has been reviewed by someone other than the original author of the code
Written QA test plan has been run by someone other than the original author of the code
Software has been deployed and tested on a staging environment
Automated UI tests are written and they pass
No severity 1 or 2 bugs (no giant "show-stopper" bugs)
Reviewed by the Product Owner (aka. get feedback early)
Passes acceptance criteria for the Product Backlog Item (PBI)
Known deployment and rollback plan
Deployment plan has been reviewed by operations
Database changes have been reviewed by the DBA
Software has been load tested and deployed to Production
The Benefits of a Written Definition of Done
Having a written Definition of Done (DoD) helps your team to accurately estimate what's going on and understand how much work is left. It also helps the Scrum Master (and the team as a whole) to defend against the "two second fix" request.
When someone comes to your team with a "two second fix" request, you can point to your Definition of Done and explain that while the coding portion might be a two second fix, there are a lot of other things that need to be done. The written Definition of Done also helps to explain to non-software, non-IT colleagues what your team does all day. It serves as a tool to advocate for your team and to deflect blame and annoyance when you have to say no.
Summary
In conclusion, having a written Definition of Done is crucial for the success of your team. It helps to eliminate ambiguity, improve communication within the team, and advocate for your team to the rest of the business.
So, what does "done" mean in your team?
-Ben
-- Having trouble getting to 'done'? Want help establishing what 'done' means in your organization? Got a team that's super busy and super dedicated but somehow still has trouble delivering? We can help. Drop us a line at info@benday.com.
