Is "Scrumban" just a bridge to full Kanban, or is it a viable long-term hybrid framework?

All answers to this question.

Scrumban is a very legitimate framework, often used by teams that have outgrown the "training wheels" of Scrum. It’s perfect for mature teams that don’t need the pressure of a 2-week deadline to stay productive. You keep the roles and the feedback loops of Scrum, but you adopt the pull-system and WIP limits of Kanban. This reduces the "end of sprint" rush which often leads to poor code quality. It isn't lazy; it actually requires more discipline because you have to manage flow constantly rather than just during a planning meeting every two weeks.

   Answered 2024-02-12 by Susan White

How do you handle long-term forecasting in Scrumban without the velocity metrics that come with fixed sprints? Our stakeholders are very attached to their burn-down charts.

   Answered 2024-02-15 by Richard Miller

• Richard, we replaced burn-down charts with "Monte Carlo Simulations" based on our Kanban cycle time. It actually provides a much more realistic probability of when work will be finished (e.g., "There is an 85% chance we will finish by Oct 1st"). Stakeholders actually preferred this once they realized it accounted for variability better than a simple velocity average ever could.

     Commented 2024-02-18 by Paul Nelson

Scrumban is excellent for maintenance and support teams. It allows them to use the structure of Scrum to stay aligned while handling the flow of Kanban for tickets.

   Answered 2024-02-21 by Linda Garcia

• I agree, Linda. We’ve been using Scrumban for two years now, and the team's' stress levels are much lower than they were during our "Pure Scrum" days.

     Commented 2024-02-23 by Kimberly Reed