Scrum or Kanban?

Posted on December 1, 2014

When should you use Scrum and when should you use Kanban? There’s no answer that’s right 100% of the time for this question but there are some general rules of thumb that you can use to decide between Scrum and Kanban. The main factors to consider are:

  • Is this a new development project or are you simply adding features and/or maintaining an existing product?
  • Do you have a small team of developers (i.e. less than four people) or variable resource allocation over the duration of the project?
  • Do you have to answer to external stakeholders or demonstrate progress at pre-specified intervals (e.g. at the end of every week-long sprint) to the Product Owner?
  • What is your team used to, and what project management tool are you planning on using?


If you’re starting a new development project, especially if it’s large, it’s generally best to use Scrum rather than Kanban. This is because you’ll likely spend a tremendous amount of time preparing wireframes and user stories prior to starting the development work, and being able to create well-organized epics to act as containers for your user stories, and versions to communicate your vision and product roadmap for your Beta, v1.0, etc. releases will be helpful. If, on the other hand, you’re simply adding features or responding to bugs/tickets on an existing product, Kanban is a better bet. This is because you probably won’t be doing a tremendous amount of road-mapping or product development work. Thus, the project management structure and ceremonies required by Scrum will slow you down rather than speeding you up.

If your team is small, e.g. 2-3 developers, or if you have a lot of resource flux on your team, it’s usually better to use Kanban. Why? Because you’re not in a situation where you can create epics and versions according to a roadmap, allocate all of the necessary resources, commit to a sprint backlog, and then execute consistently (with stable velocity). You’re in more of a “well, we’ve got a couple of part-time guys working on this, and they can each allocate 15-20 hours/week each so let’s just keeping working on whatever is at the top of the backlog.”

If you’re on the hook to deliver something “shippable” or have to demonstrate progress to the Product Owner or stakeholders at the end of every sprint it’s usually better to use Scrum. This is because it helps you manage expectations and provide clarity on what you’ll be delivering to your stakeholders and the timeline of your milestones. It provides a structure, which you can use to collaboratively plan out your deliveries and ensure that no-one is disappointed or surprised.

Finally, it’s always important to choose the right tool, principle, or process for the job. Every situation and every team is a bit different. If your team is used to using Kanban, and you don’t see any need to make a change, then, of course, it doesn’t make any sense to do so.

Preview Next ArticleBack to All Articles