How to manage the board in Scrumban

Question

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.

Answer 1

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.

Answer 2

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 :)

https://pm.stackexchange.com/a/22628/8132

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 -

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!