I’m co-hosting the Darkside of the HODL Moon podcast with my buddy Kade. Check out our homepage: https://darksideofthehodlmoon.com
Now then, so what’s Kanban and how does it compare to Scrum?
Like Scrum, Kanban is just a method for executing Agile software development, except it’s not as strict as Scrum in terms of meetings and times.
So you may have actually seen what’s referred to as a Kanban board before.
Basically, it’s a bunch of columns with cards on it that you can move from one column to the other one to reflect a state of that item, like to do, in progress, and then done. See Trello for a cool free example of this you can use today!
However, just because something has a Kanban-style board does not mean that that is the Kanban process.
Instead, Kanban does not use “sprints”.
Also, since there’s no sprints, there’s no sprint backlog, which we’ll learn about, but only the product backlog itself.
So what happens is the team just works on their tickets, they get the job finished, they move it to done and then they take the next task off the top of the product backlog.
And that backlog just goes on forever, it’s just endless.
Kanban is also different from Scrum in that it does not prescribe any particular meeting types like Scrum does with standup meetings, and sprint planning meetings, and retrospective meetings. And there’s one more big difference.
Kanban operates off of the theory that only a certain amount of items can be in progress or in any given state at one time. How many items can be in each particular state is up for you and your team to decide.
Some software teams use Kanban, but it tends to work best with teams that are not very concerned with things like estimation and are continuously moving tasks through the same number of steps pretty quickly until they’re complete.
For instance, customer service teams often use a Kanban-style of working.
There you are then. That’s what Kanban is all about.
Now we are familiar with Scrum and Kanban, the next big question is, which one is best?
Sorry to disappoint you, but there’s no definitive answer here as it depends on what your team prefers to use.
The best process is the one that you like using. As you can tell, Kanban is a more relaxed way of doing Agile development but it has a big disadvantage since it doesn’t use sprints.
It’s going to be more difficult to project the amount of time it’s going to take to complete work.
Don’t worry too much about that right now because we’re going to talk about things like estimations and velocity another time.
So to review Kanban is just another way to implement an Agile type of software development workflow.
It’s a little less prescriptive than Scrum and it does not use sprints.
Got it? Good!
Alright, see you in the next blog post.