Comparing Agile Methods: Scrum, Kanban, and Scrumban

Regular readers will know that I’m not at all experienced in formal Agile project management, but I know it is something that I need to know more about.

Today I’m partnering with Eylean to give you an overview of three agile methodologies: Scrum, Kanban, and Scrumban. I’ve learned a lot during the research for this article! Let’s dive in.

Agile Methods: The Basics

Agile is agile is agile? Not true (although all flavors of agile are part of the set of project management trends because they’re so critical to the work we do today). Scrum, Kanban, and a method that blends the two (turning Scrum Kanban into Scrumban) are all quite different.

Scrum is a way of managing the work within defined timescales called sprints. These generally last between 1 and 4 weeks and you work through your task list in that time. It’s relatively formal in that respect, as deadlines are tightly respected.

I think of the Kanban method as a way to visually manage To-Do lists. There are few formal constraints and you adapt your Kanban board (more on that later) to reflect your workflow as you wish. There are no hard deadlines, but you can work towards a release or a larger goal.

Scrumban is a blend of the two, as you’d expect. You’ve got the idea of a continuous flow of work within longer planning cycles that tie into your release dates.

Who Makes Up The Agile Team

Scrum, as the most formal of these three methods, has formal roles: Product Owner and Scrum Master (plus other cross-functional people who make up the ‘team’).

The Product Owner is kind of like the waterfall Project Sponsor. She sets the vision and priorities. The main difference I think is that sponsors are rarely part of the team day-to-day. Product Owners are right in there with everyone else.

The Scrum Master is the person whose role is similar to that of a project manager: someone who leads and manages the Scrum process.

There aren’t formal roles prescribed for Kanban and Scrumban so you can use whatever you want, or no formal roles at all. Kanban team members tend to have specialist skills but Scrumban teams could be made up of specialists and generalists.

Read More: 5 Structures for Agile Teams

How Work is Planned

All agile methods need you to work out what has to be done. It’s when you’ve got your requirements that the approaches start to differ.

Scrum teams take their requirements from the product backlog. The Agile Alliance defines the backlog as:

“a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release.”

During planning you prioritize the work for each sprint. There’s a ton of negotiation at this point about making sure that the right tasks are being done in this planning cycle.

If a big task can’t get done within the sprint time frame then it will be split up into smaller chunks because the sprint dates absolutely have to be respected.

Scrum teams have awesome change management processes. No new stuff gets added during a sprint but it might make it into the next sprint.

Kanban is far more relaxed. The team can add work when their task lists are empty or at any other point – as they don’t work with sprints there are no fixed points where they have to come together to plan.

As Kanban team members tend to have specialisms, they can take their next task whenever they’ve finished their current workload and there isn’t the requirement to wait until the next formal planning cycle to get more work allocated.

Scrumban teams do their planning when they run out of work to do, or in agile-speak “when the backlog is complete.”

How Tasks Are Displayed: Kanban Boards And More

All three approaches use visual display boards (which today are more likely to be on your computer than on your office wall, but you could still go old school). These show the tasks and what stage they are in the process of getting done.

I’m actually a bit in love with Kanban boards. I think the idea of moving work visually between columns is great and a really simple communication tool for teams.

Here’s an example of an Eylean Kanban board:

I struggle with them because I am not a visual person. I’m wordy. But if I worked in a team where we were using agile project management methodologies I reckon I’d spend quite a lot of time at our board.

Kanban boards and Scrumban boards sit there and are used over and over again. It’s a continuous flow of work, so the tasks hop on one side of the board and make their way over to the other side where they drop off.

Scrum task boards are wiped and reset every time a new sprint starts to reflect the requirements planned for this sprint.

Here’s an example of a Scrum board. They don’t look that different at first glance but the backlog tasks are described as user stories and there are some other subtle differences.

How Tasks Are Allocated

The more traditional role of the project manager sees tasks being allocated or assigned to team members. In reality, that’s done based on discussion and taking into account team members’ skills, experience, and interests.

In Agile methodologies, team members get to choose the things they would like to work on.

Scrum teams get to choose upfront so they each know what their responsibilities are during the spring. Kanban and Scrumban teams choose as they go.

Having not lived this process myself I can only assume that it’s actually similar to the discussions I have with my team. I can’t imagine that core business requirements are not delivered because no one fancies working on them for the next month.

Both Kanban and Scrumban have a ‘work in progress’ limit. For example, I can’t do more than one book review for this blog at a time, so my workload would only show one at a time.

How Progress Is Measured

The burndown chart is the key way to measure progress in Scrum. Burndown charts have always struck me as complicated and I expect they are if you have to create them manually. Fortunately, software tools make it a lot easier as it’s all automated for you.

Burndown charts show you how much work you have ‘burned down’ i.e. completed. They illustrate how much work is still to do (the blue line in the picture below) and what the idea progress would be (the dotted line – waterfall people, think actual work vs planned work on your Gantt chart).

They also display other performance metrics such as the concept of ‘value’ (the green line in the picture below) which should go up as the team completes more work.

Progress in the Kanban method is measured in two ways:

• Cumulative flow: A graph that shows total items in progress
• Cycle time: A measurement that shows how much time it takes to complete one task.

Scrumban uses cycle time too. Here’s what a cycle time chart looks like:

The limitation for this that I would like to explore further is what happens when your tasks are not supposed to take the same amount of time? Average cycle time then becomes meaningless. A deeper analysis of Agile performance metrics will have to wait until another day!

Which Agile Method is Best For You?

So, which of Scrum, Kanban and Scrum Kanban should you be choosing?

The answer, as it so often in project management, is ‘it depends’.

All agile methods have the advantage of being close to the work and being able to make decisions based on the reality of the project. They all rely on a close-knit team.

Scrum has advantages for big projects that need to stay on top of the requirements and deliver regularly. The Scrum Alliance says that the approach is particularly beneficial for complex projects.

The Kanban method is probably less suited to a project environment and more appropriate for operational teams dealing with a steady stream of work.

Scrumban gives you the benefits of timeboxing work into sprints and releases with the flexibility of being able to add new work and cope with business-as-usual type work too. That would work well for smaller teams who manage project work alongside keeping the business operational, for example in a start-up situation.

While I’ve learned a lot during the writing of this article, and I hope I’ve explained some of the main differences between the approaches, this isn’t enough for you to make a decision about what is right for your team. There is also the hybrid approach mixing agile and waterfall/predictive to explore as well.

If you’re thinking about adopting agile methods then use this as a springboard to research how they would work for you in practice, and then commit to an approach and try it!

Further Reading: Agile Project Management for Dummies by Mark C. Layton. This is my ‘go-to’ book for understanding agile, although it is written predominately with a software development environment in mind.

I’d like to thank the team at Eylean for sponsoring this article and helping improve my knowledge about agile project management methods! Find out more about Eylean, a Scrum and Kanban desktop software tool, on their website: http://www.eylean.com.