By: Jesse Domenget

It was first in March of 2010 as an intern that I was first introduced to Scrum. The company I had been hired by was only about one or two years into their Agile journey. Then in the Summer of 2015 I was introduced to Kanban by a co-worker of mine. Throughout my journey, I started to develop a passion for Agile and was amazed how it differed amongst companies.  Then in October of 2016 I became a certified Scrum Master and now sit here typing to explain the difference between Scrum and Kanban.

Let’s get right into it and talk Scrum.  Scrum is an agile framework where a product owner adds features to a backlog list that is prioritized in importance per the product owner. A scrum team executes a sprint plan of features to complete with a sprint being a time box of usually about two weeks.  Before each sprint, there is a meeting called sprint planning which is where the product owner, scrum master, software engineers and testers on the Scrum team meet to prioritize what should be done in the sprint with the main goal to have a piece of shippable software for the end user. At the end of each sprint a review and retrospective are performed to determine how the sprint went and learn from what went right and what went wrong and to make changes from these experiences for the next sprint coming up.  After this another planning session occurs and the sprint starts all over again for the next chunk of prioritized work.  To estimate in Scrum, you track story points where each task being worked on is given a point value according to difficulty set by the team.  With this you track velocity which is how many story points can a team complete in a sprint.

Kanban is another agile framework but differs, as you will see, from Scrum.  A product owner prioritizes a backlog and can at any point. One of the main goals in Kanban is to limit Work in Progress (WIP) to the team’s capacity. Typically, the capacity is WIP equal to the number of team members that can perform the work which means I should never have more than one thing in progress at a time as a team member.  As a team member, I look to the backlog to see what is the next priority and start working on it.  Once I finish that task I look to the backlog again for the next priority of work. As the team finishes tasks it’s up to the team to determine when a new piece of software is shippable.  Since the team is not obligated to work on a set plan the product owner can change the backlog priority as they choose.

So, what are the differences?

  • Meetings
    • Scrum – Throughout a sprint there is sprint planning, backlog grooming, sprint review and sprint retrospective. Daily standup meetings occur each week.
    • Kanban – In Kanban there is not defined meetings. However, in practice you may introduce daily standup meetings and backlog grooming sessions.
  • Planning
    • Scrum – Plan and work in a time boxed sprint where priorities cannot change during that sprint. There is always a sprint planning meeting with the entire team to plan the next sprint.
    • Kanban – Always working with the next item at the top of the backlog. Priority can change at any time in the backlog.  Backlog prioritization is supposed to be set by the product owner.
  • Estimating
    • Scrum – Tasks are estimated in story points. The idea is to estimate in the amount of effort and not time.  The general idea is to pick a few previous tasks and apply points against them.  For example, an easy task is 1 point.  Slightly easier is 2 points.  Then 3 points, 5 points, 8 points and so on.  If the task is new or you are unsure of how to do it give it a high point value to indicate uncertainty. The points can always be adjusted as you find out more about it.
      • If you haven’t noticed the point system follows Fibonacci numbers (e.g. 1, 2, 3, 5, 8, 13, 21) instead of doubling points (e.g. 1, 2, 4, 8, 16, 32). There’s no right or wrong answer for the point system you use but teams tend to choose Fibonacci because it gives a big enough gap between numbers and shows that as points get higher uncertainty is greater. It also makes a team question 8 points vs. 13 since it’s not doubled.  It’s easy for team members to say “Oh yeah, that’s doubled effort” when doubling points.  It doesn’t make the team questions the points when executed in practice.
      • As the team starts to complete tasks over a few sprints you start to gather a picture of the velocity of the team. Meaning how many points can a team typically complete in each sprint.  With this number, you can estimate how long a project will take.
    • Kanban – Uses a concept called Cycle Time. The idea is that each task should be scoped to be relatively the same amount of effort. If a team can do that the tasks they work on should start to take the same amount of time to complete. With that data, you can say when the next task will be complete. Of course, impediments happen but because with cycle time you’re taking the average time to complete over a period of time the impediments to a degree should end up being considered with the cycle time you develop.
  • Reporting
    • Scrum – A burn up chart is used in scrum to show how many points have been completed over time. Using a deadline date, you can see with this chart at the velocity the team is working at whether it’s plausible to finish by that date.
    • Kanban – A Control Chart is used in Kanban to determine how long a task should take. This chart tracks each task and how long it took to go from in progress to done. The chart shows the date the task was complete and how much time elapsed until it was finished. The chart tracks a rolling average and shows the standard deviation between the rolling average and the complete time of any given task.  If you see that your standard deviation isn’t far off from your average, then you can safely use your average to determine how long a task takes to finish.  If your standard deviation is large, then you can’t say with confidence that your rolling average is how long it will take to complete a task.

What we chose and why

In general, we follow Kanban. A main reason we chose this is we don’t have the resources and time to follow scrum. Since a lot of us work on multiple projects it’s hard for us to get the time for everyone to be in the same room. Scrum meetings can take up a good chunk of time and in general during that time developers aren’t working on new features.

We do however, mix some scrum into Kanban.  That’s the nice thing about being Agile you can generally do what works for your team.  For example, we still have myself as a scrum master to help guide the team through the Kanban processes as well as there have been times in the past that we’ve used story points to estimate instead of cycle time.

What has been some pain points through our journey into Kanban?

In my opinion a lot of difficulties throughout our journey have come from the team knowing and utilizing scrum in the past at other employers and then trying to transition into working in Kanban. One of the main difficulties has been estimating work.  I personally like story points as it’s an easy concept to understand and it does work very well. However, with Cycle Time in Kanban it has been difficult to group tasks into equal sized chunks so that the standard deviation on the control chart stays close to the rolling average.


To conclude, what works for us as a team doesn’t mean it will work for you.  Scrum and Kanban are two different Agile frameworks but can be mixed to suit your needs. Scrum in my opinion has a more defined process while Kanban let’s a team get down to work without meetings in the way. The great thing is that the choice is yours and can always be changed to better suit a developing team’s needs.