If you run agile teams, chances are that you already use a Kanban Board, or you might use a Scrum Board. But have you stopped to consider whether it might pay to weigh up the two options, and maybe think about switching between Kanban and Scrum Boards? Particularly if you have inherited a legacy system, it might be time to take a good look at Scrum Boards and Kanban Boards and decide which is actually the best fit for your team. (It is also possible to create a hybrid of the two called 'Scrumban' - you can read more about that in our FAQ - What is Scrumban?)
Scrum Boards and Kanban Boards both perform some of the same functions. You might even say that their goals - to create a clear, visualized workflow that helps a team stay on track and work productively - are the same. But the way they both get there is pretty different. Let's dig into it.
- What is a Scrum Board?
- What is a Kanban Board?
- Pros and Cons of Using a Kanban Board
- Pros and Cons of Using a Scrum Board
- Scrum Board vs. Kanban Board: which wins out?
What is a Scrum Board Exactly?
A Scrum Board is a visual tool to help teams that work in Sprints to track their work. If you want more background on Sprints, we’ve got you covered. But for the purpose of understanding Scrum Boards, the central thing to keep in mind is this: there are two key elements of the board - the product (or project) backlog, and the Sprint backlog. The product backlog contains all the tasks associated with the product or projects; the Sprint backlog contains only the tasks that were agreed for that particular Sprint.
An example of a Scrum Board in Forecast
This is what Scrum Boards look like in Forecast. The six tasks that you can see in the 'Sprint' column would have been drawn from the 'Backlog' during the Sprint planning meeting. For the duration of their current Sprint, the project team will only work on completing the tasks in the Sprint column of the Scrum Board.
So, what is a Kanban Board?
A Kanban Board is another way of visualizing a workflow that is helpful for agile teams. The basic principle is that it allows you to see what work is upcoming, what is in progress, and what’s already been done, by splitting the workflow into different columns. It’s not associated with fixed periods of time like a Sprint, but instead it is ongoing.
Kanban Boards are easy to use and very flexible. Even though Kanban started off in the manufacturing sector, using a physical board and cards, Kanban clearly works excellently well in other sectors too. Some people even set up a personal Kanban Board to track their own work. It really is that versatile! The majority of people who use Kanban today use a digital board rather than a physical board. It’s usually quicker and easier to update, and it suits hybrid teams a lot better. Seeing as Kanban Boards are so popular, it’s no surprise that the market is full of platforms you can use to create your board.
The Case for Kanban Boards
Pros of Using a Kanban Board
- Flexible structure meets the needs of your workflow
The standard Kanban Board has three columns: “Backlog”, “In Progress”, and “Done”. But there’s no reason why you can’t adapt this basic Kanban Board layout to create something a little more bespoke and custom for your team.
The best Kanban software lets you create these custom layouts with ease. The below example of a Kanban Board was built in Forecast. For this project, “Ready to Start” and “Awaiting Approval” columns were added, so the team can have better oversight into what stage each task has reached - is it in the process of being signed off, for instance.
An example of a Kanban Board in Forecast
The Kanban view in Forecast is just one of the ways you can visualize your project, the Gantt chart "Timeline" view being another. To make things even easier, our Kanban Board automatically populates with any tasks you create anywhere else within the platform, meaning that you won’t spend any time duplicating information into your Kanban Board. If a task is marked as ‘done’ elsewhere within Forecast (within the project’s Scoping page, for instance), it will automatically move into the “Done” column on your Kanban Board.
This flexibility, arguably, is better at helping your agile team live and breathe the values of the Agile Manifesto, allowing for better change responsiveness, and valuing people (and the way they work best) over processes.
- It’s very easy to learn
Got a new team member who hasn’t worked in an agile setting before? “Burndown chart”, “Sprint Velocity”, “Extreme Programming”...watch their eyes glaze over as it dawns on them that they have to learn a new language in order to negotiate their new job.
You don’t have this problem with a Kanban Board. Even if someone has never used one before, they can take one look at its intuitive layout and get the gist of how it works. This also makes it super accessible for anyone who might only be on the team temporarily, like a contractor or freelancer.
Cons of Using a Kanban Board
- Prioritization is not inherently built-in to Kanban
In the standard “Backlog/To Do”, “In Progress”, “Done” set-up of a Kanban Board, it might be easy to see what people are currently working on, but how do you communicate which tasks are more urgent than others? Even in the most expertly run projects, issues can arise which knock the plan off course. You may need to reduce the scope of what you’re working on. But some tasks will, inevitably, be non-negotiable and mission-critical. However, in a basic Kanban Board, it won’t be immediately obvious which tasks these are.
You will have to adapt your Kanban setup - perhaps adding a “Priority” column. This is easy enough to do, as previously mentioned. But if you find that questions of urgency and priority keep coming to the fore during your projects, you might want to use a system that helps you tackle your backlog of tasks in defined, time-sensitive Sprints, like a Scrum Board.
- No fixed or defined timeboxing (if this is what you want)
We alluded to this in the last point, but it bears repeating that sometimes a little structure is a good thing, even if you are trying to keep things as flexible and reactive as possible. For bigger and more complex projects, if you try to map out all of the tasks in your Work Breakdown Structure onto a Kanban Board, it will quickly become enormous and unwieldy. In these cases, you’d likely be better off creating backlog containing all tasks, but migrating items from the backlog in manageable increments… as you would do in a team running Sprints with a Scrum Board!
- Tasks can get ‘stuck’
Let’s put this into context with an example: say one of your developers moves a task from the "To Do" to the "In Progress" column. Great so far. But then, while in they’re in the middle of that task, they encounter a problem that stops them from finishing it - something that they can’t resolve themselves. Maybe the resolution is going to take several steps. Perhaps it requires outside help. In the meantime, what happens to the task?
It stays there, languishing in the "In Progress" column, clogging up the Kanban Board. The PMI actually warns against this problem and recommends you tackle it by putting a limit on how many "In Progress" items sit on your board at any time.
An iterative process with fixed points for review, like a Scrum Board, wouldn’t have this problem. In the Sprint retrospective, the team would evaluate the ‘stuck’ task and either move it back into the backlog or break down the action points needed to get the task finished. These would then be added to the next Sprint.
The Case for Scrum Boards
Pros of Using a Scrum Board
- Fits perfectly with working in Sprints
The Scrum Board is, after all, a collaborative tool that is designed specifically for working in Sprints. It fits perfectly into the process and keeps the team on track while they progress through the user stories agreed for the Sprint.
Because the content of the Sprint is agreed upon at the beginning of the Sprint, all the tasks that need to be tackled in the Sprint will be added to the Scrum Board - meaning that the board becomes an essential reference point for the whole team. And in the Sprint retrospective, the board can be used as a jumping-off point to help you review what you achieved.
- The structure creates momentum to get things done
Working in Sprints can really light a fire under a project. It creates a sense of urgency (because the time pressure is on) but not panic (because the work funneled into the Sprint is -- ideally! -- gauged to be manageable within the timeframe of the Sprint).
Part of the goal of working in Sprints is that nobody is ever at a loss about what they should be doing, or what task they should focus on next. A Scrum Board captures all the work that needs to happen in the Sprint. It enables a level of clarity that keeps your Sprints on track, meaning that work can progress at pace.
- The Scrum Board is controlled by the Scrum Master
Remember how we said that a Kanban Board can become messy, with unfinished tasks hanging around in inappropriate places, and no priority clearly defined? Well, one way to prevent your agile workflow platform from getting clogged up and confusing the life out of your team is to make someone responsible for keeping it updated, functional, and managed.
When you’re using a Scrum Board, this problem is an easy solve: the person who takes this role is the Scrum Master. The Scrum Master will run the Sprint planning meeting, and update the board off the back of this plan, getting it ready for the Sprint ahead.
With someone to manage the Scrum Board, it is far more likely to remain as a useful, tidy, functional tool.
Cons of Using a Scrum Board
- ...the Scrum Board is controlled by the Scrum Master!
Yes, we just considered this as a pro, but here’s the thing: it depends on your goals for your team. If your aim is a really flat, agile team structure, with individual contributors who are equally empowered to move rapidly and decisively, do you really want to be tied to a board that can only be changed by one person in the team? It might make sense for some projects, but not for others. The last thing you need is your Scrum Board slowing you down.
- The product backlog needs to be managed or ‘groomed’ to avoid becoming too much
Each Sprint, you return to your backlog and choose which tasks you want to bring into the upcoming Sprint. In theory, this means that you’ll keep on top of your backlog, because you keep chipping away at it each Sprint.
But as you progress through your agile project, your backlog will change. New requests can be added; tasks might evolve into something bigger; items might change in terms of priority. Another key principle of the Agile Manifesto is prioritizing being responsive to change over sticking rigidly to a prescribed plan. So, if your team is really embracing the spirit of agile, you should be willing to accept changes to your backlog as par for the course.
However, this can lead to your product backlog becoming something like a never-ending wishlist of ‘nice to haves’ with no real sense of what needs to be tackled first. There will, of course, be times when your backlog looks hefty. But there shouldn’t be any point at which your backlog looks completely, infeasibly possible to work through. You do need to stop it from becoming unmanageable.
At times, you will need to stop and review the product backlog. But this means that adding another level of process to your Sprint - more time in meetings, and more time away from the work you’re trying to get done.
So, Scrum vs. Kanban: Which Wins?
Unfortunately, there is no cut-and-dried answer to this question. What works for one project might not be the best approach for another. Each team works a bit differently, and that's without even considering the fact that Project Managers have their own differing opinions of what best practice looks like.
Ultimately, the most effective thing you can do is to be familiar with both ways of working, so you can make a judgment call on what is best suited to your upcoming projects. You can get the best of both worlds a platform that makes switching between Kanban and a Scrum Board pain-free and simple. Rather than boxing you into one method, Forecast gives you the option to run projects with Sprints or without (you can even turn Sprints off midway through a project if you need to for whatever reason!). You can build the perfect, flexible Kanban Board, or stick to our simple, structured Scrum Board. The choice really is yours.
