Carrying Out Work

Definition of done

Any rework in a software development process is an overhead that adversely affects the cost of delivered programs, customer satisfaction (due to unforeseen delays), quality (due to squeezed deadlines), the organization’s overall performance, and reputation. To avert these outcomes, you should avoid rework at all times.

Let us look at typical development situations that cause rework:

• A developer needs to stop working on the current story and go back to the previous story’s code because the QA team just reported a bug in it. This situation creates context switching, which delays the delivery of both features.

• A developer needs to rewrite part of the code that did not pass code review. This scenario uncovers unnecessary spent time on a program that had to be changed later on.

We may not be able to predict such scenarios before they ever happen, but it is straightforward to avoid them after we have encountered them at least once.

Therefore, learn frictions that cause rework in a team and systematically brainstorm how to avoid them in the future. Mitigate adverse outcomes by planning actions ahead of time that help prevent issues. Compile a list of activities that need to happen before starting to work on the next iteration, milestone, or significant chunk of work. These repeatable actions are usually called Definition of Done (DoD). Follow DoD in every iteration or milestone. Before you call it “done,” each requirement needs to meet the criteria of DoD; until then, it is NOT done. Track rework to ensure that DoD helped, and if not, refine DoD until it becomes useful for a given team.