Agile Project Management With Kanban 

 October 24, 2020

By  Dave Litten

Agile Project Management With Kanban


The Kanban system is built for smooth and continuous delivery of customer value by carefully controlling the flow and quality of work while uncovering and resolve issues immediately.

The Kanban Board limits the work in progress, and uses small batches, so that the timeframe between specification, implementation, and validation can be done in just days.

The Kanban Project

Kanban methodology is a straightforward project-management technique based on Toyota’s just-in-time scheduling mechanism. Using Kanban to help manage our projects will allow us to focus all our time and energy on delivering value to our customers.

Kanban is simple in structure and uses common terminology. People find it very easy to pick up and to get proficient within just a few weeks of its application.

The traditional way to carry out product development is by using the waterfall or predictive method of project management. In traditional Waterfall, features might not be validated until months after implementation.

Agile Project Management With Kanban

These days, product development needs to be carried out more swiftly and so using a form of lean or agile is the way to go. Kanban agile is the solution.

Customer involvement within waterfall teams normally happens within performing planning and key milestone points, whereas Kanban agile engages with customers on a regular basis taking the opportunity to demonstrate prototypes and get swift customer feedback.

Waterfall Lifecycle Problems

Consider typical situations that occur when using upfront predictive planning types of project …

Significant time is spent on Meetings about planning and process while issues go unchecked often for weeks or months.

The specialist team is measured against the speed of delivery rather than fully functioning products or services.

Little initial quality checking can result in a lot of rework.

As requirements change and project work is reprioritized even more time is spent in meetings while existing completed work is either wasted all needs to be reworked.

The result of all this is the products are delivered late and over budget with less functionality and lower quality.
The advantages of using Kanban

Kanban only uses meetings when requested and does not use them for discussions about process. The Kanban board identifies workflow, bottlenecks and highlights the areas where issues arise.

Kanban Board Agile User Stories

User stories replace project requirements and are in a format used to gather end-customer requirements, they are small enough to be brought into the sprint and broken down into tasks:
Here is an example:

Agile Project Management With Kanban

Kanban Product Backlog

The backlog is the ordered list of all the work, presented in story form, for a team. It is composed of backlog items – most of which are features – items of functionality that will have tangible value to the user or customer

Not all items in a backlog will be at the same level of detail

Agile Project Management With Kanban

The product backlog is constantly emerging over time as new items are added, and existing items refined, the product owner will balance and reprioritize those items

Kanban Backlog Grooming

This consists of creating, refining, adding details, estimating and re-prioritising.

The Product Backlog is constantly groomed. User stories are reprioritized, re-estimated, new stories may be inserted, old stories may be trashed, and stories may be broken down into several smaller stories.

Agile Project Management With Kanban

The Kanban vs Scrum Framework

If you are familiar with the scrum approach to agile, then you will know this consists of a series of sprints lasting no more than four weeks in duration.

Sprints are fed from the prioritized product backlog, where the most important user stories are selected for the next Sprint, where they will be converted into products.

Each Sprint starts with Sprint planning where the specialist team plan the individual tasks needed to convert each user Story into a product. Here, estimation takes place to determine the resources needed to work on these tasks.

At the end of each Sprint (also known as a timebox), completed products will be potentially available for use by the customer.

By definition, each Sprint will have a fixed end date and cost, so the only variable the team have is scope, meaning that by the end of the Sprint, any uncompleted products are replaced back in the product backlog for consideration when planning the next Sprint.

During each Sprint there is a daily stand-up meeting to discuss work in progress and any issues, there is a Sprint review where the customer is given a demonstration of what products are complete, and a Sprint retrospective which looks back on how effective the Sprint and its process were and lessons or improvements then used for future sprints.

When teams first use Kanban, a transition approach can be useful where Kanban is used in concert with scrum sprints. However, the use of Kanban can entirely replace the framework of scrum.

Here is a diagram sharing the key elements of a scrum Sprint:

Agile Project Management With Kanban

The Kanban Task Board

The first column of the Kanban board is the Product Backlog in the form of user stories.

Some online suppliers will advise that you can use an electronic Kanban board, these are nowhere near as practical and useful as having a physical Kanban board.

Whether you use a large wall chart or whiteboard, it is best to capture user stories leading to the tasks within your project, in the form of post it notes.

So, the first step is to either create a series of post-it notes from your existing backlog or to brainstorm the backlog with post-it notes representing each user story.

Agile Project Management With Kanban

Breaking down your requirements

This is the first thing you need to do for each of your user stories, as initial stories can be very large with lots of elements to it and so will need to be broken down before you actually work on each element.

You will want to break each user story into tasks.

Breaking down into tasks is the break down step, and will happen continuously every day, without the need for dedicated planning session.

