O que é Scrumban?

Corey Ladas usou Scrumban em seus textos sobre sistemas Kanban para desenvolvimento Lean, inicialmente como caminho de evolução de práticas Scrum. O termo passou a designar arranjos variados. Scrum.org também documenta uma combinação específica chamada Scrum with Kanban, que acrescenta práticas de fluxo sem alterar o framework Scrum. A diferença entre esses usos deve ser explicitada ao descrever uma equipe.

Scrumban é um nome usado para combinar cadências e práticas associadas a Scrum com gestão de fluxo de Kanban. A palavra não define um conjunto único de regras. Algumas equipes mantêm o framework Scrum inteiro e acrescentam visualização, limite de WIP e métricas de fluxo. Outras deixam de usar Sprints e preservam apenas certas reuniões ou responsabilidades. Para entender uma implementação, descreva políticas reais em vez de presumir que o rótulo explica como o time trabalha.

Scrum com Kanban. Scrum.org explica que práticas Kanban podem complementar Scrum sem alterar suas responsabilidades, eventos e artefatos. O time mantém Sprint Goal, Sprint Planning, Daily, Review e Retrospective, mas define fluxo, limita itens simultâneos e observa tempo. Essa é uma combinação específica. Chamar qualquer quadro com colunas de Scrumban pode ocultar que o time não usa de fato limite, sistema puxado nem inspeção de resultados.

Fluxo visual. Desenhe os estados reais por onde um item passa, inclusive espera por revisão ou publicação. Cartões devem mostrar trabalho com início e fim definidos. O quadro Kanban torna bloqueios e acúmulo visíveis. Um quadro de Sprint com “a fazer, fazendo, feito” pode ser um começo, mas talvez esconda gargalos importantes. Ajuste detalhe ao que a equipe consegue usar para tomar decisões.

Limite de WIP. A equipe combina quantos itens podem permanecer em determinado estágio ou fluxo. Quando o limite é alcançado, a pergunta é como terminar ou desbloquear algo, não como iniciar mais trabalho. Isso reduz troca de contexto e revela restrições. O número inicial é uma hipótese; compare tempo, qualidade e capacidade antes de ajustá-lo. Um limite ignorado nas urgências diárias vira decoração.

Puxar trabalho. Em um sistema puxado, novo item entra quando há capacidade e uma política clara de seleção. Se há Sprint Backlog, o time pode puxar o próximo item dentro do objetivo do Sprint. Se opera fluxo contínuo, precisa decidir como reabastecer a fila e proteger prioridades. Puxar não significa que qualquer pessoa escolha livremente o que prefere; há acordos de valor, risco e classe de serviço.

Cadência. Times com trabalho previsível podem manter ciclos de Sprint. Equipes de suporte e manutenção talvez recebam demandas urgentes que pedem outra cadência de seleção. Antes de abandonar Sprints, investigue se o problema é realmente imprevisibilidade do serviço ou falta de política para urgências. Uma revisão periódica de resultado e uma retrospectiva continuam úteis mesmo sem Sprint, mas seu formato pode variar. A adaptação precisa manter oportunidades de feedback.

Métricas. Acompanhe WIP, throughput, tempo de ciclo e idade dos itens para entender fluxo. Uma Sprint bem-sucedida não impede que itens esperem semanas por aprovação depois do evento; medir ponta a ponta mostra esse custo. Em Scrum, métricas de fluxo podem apoiar decisões diárias e planejamento. Não compare produtividade individual por cartões. Pergunte se clientes recebem valor com mais previsibilidade e qualidade.

Produto e resultado. Melhorar fluxo não substitui descobrir o que vale construir. Product Owner e time precisam conectar seleção de itens a objetivo de produto ou serviço. Um quadro pode ficar rápido em entregar trabalho sem valor. Reveja com stakeholders o efeito das entregas e o que deve ser descartado. Se uma interrupção urgente consome grande parte da capacidade, sua origem pode ser problema de qualidade ou política de demanda.

Políticas explícitas. Escreva quando um item entra, como se marca bloqueio, qual trabalho pode interromper outro e o que significa pronto. A escolha de manter ou não eventos Scrum deve ser transparente. Se a organização afirma usar Scrum, não pode descartar partes essenciais e continuar tratando seu resultado como aplicação fiel do framework. Scrumban pode ser uma prática local válida, desde que os acordos permitam colaboração e aprendizagem.

Evolução. O termo surgiu em discussões sobre transição de Scrum para sistemas Kanban e foi desenvolvido por Corey Ladas. Hoje cobre implementações diversas. Evite importar um modelo sem examinar o trabalho. Comece com uma dor concreta, como excesso de itens simultâneos ou previsões frágeis, introduza uma política e observe seu efeito. A melhoria de fluxo é contínua, não um estado alcançado por renomear o método.

Exemplo hipotético: um time de manutenção usa Sprints de duas semanas, mas recebe incidentes que interrompem metade do trabalho planejado. O quadro mostra dez itens “em andamento” por pessoa e poucos concluídos. Antes de abandonar toda cadência, o grupo classifica tipos de demanda, estabelece limite de WIP de seis itens para o fluxo e reserva capacidade para incidentes reais. Mantém a revisão periódica com clientes internos e a retrospectiva.

Antes da mudança, a mediana de tempo de ciclo de solicitações padrão era 21 dias e quatro itens eram concluídos por semana. Em um período comparável hipotético, o tempo cai para 13 dias e cinco itens são concluídos, sem aumentar defeitos. Os números são ilustrativos. A equipe examina também se incidentes mudaram de volume; caso contrário, não poderia atribuir a melhora apenas ao limite de WIP.

O time decide manter Sprints para orientar uma meta de melhoria, mas usa fluxo puxado para executar os itens. Outro time poderia escolher cadência diferente. O ponto é tornar explícito como trabalho planejado e imprevisível convivem, sem transformar “Scrumban” em desculpa para ausência de foco.

Scrum with Kanban, na documentação de Scrum.org, preserva todo o framework Scrum e adiciona práticas de fluxo. Scrumban é um rótulo mais amplo, usado também para arranjos que mudam ou retiram cadências de Sprint. Nenhum nome substitui explicar como objetivos, seleção de trabalho, limites, revisão e melhoria acontecem. Ao comparar times, examine políticas e resultados concretos.

Cursos K21 recomendados