A escolha entre Scrum, Kanban ou uma abordagem Híbrida para a gestão de projetos em times de dados depende das características do trabalho e da equipe. Não há uma resposta única, pois cada metodologia possui pontos fortes para diferentes cenários.
[caption id="attachment_6042" align="alignright" width="186"]
Escrito por Mariani Sfredo, Gerente de Projetos da Onetopia[/caption]
SCRUM
O Scrum é uma metodologia ágil que utiliza iterações de tempo fixo (sprints), com papéis e cerimônias bem definidos, ideal para projetos com requisitos claros e prazos fixos. Para o time de dados, suas vantagens incluem a entrega de valor ao cliente por meio de entregas incrementais, ritmo regular e previsível para a equipe de melhoria contínua. Por outro lado, é menos adaptável a mudanças que surgem durante um sprint, visto que, sua estrutura é mais rígida e pode não se adequar à natureza exploratória de alguns projetos de ciência de dados.
KANBAN
O Kanban é um método visual de gestão de fluxo de trabalho que se adapta a mudanças constantes e prioridades dinâmicas. Foca em limitar o trabalho em progresso (WIP) para evitar sobrecarga e identificar gargalos. Com menos cerimônias e papéis, a sobrecarga de gestão é menor e permite a entrada de novas tarefas a qualquer momento, sendo ideal para demandas urgentes. Com isto, ele se torna adequado para projetos de natureza mais exploratória, onde os resultados não são totalmente previsíveis.
Por outro lado, a menor rigidez pode dificultar a gestão de projetos complexos, se não houver disciplina, visto que não tem sprints com prazos fixos, tornando assim o ritmo de entrega menos previsível.
SCRUM+ KANBAN = SCRUMBAN
A abordagem híbrida, como o Scrumban, combina o melhor do Scrum e do Kanban. Geralmente, utiliza a estrutura do Scrum (sprints, reuniões) e a visualização e gestão de fluxo de trabalho do Kanban. Ainda, permite a entrega contínua, enquanto mantém a cadência das reuniões de planejamento e retrospectiva. No entanto, essa unificação também traz complexidade, ou seja, pode ser mais complexo para implementar, exigindo uma boa adaptação das práticas. Outro ponto é que há o risco de criar um processo excessivamente burocrático se não for bem ajustado.
Afinal, como funciona?
No Scrumban, a equipe mantém um backlog priorizado e utiliza quadros visuais para organizar fluxos de trabalho. A iteração não é rigidamente definida como no Scrum, permitindo revisões contínuas, mas preserva a lógica de metas incrementais. Esse modelo possibilita que engenheiros de dados trabalhem em tarefas de infraestrutura enquanto cientistas de dados conduzem experimentos, sem que o fluxo de trabalho seja interrompido por sprints fixos.
Quando usar:
Scrum é mais útil quando há necessidade de entregas incrementais claras, como construção de dashboards ou features de produto.
Kanban se adapta melhor a times de operação de dados e suporte a pipelines.
Modelos híbridos permitem unir a cadência de Scrum com a fluidez do Kanban, comum em times maduros de DataOps.
Benefícios: maior previsibilidade, alinhamento entre engenharia e negócio, e menor taxa de retrabalho por falhas de comunicação.
Caso de Uso
- Contexto
E-commerce nacional com arquitetura Lakehouse (Bronze/Silver/Gold), alta variabilidade de esquema e incidentes de qualidade (duplicidade, atraso, inconsistências de reconciliação).
- Objetivo
Reduzir o lead time de mudanças em pipelines analíticos e elevar a confiabilidade para consumo diário (SLAs intra-dia) e modelos de ML.
- Abordagem
Scrumban para governança do fluxo (limites de WIP por trilha; classes de serviço “Expedite” e “Standard”; políticas explícitas); DataOps para automação (CI/CD, testes de dados de esquema/completude/unicidade/frescor, observabilidade com SLIs/SLOs, promoções Bronze→Silver→Gold com gates).
- Operação
Pull por capacidade; PR aciona suíte de testes e checagens de compatibilidade; gates aprovam promoção e atualização de catálogo; incidentes seguem swimlane dedicada com post-mortem e ações preventivas.
- Resultados (4 semanas).
- Lead time Silver 12→5 dias;
- Taxa de falhas por release 18%→5%;
- Atraso médio T+1d→T+2h;
- Incidentes/1.000 execuções 3,2→0,6;
- MTTR 6h→1h40; acurácia em dashboard financeiro +2,1 p.p.
- Lições
- Políticas de fluxo + WIP são determinantes para previsibilidade;
- Testes de dados evoluem com o domínio e devem ser tratados como ativos de produto;
- Gates objetivos evitam vazamento de dívida técnica para a Gold;
- Observabilidade reduz ambiguidades ao ancorar decisões em SLIs/SLOs.
Comparação/ Alternativas
| Critério | Scrum | Kanban | Scrumban (híbrido) |
| Natureza do trabalho | Requisitos claros, iterações com metas definidas | Fluxo contínuo, demanda variável, trabalho operacional/expedite | Portfólios mistos (infra, qualidade, exploração) |
| Planejamento | Sprints time-boxed, Sprint Goal | Planejamento contínuo por políticas de fluxo | Cadência leve (reviews/retro) + fluxo contínuo |
| Mudanças de prioridade | Restritas dentro do sprint | Entram a qualquer momento, conforme WIP | Balanceadas via classes de serviço e limites de WIP |
| Estimativa | Relativa (story points), velocity | Menos ênfase; foco em cycle time/throughput | Combina velocity para épicos com métricas de fluxo para operação |
| Governança e qualidade | Definição de DoD e artefatos formais | Políticas explícitas, limites de WIP, SLAs de fluxo | Gates Bronze→Silver→Gold + SLIs/SLOs, contratos de dados |
| Riscos comuns | Rigidez frente a trabalho exploratório | Entropia/“caixa de entrada infinita” sem políticas | Complexidade inicial; risco de burocracia se mal ajustado |
| Métricas recomendadas | Velocity, burndown, cumprimento do Sprint Goal | Cycle time, WIP aging, throughput | Conjunto híbrido + frescor/completude/unicidade e taxa de falhas/MTTR |
Boas Práticas/ Dicas
- Incluir no backlog métricas de qualidade de dados, não apenas entregáveis de software.
- Usar quadros visuais para mapear dependências entre engenharia e ciência de dados.
- Reavaliar papéis: o Product Owner precisa entender conceitos de dados; o Data Steward deve participar das discussões.
- Promover retrospectivas focadas em impacto de negócio, não só em métricas técnicas.
Conclusão
A gestão de projetos de dados exige um arcabouço adaptativo que una agilidade, governança e qualidade ponta a ponta. Abordagens híbridas, como Scrumban combinada a DataOps, são eficazes para equilibrar exploração e engenharia robusta, garantindo cadência com limites de WIP, automação de testes e observabilidade guiada por SLIs/SLOs. A relevância tende a crescer com nuvem, fluxos quase em tempo real, regulações mais rígidas e a incorporação de IA, tornando práticas como data contracts como código, promoções controladas Bronze→Silver→Gold e monitoramento contínuo requisitos mínimos para produtos de dados confiáveis.
Como plano imediato, recomenda-se: formalizar três SLIs críticos (frescor, completude, unicidade); instituir gates de qualidade antes de cada promoção entre camadas; iniciar um piloto Scrumban com políticas explícitas de WIP e classes de serviço, integrado a uma esteira de CI/CD para dados. Esse conjunto eleva a maturidade operacional e acelera a experimentação com risco controlado.
Qual dessas práticas você já aplica — e qual será a primeira a ser institucionalizada no seu time nas próximas quatro semanas?
Material Complementar
- Kanban Guide for Scrum Teams (Scrum.org) — aplicação de práticas Kanban em times que operam com Scrum. scrumorg-website-prod.s3.amazonaws.com
- DataOps Manifesto — princípios para operacionalizar dados com foco em fluxo, automação e qualidade ponta a ponta. dataopsmanifesto.org
- Repositório “Awesome Agile” (GitHub) — curadoria de materiais sobre fundamentos, métricas e adoção ágil
