Agile and Scrum are not alien to us anymore. The Software Industry has embraced Scrum and Agile because of the value they provide. People have used Scrum in many ways and have modified it to suit their unique needs and project requirement. It is not rare to see task boards with many variants of columns, with stretched tasks, defects, burn down charts and so on. If you are not familiar with how requirements are managed in Agile / Scrum world, you might find this article on User Stories interesting.
To summarize, in the Agile methodology typically requirements are managed in the form of user stories in the product backlog. During sprint planning meeting, product owner gives a list of user stories that are important for the current sprint along with their condition of satisfactions. The team then breaks this story into small tasks and gives their estimated time to finish them.
These tasks are posted on the task board along with the user stories and team moves them on the task board. Typically any given task can move in four stages, not started, in progress, blocked, and done. Tasks are treated as ‘done’ when developers have finished their coding and testers have finished testing it.
Often teams are not clear on what is the meaning of ‘Done’ and when should any task be treated as ‘Done.’ Different people interpret ‘Done ’ in different ways according to the roles they play in Scrum. For example, a developer might say that the task is done if it is working on their machine, a tester will treat the task as done if it is in a state where it is testable, scrum master might say it is done when it is out from the backlog and so on. Since people have different meanings of done, tasks are done, but there could be some conditions under which it is not done, probably there is some scope for design/code improvements, documentation and so on.
As a result of this, management and customer get a false sense of velocity. They think that features are done and are ready for production, but in reality, they are done with some caveat. They are done, but there is some technical debt associated with them. Features are done, but they are partially tested, hardly documented, rarely optimized and are not ready for release.
One very simple solution to this problem could be to define the definition of done explicitly and clearly so that everyone knows what is the meaning of done. This explicit definition of done will also gives a chance to the product owners to see if they want to do something more before treating tasks as done. One example of done could be “ Task is done when it is implemented, unit tested, the code is reviewed, integrated, tested across supported platforms and is release ready.”
Once the whole team agrees the definition of done, it can be implemented in the form of either checklist or individual items like unit testing, code review, integration, etc. can be treated as separate tasks and can be attached to every story.
Adherence to the definition of done should be the responsibility of the whole team. Every time a task is moved from in progress to done, the team should ensure that it is not only working on developer’s machine but is done according to the agreed definition of done.
Once we have this definition in place, the team will be a bit closer to their final goal of producing top quality re-factored code which can be deployed anytime with confidence.