April 12, 2024


Kanban is a tool that aims to improve efficiency by reducing waste of time and doing things more efficiently. In this article, we’ll see a quick introduction to this tool, what it is, how to use it, and whether it can be applied (and how) to our work process. The views and knowledge expressed here are those from the perspective of a Software Engineer focused on backend development—not an expert in agile methodologies.

Getting started

No matter what business we’re in, we’re always finding ways to make things more efficiently. Lean methodologies were introduced with that purpose, and they were born in manufacturing environments but can be applied to almost any kind of business activity or process.

They can be seen as a set of tools that can be adapted or modified to any environment, according to the problem being solved.

One of these tools is Kanban.

What is Kanban?

In every business, there’s always a desired result that’s preceded by a series of steps or tasks. These steps or tasks almost always carry some form of result, let it be a document, a piece of information, or any other output that is also used as the input for another step or task.

Not having these results (and on time) can cause delays for the final customer and, consequently, lost in our business. On the flip side, having too many results (documents, deliverables, etc.) can become cumbersome to manage and can also have the same undesired effects.

This is where Kanban comes in: it helps us in learning and managing an optimal flow of work within the process.

Some basic rules to implement Kanban are:

  1. Visualize the workflow: A visual representation of the workflow lets us see how tasks move from being "not done" to "done right".

  2. Limit work in process/progress (WIP): Get more done by doing less (at the same time). There’s a limit in the tasks we can do at the same time, going beyond that limit will only decrease our productivity. This is the same principle we apply in programming: divide and conquer: we should decompose "bigger" tasks into smaller ones, and do them one at the time to get them done correctly. Kanban metrics allow us to find that "optimal" number of tasks.

  3. Measure and improve the flow: Improvements should always be a result of decisions made in an informed way. Kanban is no different. In order for us to improve those areas where we’re not being as productive as possible, we need to first measure the steps, tasks. How much is this task taking and why? How much did we take to release feature XYZ? How many hours did we spend in the analysis of feature ABC? Finding a good tool that allows us to measure our tasks/steps properly is very important to enhance our processes. Some examples are Kanbantool and Jira.

One good thing about Kanban is that we don’t have to change what we may already be doing in our business. We simply adapt the Kanban tool to our processes, to start measuring, adjusting and optimizing our tasks for maximum efficiency.

Put in another way: we use Kanban in our existing business to identify ways to improve our already existing processes; we don’t need to change our processes at once and "implement Kanban"—we don’t lose the good things we’re doing already.

Using Kanban

Can we apply it?

Whenever we consider using some new tool, framework, process, etc. we immediately think: can we apply this?, will it work for me?

It’s no different with Kanban. Can we apply it in the software development processes?

Yes. Many would agree with me. Many others would say "yes, but some Scrum-like methodology would fit better for my use case"—and that may be completely right as well. As always, the answer is "it depends".

Software development teams use Kanban to organize their work. That is, (roughly speaking,) defining a backlog of tasks, prioritizing them, doing some analysis work, "moving" them to "development", "review", "done", and the list goes on and on, as long as the teams see it fit.

That’s the interesting thing about it: it’s not a restrictive framework that dictates "what must be done", instead it offers guides on how things could improve, rather than specific actions, so it can be easily adopted by different businesses.

How could it help us?

Kanban should not be "enforced". As with any other tool, we must be able to identify pain points we have in our teams (or solo-team) and check if the tool can really help us.

For example, if we feel we’re always busy, and yet we can’t get anything done/completed. Or, if we feel the process, as a whole, is not as efficient as it could be. Or maybe we simply don’t have an answer to common questions like "where are we at now?", "when will task XYZ be completed?", "who’s working on feature ABC?", or "what should I work on now?".

In such cases, it may be worth taking some time and consider something like Kanban; something that could lead to improve our efficiency and remove waste of time and resources.

What changes are required to use Kanban?

Good news! There’s no need to overhaul the whole business practices in order for us to adopt Kanban. It provides the means to visualize what we’re already doing and which parts could be tweaked to be more efficient. On top of that, the changes required to make things better can be implemented gradually—no need to throw everything away and start from scratch!

How to get started with it?

Map the workflow

That’s the most challenging part of almost anything: getting started. Once we get that little first step, things start to turn smoother.

So it’s important to know how to take that first step.

One approach is to make something like a map or visual representation of our current workflow. This means identifying major processes in our organization/business, department, area, etc. It’s here where we also identify (mentioned in no particular order):

  • which are the steps/tasks we currently have in our process?

  • where are they coming from?

  • how are they defined, assigned and prioritized?

With answers to questions like this, we create one column for the Kanban board. So, for a software development team, we could have the following columns:

  • Backlog

  • Analysis

  • Design

  • Review

  • Development

  • Code Review

  • Testing

  • Release

  • Support

It’s after we do this step that we can identify improvements in our current workflow, so it’s normal if some of the things we’re doing are not as efficient as we’d like them to be. That’s expected: it’s from this point from where we start to see areas of improvements and form where we can start to enhance our flow; so it’s important to not try to "beatify" the current state of our processes: we need to see our flaws, so we can tackle them.

Also, at this point, it’s a good idea to define how many work in progress (WIP) we’re willing to keep. For example, a developer shouldn’t have more than one feature ticket in state "Development" at the same time; but probably a marketing specialist can handle three or more tickets with the goal to define different marketing strategies associated with different partners. These limits can then be changed gradually as the team monitors their speed and results in each of the steps.

