Kanban Fundamentals

New to Kanban? We can help. The resources on this page are designed to guide you through the core principles of this methodology without hours of research. Walk your way through the sections below for a comprehensive overview of Kanban’s ins and outs.

What is Kanban?

For one, Kanban is NOT an Agile tool, framework or methodology—in fact it’s not even derived from software development practices. Instead, Kanban came out of lean manufacturing techniques made famous by Japanese automakers who used it to manage their workloads. Since the concept has expanded outside that industry, Kanban has become a popular workflow method software teams and businesses employ to work through projects of any size.

To find out more about Kanban and how it integrates with Scrum, watch our Kanban in Under Five Minutes video below.

Continue reading to learn more, as well as how this all integrates with Scrum.

Implementing Kanban

The process of implementing anything must be broken down into logical steps, which we’ll call a workflow.

  • Each workflow step has two parts; 1) a queue and 2) an in-progress step.
  • Each step, including the queue steps, are limited in the number of work items they can hold as determined by the team in charge of that step.
  • Work is pushed into the queue step by the preceding step and pulled In-Progress by the following step.
  • If one step reaches its limit, then any preceding steps must also halt, as they have reached their limit until the bottleneck is cleared.

As you can see, there’s nothing inherently un-agile about Kanban. It codifies common sense: don’t try to do everything at once.

Now, introducing Kanban isn’t as simple as just emailing these five bullet points to the team and telling them to “go get it!” You need to know what your development workflow looks like and you will typically want some visual way of communicating the workflow to the team. In fact, the word Kanban literally means “signboard” in Japanese.

Here’s what a Kanban board might look like:

kanban board

Axosoft Kanban Board

Each one of the cards represents a work item. It doesn’t matter if the work item is a task or a user story as long as it’s consistent.

Notice the columns we’ve laid out? That’s our workflow. Also, take note of how ridiculously simple it is. We’ve got a place for a product owner to groom the product backlog with the Waiting for Approval and the Approved columns. Anything that’s Approved is ready for the team to pick up and put into development.

That part is important. As a non-developer, I don’t push work from Approved to Development. That wouldn’t reflect reality since that developer can’t actually start it until he’s done with his current work. Instead, when that developer is done with his current work item, he’ll reach into the Approved column and pull the next work item into the Approved workflow step.

That difference between push and pull may seem like a subtle impact, but it makes a big difference. Here’s how:

  • No waiting period between tasks: Since a developer doesn’t have to check with or wait for a manager to give him the next task, he can smoothly transition without delay as he becomes available.
  • Significantly less time spent shuffling resources: A manager attempting to schedule every team member’s tasks along a timeline will always encounter impediments making dates line up. Estimates are imperfect. Scope is ever-changing. If a team member is taking on work as he/she becomes available, there’s typically much less administrative overhead involved.
  • Less time wasted switching tasks: Since developers now pull work onto their plate rather than getting it pushed to them, it’s impossible for a single sane person to get overloaded. This means less time switching from task to task, which translates into less wasted time.

Combine Scrum and Kanban


Scrum is a great tool for managing how you deliver new functionality. It’s fantastic for getting your feet wet in the world of agile. However, there are some parts that are left out of Scrum, and believe it or not this is done on purpose. Scrum isn’t a methodology per se—It’s an open framework that empowers you to redefine how you apply it. Kanban, however, is a complementary framework with rules in place that might help teams fill in some of those gaps.

Scrum doesn’t prescribe a specific way for day-to-day tasks to be tackled. However, it does work best in an environment where individual team members can organize their own workload rather than being scheduled by somebody else. This is probably the biggest reason why agile coaches get bent out of shape when you compare Scrum Masters with Project Managers.

Therein lies a problem. If nobody is specifically responsible for managing a team’s day to day workload, then how does it get done? Well, you’d be surprised what a bunch of smart people (your developers) can accomplish when given free reign, but if they need a little bit of help or if you’re having trouble letting go of that control, you’d be hard-pressed to do better than introducing Kanban to your team.

Scrum provides the structure for organizing feedback, short-term planning, stack ranking, an inspect-and-adapt mindset, and other organizational improvements. Kanban provides a steady flow of tasks that reach 100% completion by helping your team manage day-to-day development with a minimum of overhead and blocking issues.