Prioritizing your tasks is an excellent way to be more productive and finish your work in time, but how do you know when a task has been finished? There are different ways to determine with your team when a task can be considered as finished. But it is very difficult for some teams to define the right criteria to do it, sometimes they fall in the mistake where every member determines when they finished with their own criteria, making it more difficult to homogenize work.
In agile methodologies, and more specific, in Scrum, it's very common to find the concept of Definition of done or also known as DoD, that is the way the team can have a general idea about the concepts or the “must” that a task needs to have to define it as finished or to consider as user story completed. There are different approaches to make your DoD, but it is important to set up a definition of done in your team.
Definition of the definition of done:
Agile Alliance: The team agrees on, and displays, a list of criteria that must be met before a product increment “often a user story” is considered “done”.
Scrum. org: DoD is a shared understanding within the Scrum Team on what it takes to make your Product Increment releasable.
What do I need to determine my DoD?
To define correctly when something is considered finish:
One of the most common problems that you can find when you are trying to determine the DoD is that every member has different approaches to what is DoD. The “easiest” way to tackle this problem is through a general definition in your team. There is no correct way to define DoD, it must be determined based on your team and the way you are working with your team.
Define your own DoD needs consider which steps or a to-do list about what your team has to pass until you can release your product or until you can show your product to your customer. For example, if you are trying to deliver new code for your customer your to-do list could be like:
- Test the code
- Review the code
- Correct the bugs
- Document the code
- Upload the code
As you can see there are 5 tasks before you release the code, those 5 tasks can be 1 or 10, you decide. The principal point is that all the team knows those tasks to consider that their work has been finished and to avoid misunderstanding during the process. Try to define it the clearest and specific way you can, and also be sure that everyone knows about DoD and understand it correctly.
Be specific for areas:
If you feel that you can have different DoD in different teams is important that you define a DoD on every team, even more, if they have to pass for different parameters. It is important that if you have different teams working on the same project every team understands their part and the requirements that their area has. In the end, all the different parts need to fit in one solution, avoiding overlapping, or worst, that none of the teams work on their own tasks because they thought that they don’t have to.
Set up the right criteria:
Sometimes the people misunderstands the difference between the DoD and the right criteria. The right Criteria can change between user stories meanwhile DoD doesn't have to change (referring in an acceptable span, it is ok to refine your DoD). The right criteria are referred to as some specific points that a specific release has, in other words, parameters to certain tasks need to accomplish but it doesn't apply for all the user stories.
Ask your team
If you don't know how to start with your DoD, ask your team, in the end, they are the people doing the job a know better with are the right step to release a quality product and which practices enhance your performance.
DoD is excellent to increase transparency in your team. If your team understands which are the parameters and the necessary activities to work, work will be easier and all members can be aware of the missing tasks, increasing their communication to define their work.
Also if you are working with different teams for the same project be conscientious about the task the other teams have can improve the way they are performing, furthermore bringing transparency to our teams.
Sometimes your members can feel like they already finished their work and they can release the new feature, but when they noticing they have to test or review (for saying something) they are late for the incrementation, forcing to go back on work and finish the job after the set time, therefore wasting time due to reworking. Once you define a DoD with your team those problems will decrease and your team will work more in time avoiding rework.
Avoiding rework will increase the time saved during your team performance because there is no necessity to go back once your team has achieved the to-do list that you define for your DoD.
Also Prioritizing your work and have a well structured DoD help your team to start work in the valuable things that the incrementation needs, instead of just working in something your term will work with purpose and more focused on the customer necessities, and even more important: achieving a valuable release.
There isn't a settled way to define your DoD, you can define it based on your necessities and refine it every time you feel is necessary. The main point in defining your DoD is that all your team have a clear idea about what DoD means and have a shared approach where every member can help and finish your work on time.