1

My development team splits there time between two completely distinct pieces of work.

  1. New functionality user stories
  2. Bugs which relate to a completely different product (1 day a week)

Typically they work with their Kanban board until they have a day where they fix bugs (2). These bugs are brought onto their main Kanban board and then they work just for 1 day on these after that they stop picking up new work but they do finish any tickets picked up.

The problem is that this dominates their WIP the next day if they are still finishing things off or of the Product Owner needs changes.

Should I have 2 Kanban boards, a swim lane or should I just adjust the WIP limits accordingly?

2

You only want one Kanban board. You can be pulling from two Backlogs for your work, they still go into a single Kanban board.

The Task Board, be it Scrum or Kanban or other, is the prioritized representation of the work the team has to do. If you have two boards, how do you rank the #1 item on both boards?

  • I hear what you are saying but the team literally drops tools of normal project work and start bug work on that day – TheLearner Mar 22 '16 at 16:16
  • 3
    That's where I'd focus my attention. Is there a reason you only fix bugs on a single day? It breaks the purpose and flow of Kanban to maintain two boards. I'd more look to see how you could instead work bugs into your normal priority work and do them as they come to the top of the backlog, not have a day for bugs. I've personally experienced an org that tried 2Wk Feature Sprint, 1 Wk bug sprint and it was a complete mess. Once I abolished this, things went much better for bugs and features. – Joel Bancroft-Connors Mar 22 '16 at 17:26
3

You have a deeper problem, that you are using 1 day a week to fix bugs. Kanban is about continuous flow. The team should be able to take in bugs and story work at the same time and your stakeholders should agree on what the priority of work is regardless of what day of the week it is. It sounds to me like the 1 day rule is a crutch that is preventing your stakeholders from learning how to negotiate priorities.

If you find the team consistently having bug work carry over the 1 day boundary, the team should be retrospecting on why and figuring out how to improve their process so that it better serves all the stakeholders on the team. Your WIP limit shouldn't change, if anything it might help to lower it if the team is struggling to have a cycle time of 1 day on defect cards. Or you need to be realistic and acknowledge that a 1 day cycle time is not the right thing to aim for.

The team should not be dropping work. Part of setting WIP limits and having the team stick to them is the discipline of getting something done done before moving to the next item. With all my kanban teams I strongly encourage team members to only move cards forwards once they are in progress. Cards that get blocked or are tempting for the team to move back to ready sit in-progress and hog up the team WIP limits. The team needs to have the discipline to work through their bottlenecks/blockers and achieve flow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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