What’s the Best Agile Project Management Method For You: Scrum vs Kanban

This ar­ti­cle does not in­tend to pit Scrum vs Kanban. Both meth­ods have their unique value. Thus, we’ll ar­tic­u­late the key dif­fer­ences and sum­marise the trade-offs be­tween the two. In the end, you may wish to ap­ply one or both of them both to your Way of Working. At WorkingMouse, we favour the Scrum ap­proach within our Way of Working dur­ing de­vel­op­ment and then use a Kanban ap­proach for sup­port and short term hir­ing.

Iteration Planning


The dif­fer­ence in plan­ning be­tween Scrum and Kanban is reg­u­lar ver­sus on-de­mand. In Scrum, tra­di­tional plan­ning hap­pens at the be­gin­ning of an it­er­a­tion (or sprint) which will usu­ally last be­tween 10-15 busi­ness days.

At the end of the it­er­a­tion, the soft­ware is re-de­ployed. Following that, the team plans the next it­er­a­tion. Kanban is a con­tin­u­ous flow of is­sues with­out an ac­tual plan­ning point. Once an item has fin­ished a stage, e.g. Design,’ it is on-de­mand pulled into the next stage, e.g. Development’ like a pro­duc­tion line. Each pro­duc­tion stage should have a limit on the amount of items worked on at any one time.

The crit­i­cal trade-off be­tween the two here is im­me­di­ate flex­i­bil­ity vs. how much the team can de­mand. In Scrum, can your prod­uct wait un­til the next it­er­a­tion cy­cle for an item to be added? At the same time with Kanban, putting an is­sue into the pro­duc­tion line will af­fect the work that is al­ready in progress. Therefore, are you sure you won’t block the pro­duc­tion line with too many plan­ning changes? If so, what will you have to pull out of pro­duc­tion?

Software Estimations


The es­ti­ma­tion process be­tween the two meth­ods is po­lar­is­ing, with Scrum es­ti­mat­ing proac­tively and Kanban ret­ro­spec­tively. In Scrum de­vel­op­ment, es­ti­mates hap­pen be­fore each it­er­a­tion. Items should be bro­ken down, so they are small enough to fin­ish within the it­er­a­tion, and time is ap­plied to each item. There are many dif­fer­ent meth­ods for achiev­ing Scrum es­ti­mates from tra­di­tional to sci­en­tific.

In Kanban soft­ware de­vel­op­ment, it is op­tional to es­ti­mate when items are com­pleted. There’s no set time on is­sues as they are pulled into the next stage, and it’s de­pen­dent on what’s in pro­duc­tion. These es­ti­mates can even be done on items in the back­log. The Kanban es­ti­mates on com­plete items are lead time and cy­cle time. These pro­vide an av­er­age es­ti­mate of the amount of time it takes for a task to move from start to fin­ish. If you want to un­der­stand the pre­sent state for Kanban, a cu­mu­la­tive flow di­a­gram (CFD) is the best an­a­lyt­i­cal tool to un­der­stand the time it takes and the cur­rent work­flow in pro­duc­tion.

The trade-offs here are rel­a­tively straight­for­ward, you can ei­ther know how long some­thing will take or know how long some­thing took. Either method re­lies heav­ily on trust in the team’s es­ti­ma­tion and skill. The ques­tion is, how vi­tal are es­ti­mates to you? If you’re work­ing within a set bud­get, a Scrum ap­proach may ap­peal as you will know what you’re get­ting for every it­er­a­tion be­fore it be­gins. In Kanban, if you have no set bud­get and a con­tin­ual amount of re­sources, this ap­proach may be favoured.

Scope Changes


Change re­quests are a di­rect re­flec­tion on plan­ning. In Scrum, it’s sim­ple no changes for you … well, at least un­til the next it­er­a­tion. As the items are es­ti­mated, and the it­er­a­tion length is fixed, noth­ing can be changed. This can be frus­trat­ing, es­pe­cially if there’s an im­me­di­ate need/​is­sue. In Kanban, the free­dom is all yours, put in your changes as you need them. However, with great power… you know the rest.