Once we have our workflow steps defined, it’s time to draw those as columns in a board. It can be done in almost anything we want: a physical whiteboard, a table, a piece of paper, a corkboard, a Kanban board on Jira.

Visualize the work in progress

It’s time to visualize the work in progress the team is doing. It’s now when we start adding the tasks to the board and track how they move from one column (step) to another. Also, it’s a good idea to display for each task some meta-data such as creation date, deadline, priority, type, priority, description, notes, definition of "done", history and any other piece of data that helps in monitoring each task. It’s good to display on the board as well who’s working on each task, unless it’s a solo-team.

Nowadays, tools like Jira, make this part trivial, as its boards already bring all these fields really easy to be edited.

Set initial WIP limits

As mentioned before, it’s important to define some initials WIP limits. Sometimes this is challenging to do: how do we know the ideal amount of work in progress we can handle? But we must start somewhere, right?

Two approaches can be applied here:

  • Start with low limits and increase them later as the workflow is monitored: this one can be painful because we may feel tempted to take more work than the one permitted by the limits, but it usually gives better results.

  • Start intentionally with high limits and lower them later as the workflow is monitored: this one may have slower results, but it could easy the adoption within the team.

During this time, it’s good to involve the whole team in documenting the process and setting realistic WIP limits everyone is willing to enforce.

Why is it so important to respect the WIP limits?

By working on as many tasks as we can really handle has two major benefits:

  1. It reduces the time we take to get anything done (lead time)

  2. It improves quality by giving greater focus to fewer tasks

Once these limits have been defined, it’s good to somehow show them on the board for each of the columns. This helps in having a visual representation of how many tasks a given team member can be working on simultaneously. It’s also important to always keep an eye on everyone’s' current capacity and beware of anyone wanting to go beyond the limits. In such cases, the team could call a meeting to understand what’s the rationale behind it and discuss it further if needed.

Kanban is a "pull" system

The idea of Kanban is that each phase/column "pulls" the work from the previous stage/column, signaling the previous stage "to make another one" (terms from the manufacturing days). This is intentional: the idea is that each stage pulls new work only when it’s possible to complete it. This way, the WIP limits are enforced for each stage.

This mechanism is opposed to a "push system" where each stage would complete the work on it and would "push" it to the next stage, regardless of the workload there and without having in mind the WIP limits.

Put in another way: each team member takes (pull) new tasks only when they’re ready to do the work, and it becomes his/her responsibility until the task is completed for that stage. This doesn’t mean one person can’t complete the tasks associated to the same concept in different stages, quite the opposite. Sometimes it’s the same person who "moves" a task from one state (column/stage) to another, until it’s "done". Again, Kanban is very flexible, and it’s here to help us with our flow, not to put restrictions.


Once we have a visual representation of our process(es), ideally in a Kanban board, we can see at a glance where in the workflow each task is, and it’s really easy to spot bottlenecks early. When the WIP limits are set appropriately, we usually hit a limit as soon as a bottleneck starts to form. That’s why, in part, the power of Kanban comes from the fact that everyone can see when a problem (like bottleneck) is forming and take action early in the workflow, before more work is piled up and everyone needs to start jumping from task to task: this is when clarity is lost because of so many context switches.

Monitor the workflow and adapt

Kanban doesn’t force us to monitor, adapt or learn from mistakes; but it’s generally a good idea to do so. Otherwise, we’re not benefitting completely from having a well-defined process structure and WIP limits.

Two tools that are really useful for tracking improvements are lead time and cycle time. Lead time is basically the total time it takes to get something done from the moment someone asks for it until it’s completed. Cycle time is the amount of time spent on a work item by a person or a team up until it’s ready to be delivered.

It’s also generally a good idea for the team to review the metrics and reflect on what’s being done right and what could be improved. This is how, iteration after iteration, the team can reach a point of "optimal" flow in the process. The space and format of this is different for each team. Some things that I’ve seen work in the pass is to have regular meetings, let it be weekly, bi-weekly, or with any other schedule, where everyone is free to express their ideas and observation of how the workflow has changed since the last iteration.

Other considerations

Classes of services

Different tasks have different intrinsic value to customers, different risks, different priorities, etc. By defining "classes of services", policies, and "rules" associated with them, we can change the value that’s delivered and improve the overall workflow.

For example, in a software development team, there could be a class of service called "production bug", which would describe a ticket whose result impacts the customers and the organization directly. Because of this, resolving it is a top priority The following "rules" would apply:

  • it’s a top-priority task

  • it can break WIP limits

  • it can skip the steps: Design, Review, and Support

  • it can be released without a product owner approval

  • it has associated a label "deliver ASAP"

Class of service is a powerful tool that can be implemented and adapted in a variety of ways to optimize the value delivered by the team.

Can we use practices from other agile methodologies, like Scrum?

Yes, we can. Kanban doesn’t define what steps, rituals, meetings, or similar team practices are used in the team’s workflow. It is a tool to be used to improve our workflow, in general, but there’s no hard rule that stops us from experimenting and implementing other tools or framework that could also help us.

Final thoughts

After the processes are defined and Kanban is implemented, we must make sure the procedures are explicit. This way, we make sure everyone understands it as much as possible; and, in case there are doubts, they must be addressed as soon as possible to make sure the whole team is aligned.

This means, the established policies must be clear, specific, readily available and reviewed/revised regularly.

We must always keep in mind what’s the goal of implementing Kanban: to keep improving our processes through reflection, refinement, experimentation, and creating and managing metrics. Tools like Jira can help a lot in this sense.