---
description: TechWell Hub Community
---

# Implementing Scrumban

### Case Study:

Can anyone share their experience and implementing Scrumban to their org? Trying to understand if there is any specific strategies besides scrum+kanban that Scrumban recommends? Want to some suggestions along with notes/sites to refer to apply that framework to our new platform.

#### Recommendation 1:

In my experience, most Scrumban comes from Scrum teams that add WIP limits to their Sprint board so they can focus on getting the highest priorities done before starting other work. It is often on the way for the team to move toward Continuous Delivery, meaning a more flexible release schedule so they can release more often than at the end of a sprint.

Certainly not following the Scrum cadence. Don't get me wrong, Scrum has a lot of value for the right circumstance but like any tool it has to fit the job. I would say the same of Kanban, great value for a specific circumstance.

Fair and I can see that being true for some projects. I still find in some places planning from a business perspective to be needed and often find that if the business is planning out for 3 months the dev teams want to know that plan. Generally that means an overview for a few hours a quarter and not a 1-week release planning session.&#x20;

Given multiple levels of planning, I can see 3 month plans being little more than goals of ideas for goals in the future with more detailed planning with specific decisions being on a few day horizon basis. Certainly our experience can be different but I don't see many businesses that don't have big idea plans out months or longer. I do see making those immutable or in detail a problem. Meaning I see a lot of value in adjusting by what you learn and even adjusting longer term goals based on what you learn in your daily work. I do like describing your work as experiments. That can put learning in perspective.

\-- Tom Steihm

#### Recommendation 2:

In fact, I have not experienced a team that is doing CD that is using Scrum. They all move to Kanban as so many of the Sprint ceremonies are not relevant when you are deploying many times each day.

We found that release planning, sprint planning, demo, etc. not relevant. In CD things tend to be a lot more JIT.

In my experience planning out for 3 months seems counter to the way I’ve worked in CD. My experience is that the business specifies outcomes they hope to achieve and then the product owner with the team come up with a hypothesis about how to achieve the outcomes or some aspect of the outcome. Then experiments are run and the data collected from the experiments help inform they next set of experiments. In this mode, we really do not plan beyond the next few days and constantly make adjustments based on what we learn.

\-- cheezy

####

