15 must have items on your Definition of Done
## Definition of done
Well so today I will take a small detour and discuss about Definition of Done, what it is and why do we need it and what needs to be on it.
Do take this with a grain of salt as it might vary from team to team, this has been working for me and I do believe most parts will work for you as well. If not then please share your advice in the comments below.
**Definition of done (DoD)** is a set of criteria that needs to be met in order to produce shippable software. This is a significant element of any highly functioning Scrum Team.
DoD is not just a static list that was defined by some guru at the beginning of the project and its fairly OK to have some items come and go as you progress through the sprints. The focus is still shippable software.
Some teams might break it down into different DoDs like one for feature, sprint and release. I have come accustomed to working with DoD that applies to each Product backlog Item (PBI).
Why is this important you might say? Well if we focus not only on software development, which is merely an act of writing software but rather software delivery which is getting software to the point that it provides some value to the user. As you can see from the two definitions this already starts to make sense, code on its own is worthless but a working product that provides some value to the end user is what we strive for.
If we follow this 15 step plan we would always have a shippable version of a product to give to the user, and phrases such as “It works on my machine a sec ago” won’t happen, and by doing so we will stay true to our promise of incrementally delivering working software with each sprint.
#### 1. Code written and Unit tested
You might notice we haven’t considered things like architecting our product, by following TDD approach, we will have an evolving architecture. So there is no need of super deep foresight of how your software architecture should look like, as this might change from sprint to sprint anyway. Just go with the flow and stick to the known principles and design patterns that work, most of the design patterns will emerge as you continue working on the product, *and do yourself a favor and stay away from those in-house built monster frameworks*
#### 2. Unit test have a minimum of 70% code coverage.
Defining what is the minimum test coverage, reduces the confusion between team members if the code has been tested well enough. Having a number one can refer to is even more helpful, again this is not carved in stone adjust to what works in your situation.
#### 3. Code compiles and all Unit Tests pass as part of automated build process.
CI & CD play important roles in overall software delivery pipeline, having software pass the tests and compile on a build server removes that “It works on my machine” problem.
#### 4. Code Reviewed by someone other than the original author.
Depending on the product and your team size, you may want to have your code reviewed by a third party, its generally a good practice. You cant imagine how many times, I got a very valuable input during the reviews. Its also a good way for developers to learn from each other. You should see code reviews as positive constructive feedback and not just a finger pointing exercise.
#### 5. Code has been merged to Develop branch after review.
You would typically want to have a develop branch which contains the latest shippable version of your product. That is it meets all the criteria of this document.
If you are using a process like git-flow to manage your development work flow, it will mean you will be working in a feature branch after the review you would want to merge the working code into dev, where it will once again need to pass automated build and unit tests just to make sure you haven’t broken anything while performing your merge party.
#### 6. DB Schema is under Git
Adapt 6 & 7 to your situation and the technology you use, some tools provide support for migrations and you can recreate your app data store by running different migration files.
Working with NoSQL databases eliminates the need of storing migration scripts, there are other techniques of handling migrations in that case.
#### 7. DB Upgrade script is under Git
#### 8. Written QA Test plan
Your QA team will write test plans, in case they are doing manual testing or just testing edge cases that they couldn’t automate.
Have someone review the test cases and they should be executed by someone else than the original author. This helps catch more potential errors.
#### 9. Tested QA test plan by someone other than original author.
#### 10. Automated UI Tests are written and they pass.
#### 11. Code has been deployed and tested on staging servers.
You would be probably using the staging environment to showcase your new feature to the Product owner, so making sure that the code is behaving correctly on a different environment, than your dev environment is an important step towards acceptance.
#### 12. Review by product owner has occurred
Product owner should be involved through out the sprint, to avoid any surprises during sprint review.
Its generally a sign of lack of communication if the product owner rejects a feature during sprint review.
So involve them through out the sprint to get adequate feedback.
#### 13. Reviewed against Acceptance criteria of a the PBI
We all get this sometimes, you think you got it what the feature needs to do but forget a minor detail. So review your PBI against specified acceptance criteria before calling it done.
#### 14. Deployment and Rollback plans are in place.
This should probably be higher up the list as you will need to use this plan to deploy to your staging environment too.
Generally having a plan of how do you plan to get your software from one environment to another is a good idea, its even better if this process is fully automated.
#### 15. Load Testing
Again depending on your product you may want to load test it before you put it into production environment, this saves you from all the surprises and memory leaks which wont be caught by the steps above.
