Accounting for bugs and rework

Comments (11)

Print This Post Print This Post

Email This Post Email This Post

Permalink

How do you handle bugs and rework in a software development kanban system?

One way or another, buggy work-in-process is still in process and counts against the total WIP limit. The only question is which part of the workflow gets stuck with a kanban token for rework.

Bug scenario

Here we have a two-stage work package decomposition. Green tickets represent a “requirement” work item. These could be something like Use Cases, they could be Functional Requirements,… What matters is that they are something that represents customer value and that seems like a “thing” to analysts, UI designers, testers, and the like.

These are decomposed into smaller work items for developers. Each yellow ticket represents a “feature,” in the spirit of FDD. Each feature will be designed, reviewed, coded, tested, reviewed, and integrated into a development branch. When all of a requirement’s features are complete, they will be rolled back up for review between analysis, testing, and development, merged into the test branch, and approved for functional verification and validation.

We should expect that bugs will be found from time to time, though we hope that this happens with decreasing frequency as a team matures. In this example, we have two requirements in testing, and they have found three bugs so far (blue tickets).

The question is: what do we do with these bugs, now that we have found them? Let’s consider two options: 1) Reinsert defective WIP into an upstream station, 2) Assign bugs to a shared rework station. Each case has pros and cons, which depend on circumstances, like process maturity.

Option 1: reinsert defective WIP upstream

In this scenario, we’ve taken the kanban for work item R5 out of the Test station and placed it back in Development, where it’s treated like any other requirement work item. When it’s done, it will be placed back in the Resolved:Ready queue and retested. It will be subject to all of the usual limits and rules along the way. The kanban is charged to Development, and Test is free to pick up the next thing that appears in their Ready queue.

This is the softer approach. It’s less disruptive and it treats bugs with less urgency. A downside of treating rework like a regular work item is that if Development capacity is full, then the buggy work item will have to be placed in a queue to wait its turn.

The attitude here is that bugs are an expected common cause variation.

Option 2: shared rework station

In this scenario, we’re leaving the kanbans for work items R4 and R5 in test and moving the bug kanbans to a special rework station. Test may continue to work on R4 and R5 while the rework is done, but since they are at capacity, they can’t pull in any new work. That means that the bugs have to be treated like an expedited request. Otherwise, the system will stall until they are resolved.

This is the harder approach. It treats the bugs like a process failure that must be attended to immediately. The kanban is still allocated to the Test station, and the Rework station does not count against the Development limit. Since the rework station is dedicated, there’s no waiting for a slot to open up in development. Regardless, development capacity will be reduced because people will have to give priority to the bugs in order to make space to resolve the regularly scheduled work items.

The attitude here is that bugs are a special cause variation and call for corrective action. This might be the right configuration if a team or project is new, or the team is having an acute quality problem. Once they get the problem under control, they can relax to the reinsertion model.