My company uses a somewhat waterfall approach and wants to move to Scrumban. While I have experience with Scrum and Kanban separately, I wonder how to merge these agile team boards into a workable Scrumban board.

The principle problem, from my perspective, is that one relies on a fixed input of stories for a given, short, period and the other depends on a flowing and mutable funnel.

How to have both?

[Further explanation]

I am asking because we are very keen to have proper sprints and have the business requirement of taking on defect maintenance during a given sprint. So while my preference would be for the PO to add those items to the backlog and wait for the following sprint to begin, this may not be practical in reality.

I am possibly thinking of a typical sprint where we do not pull in our expected quota of points but leave room for defect work to a reasonable level and let some defect work stay on the backlog.

2 Answers 2


Both Scrum and Kanban have well defined processes and constraints.

ScrumBan, however, is not so clearly well-defined. It is, put loosely "something in-between Scrum and Kanban".

If you want a potential example, one approach would be to have it be the same as Kanban, except with sprints. You have a 'backlog' column on the far left, and a 'Selected for Development' column on the second-to-the-left. Every sprint, you pick X stories and move them from the first column to the second.

Of course, since the mandate is coming from your company, the best answer is that you should ask them what they want/expect.

  • That is what I have assumed after reading, for example, this: deloittedigital.com/us/blog/… However I didn't want to go off without getting informed properly.
    – Matt W
    Commented Sep 19, 2017 at 15:51

FWIW, let me add another response here.

I would have answered the question slightly differently from Sarov in that I'd say "...one approach would be to have it same as Scrum, except with a Kanban style visualization board, and Kanban concepts of WIP Limits and Pull."

Kanban is not a software or project management methodology by itself. It is a visualization and improvement method that can only be applied to an existing method, be it waterfall or Scrum or others, including non-software, non-IT processes. So you might even consider simply applying Kanban to your current waterfall process to get the benefits of Kanban.

I just responded to a similar question so I will post that link here - hopefully, that is OK with the StackExchange powers that be :)


Also, just to share with you our own story - we are a software house that now uses Kanban for all our product development. We were a 'waterfallish' company earlier - we never adopted Scru and moved directly to Kanban.

We also made changes to our Engineering practices where we adopted a TDD approach to development and adopted Test Automation and now, increasingly, Continuous Integration/ Continuous Deployment practices.

It has taken us 3-4 years to evolve - and our Kanban board - which has gone thru multiple revisions - looks like this -

enter image description here

However, from being a 2 minor and 1 major release a year back in 2009, we are now a "monthly release like clockwork" organization. We deploy both on SaaS as well as to out on-prem customers, so it is possible to support both.

We have experienced significant business benefits as our customers see us to be very responsive to their needs (due to frequent releases based on customer feedback and suggestions), our CEO is happy as we deliver regularly so the fear of "missing a major release or release date" is no longer there, and employees are happy as no one is pushing them to do too many things at a time (Kanban's focus on reducing multi-tasking) and holding them accountable for estimates, etc.

I am not sure I fully understand your keenness to have sprints not only due to the desire to deliver to the market more frequently or but because you also want to plan defect fixes properly. However, that IS an important consideration whether you do sprints or not.

Kanban helps you reflect this reality that many software teams face - of working on both "value demand" (new features/ user stories) and "failure demand" (defects), by either visualizing them with different colors or in different swim-lanes (as you see on the image above, altho' we use swim lanes for different products; for us the card colors are the way to distinguish between work items of different types). The interesting thing is that while our user stories come from an upstream separate Kanban board we use for our roadmap planning (so that is our backlog), the defects (both customer-reported and internally found) are directly added to the Ready column of the swim lane and typically get a higher priority than everything else. As soon as a developer who can work on a defect is free, they will pull the defect and work on it first.

We do releases roughly on a monthly cadence, but we also have a 'soft'policy of making a release when we have enough of value done and ready to deploy (say, 15-20 users stories and defect-fixes).

In addition to the basic Kanban tools above, we also religiously follow some of Kanban's practices - the bi-weekly Replenishment Meeting to prioritize what will go next in our upcoming releases, and a Month Retrospective for lessons learned and a Quarterly Strategy Review meeting to make sure all stakeholders are aligned to what the product team is doing. Of course, the Daily Standup is the basic team-level meeting.

Hope this helps - not sure you will get prompted about this response as you have already marked another answer as the right answer :-) You can read more about Scrumban here. And if you need, I will be happy to answer any questions you have about your transition - good luck with that!

  • Thank you. That’s s great answer. I’m rather between a rock and a hard place but it is great to have input like this. I’m interested in how you define kanban as not a methodology. My understanding is that scrum and kanban working together make your process ScrumBan. I understand they are not contrary and can work well together but that I believe they are both agile processes.
    – Matt W
    Commented Oct 18, 2017 at 18:52
  • You might want to read the book by David Anderson - "Kanban: Successful Evolutionary Change for your Technology Business (play.google.com/store/books/details?id=RJ0VUkfUWZkC) where he's originally spelt out the Kanban Method in great detail for software and IT teams and other knowledge workers. Commented Oct 18, 2017 at 19:17
  • Sorry - hit the Enter button and it saved a partial comment - I wanted to add - You are right that both are Agile methods - in that Kanban helps you become Agile in all respects (and David coined the phrase "Kanban: Alternate Path to Enterprise Agility"). However, as he spelt it out in the book, the Kanban Method needs to be applied to an existing method. WIthout that, Kanban has no prescribed process or development methodology. You start by visualizing whatever is your current method - and then gradually improving it to achieve greater Flow and Throughput and remove all impediments to Flow. Commented Oct 18, 2017 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.