Kanban Board Flow and Columns' Relationships [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this questio开发者_StackOverflown

Given the basic flow on a Kanban board:

| Backlog | Dev | QA | Deploy |

After reading books/articles/presentations it got transformed roughly into

Business  -> | Backlog | Input |     Development    |         QA         | Deployment | Closed |
Marketing -> |         | Queue |--------------------|--------------------|    Queue   |        |
Other   ->   |         |       | Queue | WIP | Done | Queue | WIP | Done |            |        |

So the questions I can't figure out:

Backlog & Input Queue & Dev Queue relationship. PM prioritises MMFs from the Backlog for that release and moves them into the Input Queue, dev (based on WIP limit) takes one and starts working on it (WIP column). What's Dev Queue used for? Should it be PM moving things from Backlog to Dev Queue and dev move them to Dev WIP or should PM move things from Backlog to Input Queue and dev takes one and moves it to Dev WIP? I can't see why Kanban examples talk about having Backlog, Input Queue and Dev sub-Queue, does each have its own purpose?
Where does dev move completed/resolved work items and what is the relationship between Done and next Queue columns? What if QA is not required? For example when Dev WIP is complete you can move it to Dev Done and QA will pull it from there into QA WIP. Or from Dev WIP to either QA Queue or to Deploy Queue (when QA not required). In the first case QAer needs to understand and go through every ticket in Dev Done column even if description is too technical or too vague. In second Dev Done is bypassed and QA loses the control/oversight of what goes into deployment. Also, should there be a Deployment Queue or Closed? Thanks to CI, deployment is one click, but going through every dev tasks and matching the revision number to the one that just got deployed before moving it to Closed sounds like a burden...

Any ideas? Or maybe you know of good detailed examples of Kanban boards and their flow setup from the real world? I know I'm supposed to map out the real existing flow and evolve/improve it over time (Kaizen as a reaction to appearing bottlenecks/problems), but in case of a new team/project what would be the perfect flow?

Keep it simple. IMHO your implementation is too complicated. I read your post three times, and still not understand everything ;) Check the following web pages.

http://www.limitedwipsociety.org/2009/11/16/kanban-example/

http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

The ideal board is project/team-dependent so there's no single answer, even for a new project. Discuss the process with your team, start simple, review periodically. But mine is described in my post Kanban in a nutshell.

You don't need both "Done" and "Queue" columns unless your process dictates some kind of handover. As for who moves the items between columns, aim for "pull" not "push".

There is no perfect flow... If you have an existing team, start from the present process. Keep it simple, be pragmatic, both with an existing team and a new team.

We use "done" subcolumns in a couple of places with a common WIP limit for the working and the done subcolumns. This way we both enable pull behaviour and limit WIP for the whole step.

A typical use of a queue is in front of a bottleneck, to optimize flow. Non-bottlenecks should use slack to learn and improve, but a bottleneck (if you can identify it) limits the performance of the whole team.

Regarding the final "done" column I would be pragmatic regarding tickets. I would, however, be more specific on the board regarding column names. Does "closed" mean in production, or on your testserver? Just put that in the column name.

Your two questions are actually the same. The short answer is that the dev queue and the input queue should be the same thing, i.e. you need one or the other, but not both. The same for dev done and qa queue, they are the same. The point of the queue or the upstream done column is to indicate to the downstream phase that there is work waiting to be done. These columns are also used to enforce wip limits.

My advice is, even on a new project, map it the way the team currently works, and use Kaizen from there. The whole point of Kanban (and Scrum) is not to tell you how to work, but to make things visible and explicit so you yourself can find the problems and change your system or process. Its works on empirical data, which means that you don't necessarily know beforehand the direction you should be taking. Kanban as a tool/technique exists to point you in that direction through trial and error, and making things visible.

Backlog & Input Queue & Dev Queue relationship. PM prioritises MMFs from the Backlog for that release and moves them into the Input Queue, dev (based on WIP limit) takes one and starts working on it (WIP column). What's Dev Queue is used for?

I don't know, you transformed the initial basic flow into something complicated :) Maybe you should post the references you used. But from my point of view, they seem redundant (maybe they are not in another context but I don't feel the need for them).

Where does dev move completed/resolved work items and what is the relationship between Done and next Queue columns?

If a WIP item is Dev-Done, I thought that QA was supposed to pull it to QA-WIP. I don't understand all these queue. So same answer as above, they seem redundant to me.

Any ideas?

Not really but I would simplify things (actually, almost fall back to your basic flow), I don't see the point of making them much more complicated than what I described in this previous answer. Ok, this answer was about a Scrum board and not pure Kanban but it would also work if you remove the iterations.

Or maybe you know of good detailed examples of Kanban boards and their flow setup from real world?

Have a look at Kanban vs Scrum, One day in Kanban Land and Kanban and Scrum - a practical guide from Henrik Kniberg. Great stuff.

(...) but in a cease of a new team/project what would be the perfect flow?

There is no perfect flow, our team perfect flow is not yours. But all the above links will give you some ideas. But keep it simple, it doesn't have to be overcomplicated.

"Ready" queues (those that you call "Input Queues") are for push flow. "Done" queues (output) are for pull flows.

Most systems have both push and pull. Push will happen where there are different organizational semantics between work steps. For example, the movement of work items between a product backlog and the input queue for the team is usually a push movement. Work may be then pulled from the input queue.

It's rare that you'll have a single work step that will have both an input and an output queue.