I was a bit confused to determine column on the Kanban. Whether can be determined freely or are there separate rules? can we convert SDLC process to Kanban columns like Waterfall's (Planning, Defining, Designing, Testing, Deploy) to Kanban as a column (Backlog, Defining, Designing, Testing, Deploy)?

I have tried to find some sources but the results are different. David Book said, we need an existing process that can be convert to Kanban process. If it so, then what is the existing process for a new project?

2 Answers 2


In Kanban, the board is meant to visualize your process. By visualizing your process and tracking work through it, it is easier to spot your bottlenecks and challenges.

So, the direct answer to your question is: No, the columns are not set. Yes, you can use those SDLC titles IF that is how you currently work. Now, a word of warning, if that is a whole project that goes through that cycle, the board won't tell you much because things will move very slowly. Most groups find that they want to track discrete pieces of work (like features) through it.

A little extra info:

A lot of teams and organizations think they are using the Kanban methodology because they have a board. There's more to it than that (though not much). The Kanban methodology requires that each column has WIP limits which are respected. It also needs regular small, experimental improvements to the system, which in turn require some disciplined measurement of flow including lead time, cycle time, and throughput.

Finally, it you're struggling to build your board, I highly recommend looking at STATIK (Systems Thinking Approach to Implementing Kanban). There is a pretty solid blog post on how to do it here. I personally do this with any team I work with anymore.

  • 1
    You need an overall WIP limit as well. If you don't then you can have an infinite number of columns, and thus infinite WIP. (Once work is started, it is in progress) Commented Mar 30, 2019 at 9:29
  • 1
    You will want a WIP limit per person of about 3-tasks, and that is a limit, not a goal. You have to tune it. It will depend on your definition of WIP, it will depend on what you are doing. It will depend on where you are now. You should measure it, set it a little lower than it is now, and manage it downward. Commented Mar 31, 2019 at 10:01
  • 1
    You can apply kanban to waterfall, yes. The term product backlog comes from Scrum and applying kanban to waterfall will not give you a product backlog in that sense. It will simply visualize and allow you to measure flow of work through your waterfall project.
    – Daniel
    Commented Mar 31, 2019 at 15:23
  • 1
    WIP can be applied many places, including each step, an overall WIP, per-person, per class of service (to name a few). Technically, if you place WIP on each step, you have an overall WIP.
    – Daniel
    Commented Mar 31, 2019 at 20:04
  • 1
    As mentioned, we shouldn't be constantly filling those limits. I actually prefer a tighter limit. Smaller WIP almost always means faster response and better throughput (it is possible to over-limit your WIP, but I've never seen a team have this problem). If I have a team of 5, overall I'd like to see a WIP limit around 8 or so to start. At this limit no one is helping each other and 3 things are just sitting around started. Over time, I'd love to get to an overall limit lower than the total number of people because that means they are collaborating. Not a hard rule, just experience.
    – Daniel
    Commented Mar 31, 2019 at 20:06

As Daniel has said - Kanban says "Start from where you are" - meaning, start with your current process, don't change anything. Simply visualize it and then gradually change it as the team identifies the need for improvements.

If your current process is "Backlog, Defining, Designing, Testing, Deploy" - you can start with that and use it to track each Requirement (or User Story or feature - whatever you use currently at the lowest level of your "scope definition" - the actual deliverables for your team). You can't just have the whole Project (depicted as a card) going through that process - as Daniel said, then you won't see anything progress; NOR can you have your typical project plan tasks flow through that process. (Tasks simply follow a "To do - Doing - Done process).

The idea in Lean/ Kanban is to track the "value addition" stages of your workflow - and apply it to each piece of value you are delivering to your customer, which, in this case, is software pieces (features or requirements). Think about each step in your dev process that adds incremental value to the deliverable - even if it does not involve a handoff from one person to another.

As an example, here is our workflow that we use for our own product development - and we use a TDD approach -

enter image description here

It's a fairly elaborate process but tracks each value addition step as a developer works through them on a single user story or enhancement or defect, the 3 typical deliverables our developers work on. The color coding identifies the type of work.

You can start with the high-level flow that you provided - and you can quickly "evolve" to a more granular flow where each of the stages you identified will have some sub-stages.

Also, remember, that Kanban helps you even out and improve your flow by providing intermediate buffer columns so that each stage of your workflow has enough work and that work is flowing smoothly. This ensures that - ideally - at no point do your team members get over-burdened or become idle. You do this by adding intermediate "Done" columns (Design (In-progress/ Done), as an example) and adding WIP (Work-in-progress) Limits on each column. Here are a couple of examples -

enter image description here

To learn more about the Kanban Method, you can read David Anderson's "Kanban: Successful Evolutionary Change for your Technology Business" - which you already referred to. You will also find many useful articles in our Kanban Guide here.

To answer your other question - there is no "pre-defined" process. You and your team have to decide what process you will use - based on your current development experience and practices - on your new project as well. If you have been only doing waterfall projects so far, then you start by using the same process again. If you have been doing a Scrum or an Iterative process, start with that. Kanban will gradually help you improve and evolve as you identify problems with your software delivery if any, and any process bottlenecks.

Finally, I also agree with Daniel - you can use the STATIK method (Systems Thinking Approach To Implement Kanban) to identify your process and the kind of work you do - I also use it in my Kanban training classes. However, it is a somewhat advanced topic. I would suggest getting a Kanban trainer/ coach to help you with that initially.


  • Is there any naming convention about work item title like "we have to use 'repair payment bug' instead of 'repair payment'"? Commented Mar 31, 2019 at 6:57
  • 1
    There are no predefined naming conventions prescribed by Kanban - Kanban is very non-prescriptive that way. It really is up to you and the team what you want to call work item types, workflow stages, and so on. Commented Apr 2, 2019 at 6:17

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.