The pros and cons of the abil­ity to change im­me­di­ately are clear. It’s a big pro to put in an im­me­di­ate change, es­pe­cially if that change re­lates to a prod­uct is­sue that is af­fect­ing many users. However, there is merit to the pa­tience of Scrum. A dif­fer­ence you view as es­sen­tial to­day could have other pri­or­i­ties trump it when it comes to the next it­er­a­tion plan­ning ses­sion. The abil­ity to have a cool­ing-off pe­riod on your pro­duc­tion line may be of ben­e­fit. This comes down to how to make the best de­ci­sion. You should con­sider your data sources around prod­uct us­age, cus­tomer-cen­tric de­sign (user ex­pe­ri­ence, com­pet­i­tive of­fer­ings, pric­ing, mar­ket share, and in­dus­try trends.

Development Team Roles


This is where the struc­tures be­tween the two ap­proaches show the sep­a­ra­tion of phi­los­o­phy. Scrum has clearly de­fined roles. The roles are; prod­uct owner (you), who ad­vo­cates for the end-user and man­ages the pri­or­i­ti­za­tion of the prod­uct back­log. The Scrum Master (our squad leads/​pro­ject man­agers) who man­ages all of the meet­ings (or cer­e­monies). And, of course, the de­vel­op­ment team who de­liv­ers the work.

In Kanban, there is no sin­gle mas­ter. The team work col­lec­tively to col­lab­o­rate and de­liver a task that is on the board. Teams can en­list the help of a coach if they de­sire, but the coach has no in­flu­ence on the prod­uct, un­like the Scrum Master and Product Owner.

The trade-offs here are be­tween hav­ing a struc­tured and un­struc­tured ap­proach. If you have a team that is ex­pe­ri­enced in work­ing to­gether and com­pre­hends the do­main of what the prod­uct should achieve, then a Kanban ap­proach may suit. However, if there are mul­ti­ple com­mer­cial par­ties, Scrum may be a bet­ter fit. At WorkingMouse, we treat the cus­tomer as the prod­uct owner. We have the do­main ex­pe­ri­ence in de­vel­op­ment and as­sume the prod­uct owner is bring­ing the do­main ex­pe­ri­ence for the prob­lem we’re solv­ing.

Agile Ceremonies/Meetings


Due to the con­tin­u­ous flow of Kanban, it re­moves a sig­nif­i­cant amount of pro­ject time bloat. This means cer­e­monies are kept to a min­i­mal. Weekly 30-minute meet­ings or daily 15-minute hud­dles are ideal. A pro­ject man­ager’s night­mare and every­one else’s de­light!

The Scrum ap­proach has sev­eral vi­tal meet­ings through­out the it­er­a­tion cy­cle. The first is a plan­ning ses­sion where the en­tire team draws upon the top pri­or­i­ties of the back­log and agree upon the user ac­cep­tance cri­te­ria (approximately 1 hour long). The sec­ond meet­ing is an elab­o­ra­tion ses­sion where the team con­firms how they will solve the is­sues, and the time/​risk es­ti­ma­tions (approximately 1 hour, ex­cludes prod­uct owner). Once de­vel­op­ment has be­gun, the team com­pletes a 10-15 minute daily hud­dle that calls out who’s do­ing what and whether any team mem­ber is ex­pe­ri­enc­ing block­ers (1 hour per week, ex­cludes prod­uct owner). Lastly, upon de­liv­ery, the team does a re­view (approximately 1 hour) and a ret­ro­spec­tive to look for im­prove­ment op­por­tu­ni­ties (1 hour, ex­cludes prod­uct owner). That to­tals 5 hours across a sin­gle it­er­a­tion if all runs well.

The trade-off here is clear, 5 hours of every team mem­bers time put to­wards pro­ject de­vel­op­ment or use that time for pro­ject man­age­ment? This is why it­er­a­tions have a min­i­mum of 10 days or two weeks as the team would get too bogged down with run­ning cer­e­monies.

Agile Boards/Reports


The two meth­ods run the same pro­ject board. Issues flow through in the fol­low­ing se­quence: To Do, In Development, Testing & Done. The dif­fer­ence is that Scrum has two stages be­fore: a Product Backlog (which en­com­passes every­thing) and the Iteration Backlog (all func­tion­al­ity that will be com­pleted in this it­er­a­tion). The re­port­ing on Scrum is via a burn­down chart that tracks is­sue com­ple­tion against it­er­a­tion time. This can be sum­marised as the pro­jec­t’s ve­loc­ity. The Kanban re­ports are the lead and cy­cle times that feed into the Cumulative Flow di­a­gram.

Again, this comes down to prod­uct re­spon­sive­ness very pro­ject plan­ning, and the type of pro­ject you are un­der­tak­ing. In my ex­pe­ri­ence, I’ve never seen a Scrum pro­ject with an empty prod­uct back­log. There will al­ways be more to do, and there will al­ways be tech­ni­cal debt. Does re­mov­ing the prod­uct back­log free you as the prod­uct owner from this and en­able a for­ward-think­ing mind­set or, is it es­sen­tial that this de­tail is never lost?


As you will now see, there’s a fairly big dif­fer­ence be­tween the two mod­els. It may be best to re­flect on how you like to work as a prod­uct owner? Do you pre­fer to work in a planned man­ner or re­ac­tively? Traditionally, Scrum works bet­ter for large pro­jects that re­quire struc­ture such as soft­ware out­sourc­ing while Kanban is be­tween for fast changes, sup­port/​main­te­nance, and bug fix­ing. At WorkingMouse, we use the Scrum method in our Way of Working for pro­ject de­vel­op­ment but al­low a Kanban ap­proach to sup­port where our clients choose what is go­ing into sup­port pro­duc­tion or does­n’t. We hope this ar­ti­cle helps you find your Way of Working for your pro­ject.


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

What is Agile Software Development: How to Start with a Problem

16 October 2020

The Advantages of Agile Project Management

09 September 2020

How To Prioritise Your Technology Pain Points in 2021

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call