Scrumban na escola: o que sobrou depois de sete anos

O que acontece quando um método de software é aplicado à coordenação pedagógica por sete anos: a tradução de cada termo, o que precisou ser adaptado e o que sobrou.

Publicado em 16 de setembro de 2026 · Por Fábio Santana, fundador da Expertia

Antes de explicar o método, o contexto

A Expertia coordena o trabalho pedagógico do Colégio Mirim em Scrumban há sete anos. Não é um piloto, não é um estudo de caso montado depois, não é uma consultoria que passou um semestre e foi embora: é a operação que sustenta o planejamento de uma escola de educação básica, bimestre após bimestre, desde então. O Bordi nasceu disso — o software veio depois do método, e não o contrário.

Este texto existe porque a pergunta aparece sempre que alguém de fora da tecnologia ouve a palavra pela primeira vez: por que uma escola usaria um método de desenvolvimento de software?

A resposta honesta é que ela não usa. Usa o que sobrou dele depois de sete anos batendo contra a realidade de um calendário escolar. É isso que está descrito aqui, incluindo as partes que foram descartadas.

O que é Scrumban, em uma frase

Scrumban é a combinação de duas coisas: o ciclo com data do Scrum (um período fechado, com o que foi combinado no começo e uma revisão no fim) e o quadro visível do Kanban (o trabalho como cartões que caminham por colunas de estado, com a regra de não abrir frentes demais ao mesmo tempo).

Em ambientes de software, ele costuma ser adotado por equipes que acham o Scrum rígido demais e o Kanban solto demais. Numa escola, a razão de ser é outra e mais simples: o ciclo já existe. O bimestre não foi inventado por ninguém para organizar trabalho — ele está lá, com data de início e de fim, e todo mundo já organiza a vida em torno dele. A metade “Scrum” do método não precisou ser introduzida; precisou ser reconhecida.

A tradução, termo a termo

Esta é a parte que interessa a quem coordena, e é onde a maior parte das tentativas fracassa: quando o vocabulário do método chega antes do benefício, a equipe rejeita. Por isso, na operação real, os termos abaixo praticamente não são ditos em voz alta. Cada um é nomeado pela coisa da escola que ele já descreve.

Sprint → o período. No Scrum, o sprint é um intervalo fechado de duas a quatro semanas. Na escola, ele é o bimestre, ou um recorte dentro dele — a semana de provas, o mês do conselho. A regra que importa não é a duração: é que o período tem uma data de fechamento, e o que não foi entregue até lá é decidido explicitamente (vai para o próximo, muda de responsável, ou deixa de ser necessário) em vez de escorregar em silêncio.

Backlog → o que a escola sabe que precisa fazer. Nome de software para uma coisa banal: a lista de tudo que está combinado e ainda não entrou em nenhum período. Toda escola tem essa lista; o que quase nenhuma tem é a lista em um lugar só. Ela mora, tipicamente, em três: o caderno da coordenadora, o grupo de mensagens e a memória da vice-diretora.

Story → a frente de trabalho. No método, a “história” é uma unidade de entrega com valor próprio. Na escola, é a frente: Semana de provas do 2º bimestre, Conselho de classe do 7º ano, Feira de ciências. Não é um projeto (grande demais) nem uma tarefa (pequena demais). É a coisa que a coordenação nomeia naturalmente quando conta o que está acontecendo na escola.

Task → o que a frente exige de alguém. Dentro da frente, os itens com dono e data: calendário de provas, revisão dos conteúdos, impressão e malotes. É neste nível que o trabalho é distribuído, e é neste nível que o prazo faz sentido.

Quadro → as quatro colunas. Não iniciado, Iniciado, Aguardando validação, Concluído. A terceira coluna é a adaptação escolar mais importante do método e vem explicada adiante.

Limite de trabalho em andamento → quantas frentes a escola aguenta ao mesmo tempo. No Kanban, é uma regra numérica. Na coordenação, é a pergunta que ninguém faz antes de dizer sim: se a feira de ciências, a semana de provas e a formatura acontecem no mesmo mês, alguma delas vai ser mal feita — qual? O método não responde. Ele só força a pergunta a ser feita em abril, e não em maio.

O que precisou ser adaptado

Aqui está o valor real de sete anos: saber o que não funciona.

O calendário não é negociável

