11/2/2018 3:00:00 PM Tihomir Bertović, Business Analyst Assistant
In modern practices, teams are working on User stories or other work items in sprints. At the end of the sprint, the team is expected to deliver. But every person in the team has a different understanding of the Definition of Done. As a result of their different understanding, both productivity and quality can get lowered. Let's find out what the Definition of Done really is!
As a newer member of a team, I've encountered the problem of Definition of Done in both, educational literature and while working on different on projects. It seemed that the definition of done changed depending on the function of the team member.
One team member will think that a User Story is done when he finishes writing code, another will think that a story is done when he finishes writing or changing stored procedures or queries, or maybe after the code was reviewed and has a green light it’s done, others will think it’s done after final product matches acceptance criteria. For your boss, maybe, it will be after the increment is delivered to the client. For Product Owner it's done after the product is delivered to production and application users are satisfied.
Since every person in the scrum team has a different understanding of done there are indeed some inconsistencies in work such as bugs, change in delivery plan and various other problems. When team member ˝blindly˝ writes code to fulfill acceptance criteria without thinking about the bigger picture, i.e. parts of the code that will be impacted by the new code, various bugs and instabilities may arise. This may impact negatively on team morale and overall velocity. If the team velocity drops it will impact client satisfaction and product value.
During my career, I encountered a case where, after testing, Scrum Product Owner was satisfied with the new feature. He was prepared to push it to production, but one of the stakeholders saw it and decided that he doesn't like how the feature looks, although the design came from their side. Familiar situation? This made us add additional work to the backlog because the whole feature had to be scrapped and extracted from the solution. Although by every scrum guidance out there this was an example of a story done as per definition, it still shows us that even stakeholders can eventually affect the product.
Because of all the things mentioned above I believe it's important to understand and know more about the definition of done.
Definition of done
By the book, the definition of done is:” …an informal checklist which the team agrees to apply to all pieces of work. The whole team is responsible for approving and writing the definition of done and applying it to every story they work on. “
Definition of Done is a shared understanding of what it means for the work to be complete. Each Scrum team has its Definition of Done. The team agrees on and writes down (somewhere in the team room or slack, google drive, etc.) a clear definition with a list of criteria which must be met before a product increment, usually, a User story is considered “done”.
Also, one of the best practices is when team writes this list on their team board, where it is visible to everyone. Before any work item is marked as done, everyone on the team should ask themselves: “Have I done these things?”
In other words: “Definition of Done is a checklist of features and activities, for example, coding comments, writing code, release notes, unit testing, design documents, integration testing, etc. that adds or signifies value to the product”. The team has to focus on iterative steps which are adding value to each new iteration of the product. Each iteration has to remove useless activities that complicate and prolong the development of each new iteration.
Definition of Done serves as a reporting mechanism for every member of a team. Each member can say with DoD: “This feature is done.” Definition of Done is used as a reference between team members so they can adequately communicate with other team members and the product owner.
Each team has its Definition of Done and they are responsible for creating it and maintaining it.
The team must make sure that it is acceptable and that all team members practice it on all the work they do. In this way, DoD serves as a professional oversight and assurance that any deliverable software product will indeed be ready for release. When Definition of Done is efficient it is established on trust between professional team members and honest earnestness of each team member. When “done” is confirmed it adds value on or product. Just having well-defined benchmarks isn’t insurance that everything will be truly “done”. Quality is built in and validated by inspection.
The Definition of Done versus Acceptance Criteria
Each User Story has Acceptance Criteria that is agreed on by the team members and the Product Owner. Acceptance Criteria must be quite specific to the particular User Stories because each story can be unique.
The Definition of Done must be applied to all User Stories that team is working on. Conditions for the different User Stories shouldn’t matter for DoD. Since all work completed by development must be peer reviewed and tested by QA before release, this criteria should be in Definition of Done and shouldn’t be every time in acceptance criteria for each User Story. If Definition of Done is adhered to every time, team members can never say that User story was finished and “done” if they hadn’t got the green light by review and QA testing.
Even the Scrum Guide describes a Definition of Done as a "shared understanding of what it means for work to be complete." No process is suggested for writing a Definition of Done, nor in fact, is there any suggestion that one should be written down at all. However, a documented definition may go some way towards providing that shared understanding.
A definition of done is a universal benchmark for all User stories and not substitute for acceptance criteria. Each story has its unique acceptance criteria. In every set of acceptance criteria, there should be one unwritten criterion: “User story complies to the Definition of Done.” Or we can look it in another way that every Definition of Done has to have one item which says: “All Acceptance criteria has to be met”.
The aim of both acceptance criteria and the definition of done is to improve the quality of the code produced. Research and programmer's intuition are consistently showing that higher-quality code saves time and, therefore, money. If the product of new development iteration is low-quality code, that code has to be tested and fixed time after time in a loop which cost more money and takes more time than it was estimated.
In the end, it can destroy schedule and there is a risk that client will be presented with a poor quality product.
Each team must agree on what the definition of done is for their particular projects at various levels (story, sprint, release, etc.) All bugs that have been found in the development of a story should be fixed before declaring the User story complete. A Definition of Done that no-one in the team knows about is almost to useless.
In conclusion, we can say that the Definition of Done is not set in stone. Teams should regularly look at their Definition of Done and review every item on it. When the team narrows their Definition of Done over time that leads to a higher quality product (code). Conversely, an overly long definition might be self-defeating, as people will eventually consciously or subconsciously skip steps.
Through project lifetime teams Definition of Done won’t stay same nor it should, because teams become more efficient and competent, as members learn to work better inside of a team. Throughout projects, many iterations team will usually enhance and refine their Definition of Done which will result with higher quality features and products (code). With time team notices patterns and methods which they need to deliver a high-quality product and they start to include these to the Definition of Done.
Tags: Definition od Done, DoD, Done, Productivity, Scrum