Stuart Bargon — an expert in the field of agile methodologies — told us that the processes of KANBAN are even simpler than SCRUM.
The first step is to map the workflow of your development team. Stuart drew a number of columns on the board:

Scheduled

In development

Ready for QA

In QA

Ready for deployment

Deployed (Done)

You then set limits on the columns, determining the number of cards (tasks or issues) that can exist in a column at the same time. For example, the above set of columns might have these limits: 4, 2, 1, 3, 3.

A good guide for setting the limits on the number of cards is the team size. For example, if you have 10 team members, the total number of limits across all the columns should add up to 10.

The idea is that anyone can write a story and put it on the board. You can reorder the items in the “Scheduled” column.

A developer takes the top card from the schedule and puts it into the next column (“In development”). When development is finished, the card moves into the next column (“Ready for QA”).

If a card cannot move into the next column because this column is already full, that means that the person who wants to move it must first tackle one of the cards in the column that is blocking the flow.
In this way, the work flows through to the last column.

Nothing has any value until it’s in the last column. There’s no value in the whole process unless it’s producing a number of cards in the “Done” column.