How do you do Scrumban

Question

Current organisation wants to operate in a Kanban way but maintain the structure of sprints and burn down charts to keep track of progress. Is Scrumban the correct methodology? If so, what is the best way to implement it?

Answer 1

Scrumban is really just the application of the principles of the Kanban method on your Scrum processes. Kanban's fundamental principles are -

1. Visualize your current process
2. Implement WIP Limits and the Pull method; and
3. Improve Flow by addressing any process bottlenecks and evolve gradually

So, the fact that the team wants to retain the tenets of Scrum and "work in a Kanban way" is perfectly fine. Start by defining the Kanban board that visualizes the process your scrum team uses to develop, test and deliver/ deploy the user stories. Instead of just the Ready-Doing-Done board, expand the Doing column into each step the user story goes through. Once you get used to that, implement WIP Limits on each stage/ step - to reflect the maximum amount of work that should be there in each step at a time. Kanban reinforces the principle of reducing multi-tasking and finishing what you've already started before taking up anything new. (STop Starting. Start Finishing!).

Your Kanban Board might look like the one below - of course you'd model your actual process:

The main swim lane tracks your user stories. If you like, you can have a separate lane to track the tasks associated with each user story - though that is optional. The user story swim lane is the one that visualizes the actual process that your user stories go through - and will help you identify bottlenecks or problem areas where your stories tend to slow down and pile up due to reasons such as hand-off delays, external dependencies (waiting for a customer confirmation, or an infra team to complete some provisioning task, etc.)

In the meantime, you should continue to use various aspects of Scrum such as the 2 or 3-week time buckets, metrics such as burndown or velocity charts and other Scrum-related ceremonies that are working well for your team. As you use Kanban effectively, especially WIP Limits and other concepts such as Class of Service for prioritizing work and committing to SLAs, you might decide to make changes to your overall process that could include dropping some Scrum related concepts such as the time buckets of 2 or 3 weeks, estimation, etc. as Kanban will help you deploy more continuously and give you the ability to make forecasts of what you can complete in a given amount of time.

You may also choose to adopt additional metrics such as the Cumulative Flow Diagram, Lead Time and Flow Efficiency while dropping the Burndown chart since you might no longer be doing estimation or tracking hours.

To learn more about Scrumban, you can look here - What is Scrumban? - which provides some more details and also references other experts on the topic of Scrumban, such as Core Ladas and others, that you might enjoy.

Hope this helps. If you need more help on how to implement Scrumban, you can reach out to me separately - I'd be happy to help.

Answer 2

Well, to invent the bicycle you can use this word. The thing is it's used by different people in different ways (the word scrumban).

I've practiced that, when we at SkuVault had the phantom need to preserve sprints (until jira had the Backlog Kanban feature).

We used sprints as folders more, and I've experienced the pain of migrating batch of tickets from sprint to sprint (spoiler: we've moved to Kanban fully, and happily living everafter). I've explained that in my blogpost (https://kiniabulatov.com/2017/07/17/why-we-finally-ditched-scrum/), so will citate a bit:

We used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow. So that sprint-folder system was great, visible and allowed us to predict.

Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.

Answer 3

I have read Marat Kinyabulatov’s answer and his blog post about their experience. It’s very interesting. However, it seems to me they are more into Product Management than Project Management and that could explain why Scrum or Scrumban is not suited for their needs.

Scrumban can be used with success in some contexts. Being Agile is also to adapt the framework to your needs. Therefore, you can decide which elements of Scrum you wish to implement.

I have in the past created a team using Scrumban. Basically, I kept the grooming sessions, the planning sessions I and II but I dropped the sprint reviews with the clients and the retrospective with the velocity analysis. This was the right way address many rapid short-term requests from several clients throughout the year while keeping an eye on their long-term objectives. We needed planification with a lot flexibility. Scrum was too strict for this and Kanban was not precise enough. So I took what I needed.

Hope it helps!

Answer 4

In the above answers few important points were missed, like roles and ceremonies, but let me do a short summary first:

Scrumban in essence is a reduced variation of scrum methodology, focusing a lot on Kanban Board principle for continuous work throughput. But nonetheless, scrumban can have iterations/cycles, dedicated roles and ceremonies.

I think it is the best solution for early adopters and product teams that are in the early life cycle of a product, because it puts less overhead and constraints. If you would like to dive deeper into all ceremonies and best practices of read more what is scrumban.

If you would like to see scrumban board examples - check here.

Answer 5

Have tested many ways when it comes to kanban. I know the board changes depending on the organization; however, just wanted to share the model which works best for me. It may help others.

Quick column translation:

• Análise = under analysis
• Desenvolvimento = Development
• Testes = Test
• Pronto = Done

I saw this kanban board in a blog and since then, it was the best choice for me and the team.