As the work is pulled through the Kanban board, there must be a Done column for each step, not as is usually shown, as a simple done column represented by the final right hand column.

By having a done column within each step, it provides a discipline for you to cheque that each step is truly finished before moving to the next column on the right.

Creating Done Rules for each Column

These should be captured for the Breakdown, Build, and Validate columns

Work In Progress (WIP) Limits

WIP is work that you started but you haven’t finished, and you will want to control all the work that is in progress.

WIP Limits are the maximum number of post-it notes that are allowed in any step (column). The way to do this is to start with the most work intense step which is the Build step.

Here you need to decide the maximum number of post-it notes that you and your team can manage. remember that each post-it note represents a task of which there may be several in order to create one or more products from each user story.

It is important that you do not have too many post-it notes in each column as this will cause bottlenecks. Remember that you need the right number so that your work flows smoothly and that you have enough flexibility.

With just the right amount of work within each column, you have the flexibility to switch and do something new, such as an extra task or adapting your Kanban board to introduce a new or modified user story.

There is no perfect number of tasks as it will depend on the nature of the project. I have used the numbers for and three in my diagram above simply as an example and to remind you that this limit must be stated.

Once you have got your Build column WIP limit, you can use that to calculate the Breakdown and Validate columns.

Scrum Daily Standups

This is called the daily Scrum. With Kanban, we get in front of the board every day to discuss the backlog, priorities and issues.

Unlike Scrum, we do not have to discuss what we did and what we are doing next – as that information is clearly seen on the Kanban Board.

So, all we need to do is move the stickies any time of day, so the only thing we need to discuss are any issues, changes, or additions.

If you have any stakeholders, just get them in front of the Kanban Board or describe it to them.

In Kanban you are continuously delivering, so there is no need for Sprints or Timeboxes.

Task Dependencies in Kanban Flow

They would always be dependencies on any project these may be dependent on a resource being available or a piece of work completed before you can start on it. So how does Kanban resolve this?

The answer is to add a Track Column.

Any dependency that cannot be dealt with right now goes into the track column. It is important to realize that this column does not count towards your work in progress (WIP).

It is there so that we acknowledge this dependency and we just have to wait for that dependency to free up or the person to become available.

During the daily stand-up, any items in the track column will be discussed and an estimate made for when work can start on that item. Once the item is ready to be worked on, it will be transferred into the top of the backlog and prioritised.

Kanban Board Resource Assignment

This happens continuously every day by whoever is available takes the next Post-it note task.

The biggest benefit of Kanban is that since you’re delivering value continuously, every day.

Resource and stakeholder availability can be a problem in Sprints. It may not be convenient for your customer to attend on the date of your Sprint review, whereas with Kanban you can demonstrate to your customer anytime you wish.

Project management with Kanban

Many projects can just use the Kanban board, the project manager, key stakeholders, and your specialist team without the need for any further structure or tools.

But there is nothing stopping you from developing a vision statement, a high-level product development roadmap and the release sequence of products as shown below:

Agile Project Management With Kanban

Kanban Project Planning Tools and Management

While Kanban is an efficient and effective method to deliver continuous customer value, projects do not take place within a vacuum. For a start, they will need to be funded and resources made available.

In addition, senior management will need to be kept informed of progress with a business case that is continuously updated to show that the project continues to be viable, desirable, and achievable.

Senior management will probably want the Kanban board translated into a form that they can easily digest and make decisions upon.

Monitoring and Controlling Kanban

This points the way to the use of monitoring and controlling management structure sitting above the Kanban process. It is important that this is done in such a way, yet it does not impede the empowered team using Kanban.

When using any form of an agile method, the project manager roles should not be one of “command and control “, rather function as a servant leader.

Here, the project manager should act as a facilitator while ensuring that any roadblocks getting in the way of the team are resolved or minimized.

By acting as a facilitator, the project manager can ensure factors such as risk management, resource usage, schedule progress and costs are controlled in a reasonable manner.

Using Microsoft Project Kanban

Here, project management tools such as Microsoft Project can be swiftly tailored as a framework around the Kanban board itself.

It is straight forward to use any version of Microsoft project and enter user stories as a summary bar with tasks and resources assigned within the breakdown, build and validate steps of a Kanban board.

Once such data is entered into Microsoft project it can then be used by the project manager to track high level progress throughout the project and used to create senior management reports to keep them informed.

The creation of a traditional documented project plan, business case and specialist documents can also be created outside of, and in support of, the Kanban Board.

Dave Litten

David spent 25 years as a senior project manager for USA multinationals, and has deep experience in project management. He now develops a wide range of Project Management Masterclasses, under the Projex Academy brand name. In addition, David runs project management training seminars across the world, and is a prolific writer on the many topics of project management.

The Projex Academy

related posts:

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Project Management Masterclasses