almost Done
How many times have you encountered different answers to the question "Is the story done?"
The development is done, but testing is pending.
The development is done, but code review is pending.
The testing is done, but the documentation is in progress.
The documentation is almost done.
The testing is complete, andthere are some defects reported, but otherwise we are done.
So then what is DONE? When are we really done?? Everyone you ask is almost done but the story as a whole is far from being done. Does this sound familiar??
Imagine such a situation is any other scenario for example asking the builder and/or any member of his team - Is the house that he is constructing for you DONE? (The expectation here will be that the house is ready to move in), and the all of themtelling you daily that it's almost done... Imagine the frustration you'll have and the resultant erosion inyour confidence in the abilities of the said person and his/her team. The same holds good for any type of software development. When any story is described as DONE, then everyone in the team must understand what DONE means.
And the simplest way to ensure that the team understands what is DONE is to have a Definition of DONE (DoD). DoD should ensure that the features/ stories delivered are complete not only in terms of functionality but also in terms of quality.ForAgile Software development:“done means DONE!”Done means the functionality is potentially shippable.
A DoD is simply alist of activities that are needed to be complete to add verifiable value to the product. A DoD can be defined at multiple levels: Story, Epic, Sprint, Release.
The DoD for a story can be (I'm borrowing from my organization's DoD as I found it comprehensive and because I helped finalize it):
- Developed
- It is working for all acceptance criteria
- Code is reviewed (Well defined coding standards)
- Unit tests are passing and automated, Codecoverage maintained or increased
- Code is checked-in to the version control system and build created by Continuous Integration
- Static Analysis check is green
- Tested
- All testing approaches identified in the test strategy have been covered
- All functional test cases are passing and acceptance criteria are met and automated
- It is not impacting any other existing functionalities (regressions passing)
- No open defects (Severity is chosen by the PO)
- Documented
- New changes are documented and reviewed
- Potentially shippable
- Demo to the product owner from UAT/Test environment
- Accepted by the product owner
- Non-functional acceptance criteria met (if applicable)
- Tools are updated
The entire team should be aware about the DoD. A DoD that no one knows about is useless. The team can discuss and decide on what all it can potentially include in its DoD. The team is collectively responsible for its DoD.Every member of the team should not only know the DoD but should also be committed to it.
The DoD should be regularly reviewed and discussed. If a team is not able to complete its stories within a sprint, then the reasons preventing it should be discussed. The reasons for the same could be external dependencies, defective DoD, skill set issues, issues with the tools (e.g. automation), large stories that were not broken down and so on. Similarly as the team becomes more effective and learns to work together, the DoD should be refined to include more stringent criteria for higher quality.Over time, thisshould lead to higher-quality code.
The stories that do not meet the DoD should not be demoed in the Sprint Demo. This helps to reinforce the teams' commitment to the DoD.
A short-changed DoD will lead to either creation of technical debts or rework by the team. This may become apparent long after the causing event, and willbe difficult to trace. Henceteam ownership and enforcement of what "Done" means is of utmost importance. An effective DoD has to be founded on a healthy balance between due diligence and professional trust.Having a meaningful DoD encourages a team's sense of ownership, and helps instil self-discipline to follow agile best practices.
https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod)
https://manifesto.co.uk/definition-done/
http://www.solutionsiq.com/what-is-the-definition-of-done-dod-in-agile/
The images used in this article are not mine. They were found on the internet and I do not lay any claims on them.
