Kanban in Plain English?

Written by: S. Pradono Suryodiningrat

Like Scrum, Kanban is just a framework for implementing Agile software development, except it’s not as strict as Scrum in terms of meetings and times. You may have actually seen what’s referred to as a Kanban board before. It’s just a bunch of columns with cards on it that you can move from one column to the other one to reflect a state of that item, like to do, in progress, and then done. However, just because something has a Kanban style board does not mean that that is the Kanban process. Instead, the key concepts with Kanban are that it does not use sprints. So, you don’t time box the work of your team into these two- or four-week periods.

Also, since there’s no sprints, there’s no sprint backlog, which we’ll learn about, but only the product backlog itself. What happens is the team just works on their tickets, they do the work, they move it to done and then they take the next task off the top of the product backlog. And that backlog just goes on forever, it’s just endless.

Kanban is also different from Scrum in that it does not prescribe any particular meeting types like Scrum does with standup meetings, and sprint planning meetings, and retrospective meetings. And there’s one more big difference, Kanban operates off of the theory that only a certain number of items can be in progress or in any given state at one time. How many items can be in each particular state is up for you and your team to decide.

Some software teams use Kanban, but it tends to work best with teams that are not very concerned with things like estimation and are continuously moving tasks through the same number of steps pretty quickly until they’re complete. For instance, customer service teams often use a Kanban style of working.

So, which one is best?

Sorry to disappoint you, but there’s no definitive answer here as it depends on what your team prefers to use. The best process is the one that you like using. As you can tell, Kanban is a more relaxed way of doing Agile development, but it has a big disadvantage since it doesn’t use sprints. It’s going to be more difficult to project the amount of time it’s going to take to complete work.

Let’s recap. Kanban is just another way to implement an Agile type of software development workflow. It’s a little less prescriptive than Scrum and it does not use sprints.

So, which one do you prefer?

S. Pradono Suryodiningrat