Em software, quando o prazo aperta, reduz-se o escopo. Na escola, a prova é na terça-feira. Não tem “entregar uma versão mais simples da semana de provas na semana que vem”. O calendário letivo é dado, e o método precisa operar dentro dele em vez de propor um ritmo próprio.

A consequência prática: o ciclo é definido pelo calendário da escola, nunca por uma cadência fixa de duas semanas importada do manual. Um período pode ter três semanas e o seguinte, cinco.

Ninguém é dedicado

A equipe de um time de software trabalha naquilo. O professor dá aula. O trabalho de coordenação acontece nos intervalos, nas janelas, depois do horário — e é a primeira coisa a ser atropelada quando um colega falta e alguém precisa cobrir a turma.

Isso mata qualquer ritual que dependa de reunir todo mundo com frequência. As cerimônias diárias do Scrum não pegaram. O que substituiu foi o sistema avisando: a formalização do que é de cada um quando o período começa, lembretes conforme o prazo se aproxima, e um resumo semanal. A informação circula sem custar uma reunião.

Não há dono de produto — há coordenação

No Scrum, quem prioriza é o dono do produto, e quem aceita a entrega é ele. Na escola, quem prioriza e quem aceita é a mesma pessoa: a coordenação. E a aceitação não é um detalhe processual — é a função. Por isso a coluna Aguardando validação é estrutural e não opcional: entre “o professor terminou” e “está encerrado” existe alguém que precisa olhar, aprovar ou devolver com o motivo escrito.

Essa coluna não existe no Scrumban de manual. Foi acrescentada pela operação, e é a parte que mais diferencia o quadro de uma escola do quadro de qualquer outra organização.

Estimativa não sobreviveu

Pontos de história, velocidade, gráficos de queima: nada disso foi adiante. O motivo é o segundo item desta lista — sem dedicação, a variação entre um período e outro é maior do que qualquer estimativa, e medir a velocidade de uma equipe que não controla o próprio tempo produz números que parecem informação e não são.

O que ficou no lugar foi mais simples e mais útil: o tempo real de cada frente, medido do início à conclusão. Não serve para prever; serve para responder à pergunta que a direção faz no fim do bimestre — quanto custou a semana de provas? — com horas em vez de impressão.

O jargão foi retirado de propósito

A regra que sobrou, e que hoje é princípio de produto: o benefício do método sem o vocabulário do método. Uma coordenadora não deveria precisar aprender a palavra “sprint” para ter um período com data de fechamento. Termo de framework na tela é dívida, não precisão — e é o caminho mais curto para a equipe decidir que aquilo é coisa de TI.

Esta página é a única exceção do produto inteiro. Aqui o nome aparece porque quem chegou até aqui quer saber exatamente de onde o método veio.

O que sobrou depois de sete anos

Retirado tudo que não resistiu, o que continua de pé é curto:

  1. Um período com data de fechamento, definido pelo calendário da escola.
  2. Frentes de trabalho nomeadas como a escola as nomeia, com as tarefas dentro.
  3. Responsável e prazo em cada tarefa — nunca “a equipe”, nunca “em breve”.
  4. Uma etapa de validação entre terminar e encerrar, com o motivo escrito quando há devolução.
  5. O acompanhamento saindo do sistema, não da coordenadora.
  6. Cada pessoa vendo apenas o que é dela, porque comparação entre pares destrói adesão.

Nenhum desses seis itens é uma ideia nova. O que sete anos ensinaram foi principalmente o que remover: a cadência fixa, as cerimônias diárias, a estimativa, o vocabulário. O método ficou menor e passou a caber na rotina.

O que não recomendamos copiar

Se alguém quiser repetir isso na própria escola, dois avisos que teriam economizado tempo aqui:

Não comece pelo quadro. Comece pela lista do que está combinado e não tem dono. Um quadro sobre um combinado vago só torna o vago mais visível.

Não tente converter a equipe ao método. A equipe não precisa saber o nome de nada. Ela precisa receber o que é dela, com data, e saber a quem avisar quando travar. Todo o resto é trabalho da coordenação, e deve permanecer invisível para quem executa.

Para ver como esses seis itens se distribuem ao longo do bimestre — planejamento, conselho de classe, semana de provas, acompanhamento de plano de aula —, o ponto de partida é a rotina da coordenação pedagógica.