Scrumban.

O que o Scrumban é, de facto

O Scrumban mantém as partes do Kanban e do Scrum que se pagam e descarta o resto. Do Kanban, fica com o quadro visual, o fluxo de trabalho por colunas e os limites de trabalho em curso — o que torna o fluxo legível. Do Scrum, fica com o sprint de duração fixa — o que transforma um backlog num plano.

O que ele salta: dailies, reuniões de grooming do sprint, cerimónias de story points, retrospetivas como ritual. Isso funciona para dez engenheiros numa organização bem afinada; não funciona para um fundador a tentar entregar num sábado.

Porque é que o Weft escolhe o Scrumban

O Weft existe porque a maioria dos gestores de tarefas foi moldada para um de dois extremos: ou uma app de lista de afazeres solitária (lista infinita, sem cadência) ou uma suíte Agile para cinquenta pessoas (sobrecarga de processo para um fundador de uma pessoa só). O Scrumban fica exatamente no meio — estrutura suficiente para forçar uma entrega semanal ou quinzenal, não tanta que passe o dia da entrega a administrá-la.

Como o Weft implementa isto

• Quatro colunas por omissão: Backlog, Todo, Doing, Done. Pode adicionar limites de WIP por coluna.
• Um sprint ativo de cada vez. Os sprints são opcionais — salte-os se o Kanban puro servir.
• As tarefas têm prioridade, estimativa, prazo e uma ligação opcional a um sprint. Sem épicos, sem workflows, sem campos personalizados.
• O tempo de ciclo começa quando uma tarefa entra numa coluna com semantic="doing" e termina em "done". Os números saem do uso honesto, não da aritmética de story points.

Quando o Scrumban não é o método certo

• Conduz várias equipas Scrum ao mesmo tempo. Relatórios ao nível do programa, velocidade partilhada, dependências entre equipas — o Scrum completo no Jira justifica-se.
• Faz suporte puro / operação contínua. Não precisa de cadência de sprint — Kanban puro ou um sistema de tickets serve melhor.
• Precisa de gráficos de Gantt e cronogramas. O Scrumban é focado em sprints, não em grafos de dependências.