There is a question that every project manager has ever asked himself: how to determine the degree of completeness? .
Without this knowledge, it would take a team ages to deliver the project. And no one is interested in it, for sure.
Actually, this article is about finding a balance between team members, stakeholders, and the time continuum – it is about a Definition of Done, a cornerstone of every project. But what things define this thing and why is it really a game changer? Let’s sort it out with RedmineUP!
With this article, you will learn the following:
- Definition of Done: Meaning & Origin
- Application of a DoD: Common Levels
- What Are the DoD Benefits and Traps That It Is Hiding?
- Definition of Done vs Acceptance Criteria
- Action Plan: How to Create Your Actionable Definition of Done
Before reading the article, we suggest you familiarize yourself with our company by watching the video.
Definition of Done: Meaning & Origin
The Definition of Done (DoD) is an agreed-upon compilation of criteria that a development team must accomplish for a project or user story to be marked as “done”. By this it is also meant that a final product meets the quality standards and is ready to be promoted to the next level.
To put it differently, a properly created DoD captures a shared vision of what requirements are needed to comply with. The whole procedure might be supervised by a Scrum Master or a team leader. In doing so, the releasable result is guaranteed.
But when and how did a DoD appear? It all started in 2002 when Bill Wake, a famous inventor of the INVEST model for user stories, published an article raising a pretty controversial question: how should teams deal with the difference in the wording of “done”. Just a few years later, the term appeared in training materials as an important part of exercises. Those were aimed at teaching Agile trainees to find a DoD in a variety of scenarios.
Thus, originally born in Scrum, the DoD concept has gained popularity in Agile. Teams are using it on a regular basis at different project levels. What are they? No worries, we are about to cover this question.
Migrate to secure hosting
Don't waste your time on Redmine maintenance. Hire experts and focus on your projects
Application of a DoD: Common Levels
User Stories
This is where a DoD is used the most frequently. On the delivery team level, “Done” means that the product owner checked all the acceptance criteria and approved the user story. To help illustrate this, these are the definitions you might expect from your team:- Code developed, reviewed.
- Unit tests passed.
- Functional tests passed.
- User documentation updated.
- Product owner accepts the User Story.
Features
Not all user stories are meant to be completed. It means that one feature is sometimes sufficient to meet a specific need. After the feature is done, it contributes to the release velocity. On this level, you are going to hear this:
- Feature level functional tests passed.
- Non-functional requirements met.
- Compliance requirements met.
- Promoted to higher level environment.
Epics
Finally, epics is the level where a DoD can refer to making strategic priorities or collecting those features that cover a market demand. Being accepted, the epic ensures whether the supplies and demands are balanced. In this case, what is “done-done”?
- End-to-end integration finished.
- Promoted to production.
- Defined market expectations met.
RedmineUP Solutions
Extend your Redmine functionality with our solutions and services
What Are the DoD Benefits and Traps That It Is Hiding?
Like all in the world, a DoD offers you two sides of one coin: unconditional success or failure. And it is your turn what kind of a fork you are going to choose.
DoD Benefits
- Crystal-clear inner transparency. The team shares a profound understanding of what “done” signifies. Being on the same page is a key factor of group and team play: no one is going to argue and mess around when there is a predefined collection of steps that you must take before the product is complete.
- Precise scope of work. Stakeholders or customers are also informed how the done scope of work looks like. Not only does it limit the rework cost and timeline but decreases the risks of possible misunderstandings in the future.
- Provided insight into your development approach. A good DoD helps organize your team’s approach and facilitates discussions on the topic. The more you want to better the approach, the more you should review and approve the DoDs.
DoD Traps
- Do not overthink. If you are going to throw endless conversations about the done criteria, your list will be a huge volume that no one is ready to read. It is not what we are trying to create. Rather, a well-crafted DoD needs to list the minimum work commonly required to move the increment from in the progress state to the done one.
- Dot the T’s. Make sure everyone shares the same opinion. Spell a DoD out a few times, even put it on the wall so that it will always be in sight. Systematically get back to it. The major strength of a DoD lies in common principles supported by the whole team. In words and deeds.
Definition of Done vs Acceptance Criteria
Before we plunge into some practice, we want you to clearly understand the difference between a generally defined “Done” and specific acceptance criteria.
In layman’s terms, a Definition of Done applies to everything the development team is working on in this sprint. It is universal, so it might even be called a generic definition. Acceptance criteria, conversely, are unique and specific to each user story, feature, or an issue. These are determined by the development team according to particular parameters that must be passed before the development process moves to the next level.
Action Plan: How to Create Your Actionable Definition of Done
1. Engage the entire team into the process
Making a DoD has to be merely a collaborative process and combine valuable input from product management, quality control, stakeholders, and development team, of course.
Let’s be frank, no one would follow the criteria they feel uncomfortable with. So, gather your teams and have an honest conversation about the requirements you see crucial. Explain to them why. Make sure there is no confusion or misunderstanding. The golden rule here – unless the code is working and nothing else breaks within the process, it can be considered “done”.
Migrate to secure hosting
Don't waste your time on Redmine maintenance. Hire experts and focus on your projects
2. Develop a DoD checklist
Be cautious: it is a common mistake to concentrate only on acceptance criteria during an ongoing sprint and forget about the bigger picture. The functional puzzle you are going to get is doomed not to be completed in the end.
To avoid this, create a usable checklist and make it an available part of your workflow. Throughout your project management tool, for example. With RedmineUP Checklists plugin, it will not take much time to create a highly customizable checklist for your DoD. Then you will be able to interact with it straight on the Agile board. What can be better than the set of criteria always at hand?
RedmineUP Solutions
Extend your Redmine functionality with our solutions and services
3. Stay clear and concise
While composing your list of done requirements, make sure that your wording is explicit and comprehensible and your criteria are sharp. Make it actionable. Do not obsess with criteria. Think of a DoD as the minimum required to ensure the product quality. Getting it done is way more important than getting it perfect.
4. Determine acceptance criteria for each increment
In the process of crafting your DoD, remember that each increment must meet specific acceptance criteria. Again, you may use Checklists from RedmineUP and add as many lists as necessary. No effort is needed to add, delete, or mark elements as “done” thanks to Ajax technology we are actively using.
Stick to only relevant information. It will come very in handy when your team starts ticking off the acceptance criteria that have been already met. Moreover, it will certainly help you track the whole progress.
Set the checklist to default on each issue. This way the team will always be reminded of the end result all the stakeholders are willing to get.
In our next video, you can learn how the RedmineUP Checklists plugin could be used as an integration into the Agile board.
5. Keep updating
Last but not least, remember the rule of a thumb: the well-crafted DoD grows with the product. So, review and update it from time to time. For example, during the Sprint Retrospective before the beginning of a new sprint.
Put your team on it. In the end, no one knows your product better than your colleagues.
Create your DoD Right Now with RedmineUP!
We will never tire of repeating that it is all about trust and collaboration. And a Definition of Done here is an indispensable element. Give the DoD a try with RedmineUP – grow your business with us!
RedmineUP Solutions
Extend your Redmine functionality with our solutions and services