One of the things that I'm still trying to wrap my head around is defect tracking.

Should we put defects on the Board and track them alongside the other items (new features, refactoring work etc), or should we track them as issues (issues are tracked separately and they show up on the board only when they are blocking something)?

Reason why their existence on the board gives me trouble is that they are variable in size. In majority of cases, such issues are an order of magnitude smaller than the other work that's on the board.

Because of that, I was thinking about two options:

  1. Introduce a separate swim lane for bugs only. In the beginning, we would like to keep it as wide as possible to force the team to go through existing issues faster (mostly edge cases and minor issues that piled up with time), and than make it narrower when we go through them. By keeping a dedicated swim lane for bugs even when there are no pressing production issues (which are always handled as expedited items), we will ensure that edge cases and minor bugs get cleaned instead of letting them pile up.
  2. Track them as issues in an issue tracking system and fix them the same way as we did. Risk here is that edge cases and minor issues would pile up, because such issues never get priority.

Should defects flow through the Kanban board, or should they be tracked as issues?

  • Related question focused on Pivotal Tracker: pm.stackexchange.com/questions/8809/….
    – Todd A. Jacobs
    Commented Jul 10, 2013 at 15:05
  • Using swimlane is pretty nice idea but how we can make it on Jira? I thought about using swimlane based on story and make on bug story for bugs and then put an every single bug within this story. However, it will affect reports (this story is kind of neverending story), so better idea is to use epic link or type of task and then make appropriate JQL query in swimline configuration. What do you think? :-)
    – user27143
    Commented Jan 8, 2017 at 10:26

4 Answers 4


My opinion is that you have a very good approach at hand by creating separate swim lane for bugs/issues on the same wall/board. Visibility is the main reason why I am inclined towards this approach.

Having two separate systems to manage your to-do list is not going to give you a complete picture of the current status. Visualizing the flow of work and making it visible is one of the core practice of Kanban. When the team sees too many issues along side regular work items, they will get concerned and will decide on capacity distribution to handle both types of work (regular and issues).

Issues requiring smaller magnitude of effort as compared to the regular work items should not be a big concern as multiple smaller issues can be bunched together (if required) and handled in a group.

  • Thanks. I completely agree that visibility is important, so we'll implement a separate swim lane for defects and see how it works for the team.
    – Ilija
    Commented Jul 11, 2013 at 11:00
  • @Ilija it would be helpful for many of us to hear back from you if it worked for the team or not. Commented Jul 11, 2013 at 11:04
  • I'll post back later, if we get to any useful conclusions. Having a wider swim lane and than narrowing it down, and than seeing how everything worked out will take time I guess…
    – Ilija
    Commented Jul 11, 2013 at 11:08

We use a different color of token to represent bugs.

That gives us a quicker way of looking at what proportion of the current work is for features vs. bugs (and same for the backlog of items).

We also have the separate swimlane as others have suggested. But if we come across a bug that is related to a feature that we are working on, we put the bug in that feature's swimlane, and the feature isn't considered done until the bug is fixed.

Besides that, I wholeheartedly agree with Aziz that visibility is the key, and that your approach with having a separate swimlane for bugs/defects is a good way to approach it in general.



The core consideration is whether defects affect team capacity in other areas. If so, then you need to represent them somehow on the main kanban. If not, you should definitely evaluate whether they are truly part of the same fundamental process.

Work-Flow Assumptions

In general, on-going or operational support should be part of a different process than development. This is not always the case, and may certainly not be true in your organization. Nevertheless, it is worth considering whether these issues should be part of your current process or not.

Kanban and Queues

Kanban often works best when batch sizes are somewhat standardized. @Zolt has a blog entry on optimal batch sizes that provides some technical detail on this key issue. However, the Kanban process can certainly handle variation in the size of user stories, both through adjustments to WIP limits and in queue management.

If your defects are handled by the same team that handles features or product development, then your team capacity remains the same regardless of the type of stories being queued. Throughput and cycle time of defects may be different, but they still require resources from your team, and will therefore impact your overall team capacity. In other words, don't ignore or discount these user stories unless they are performed by a different team or within a separate process.

