This is a guest post by Nishi Grover Garg.
The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?
It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Here’s how to go about it.
Brainstorm with your team
The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.
For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.
By doing this exercise you are baselining your expectations from each task, independent of its owners.
Consider quality goals
If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.
For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.
So, to overcome this, you can add a subtask for each development task regarding performing basic integration tests. You can also add a code review task so that every developer now has to get their code reviewed by a buddy, even if informally, before checking it into the repository.
Creating these tasks adds an agreement with each developer to perform these tasks and not shirk out in a time crunch.
Ensure visibility
Whatever definition of “done” you agree on with your team, it is important that all team members are fully aware of the criteria and always see those tasks progressing.
You can create all the definitions of done as a checklist and put it up on the wall. You could also add the definitions as part of the team’s tasks on your task board. For a virtual task board, you could have them added as subtasks within the team’s tasks. You could also mandate a discussion about each subtask during your daily standup meetings, before moving an item forward on the physical task board.
Whatever your choice, having clear visibility not only keeps the team members accountable to do all that is needed, but also gives them the needed time. They may have deadline situations where they feel pressured to move things along, but they know that these subtasks need to be completed before moving along. This can help team members to negotiate more time when needed to avoid compromising on quality.
Follow through
Once you decide on your definition of done and set up the process with your team, it is important to follow through. Keep a continuous check on the progress of tasks and if their subtasks are being completed. Keep conversations going about each of these quality tasks and their importance throughout the sprint, and see that nothing moves ahead without having all related subtasks completed too.
If there is a setback, take it as a failure but do not let it slide. Any incomplete subtask means its parent task is not closed, so any user story that has an incomplete task is deemed incomplete in the sprint and spills over to the next one. We follow this rule in our teams — and trust me, it hurts us on a personal level when we see the entire sprint losing its velocity over something small like a test review task not being completed.
Over time, the team understands the benefit of getting things done in this flow and gets better at them. With practice and adherence to the definitions of done, your team will become the champion of quality.
Nishi is a corporate trainer, an agile enthusiast, and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