Note, however, that there is no requirement that defects enter the same queue as other types of work. It is certainly worth evaluating the addition of a separate queue (or queues) for defects, bugs, and other issues to enable differentiation in the prioritization and pull processes.

Some Possible Solutions

Because Kanban is fundamentally a pull-queue framework, you have some options in how you organize your queues and how you determine when work should be pulled from a given queue into an in-progress state. Some options include:

  1. Having swim lanes dedicated to the alternate queues.

    Note that this works best when your in-progress sub-queues (columns, if you prefer) are fundamentally the same as the stages for your other stories.

  2. Having columns dedicated to certain types of stories.

    The benefit of having optional columns, or having user stories that may skip columns that are not relevant, may be outweighed by the added complexity or cognitive load needed to track flow on the kanban. This should be carefully evaluated by the entire team.

  3. Having different team members pull from different queues.

    This somewhat violates the principle of collective ownership that agile methodologies promote, but is certainly in line with the core pull principles around which Kanban is based. If your team is organized in such a way that different people have non-overlapping core responsibilities, rather than being fully cross-functional, this may be a useful work-flow.

  4. Adjust WIP limits.

    If defects generally have a faster cycle time than other types of work, it may make sense to increase your WIP limits to account for the increased throughput you expect of the team. Alternatively, you can have separate WIP limits for different swim lanes or columns. This may greatly increase the complexity of the kanban, and makes at-a-glance assessment of the board more difficult, but it is certainly an option worth considering.

There really isn't a single right answer to the issue you describe, nor is the list above meant to be exhaustively canonical. Nevertheless, the point is that the Kanban framework is flexible enough to address this type of issue in a variety of ways.

  • The question is based on an assumption that the same team is building new features, as well as fixes any issues that are discovered with production system. We don't have a dedicated team for defect fixing, nor we have a separate pipeline for that type of work.
    – Ilija
    Commented Jul 14, 2013 at 9:15

There are two kinds of defects; the first are errors which occur whilst still building the requirement and before it is accepted as Done by the Product Owner. In this case the error is simply communicated, perhaps another task created. You see the original requirement is not done yet, thus simply do it. Do not raise defects or bugs for this, as this is normal behaviour in product development.

The next is when a defect is found after the team and PO have reviewed the work and accepted it as done. When an issue is found, this should be added to the product backlog as a defect/bug.

The PO then schedules this defect/bug as with any other Product Backlog Item; the reason some bugs are critical and others are purely cosmetic. A defect has a value to fix and it's the PO's responsibility to order the defects amongst other work.

Estimation of Defects I coach not to put story points against defects as the defect is a result of some weak practice; the team should not be rewarded with points for this. When assigning points, one creates and artificial velocity and not the teams real rate of work to get stories done without defects. I.e. a story that was estimated at 10, still remains a 10 even if defects are found. It should not suddenly grow to 12, because of a defect. The argument here is the defect should not have occurred in the first place.

Simply timebox defects; e.g. easy defects are given 1 hour and harder ones a day. At the end of the timebox; inspect and if not complete give another timebox. The idea here is not to let defect fixing carry on for days without reviewing and inspecting the defect; sadly some developers go down the wrong path in fixing a defect and this should be avoided.


  • Issues with WIP, simply deal with them as tasks and not as defects
  • Defects are logged once PBI accepted as done. Treat as any other PBI, but timebox the estimation.
  • Points are not rewards. They are a measure of estimated effort, or a gauge of team capacity.
    – Todd A. Jacobs
    Commented Jul 15, 2013 at 15:23
  • They are definitely not a reward; however they original effort should not keep increasing as it was not done properly in the first place. Points simply quantify the unit-of-work and not purely based on "effort". You may use it as capacity gauge, but if you are doing some form of release planning; velocity becomes a critical factor in determining the teams rate of work to get to "done" Commented Jul 18, 2013 at 4:00
  • e.g. A team has weak quality control and introduces many defects, when these found they are added to the backlog. If sized, the total size increases only for the known defects. However if done without size, overall velocity decreases and the trend in rate of work will factor in the lower quality standards. This trend then is applied to future work and the likelihood of future defects. Commented Jul 18, 2013 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.