Scrum e Kanban: entenda as diferenças e qual escolher

Você está lendo este artigo e esperando que ao final dele eu te conte qual framework ágil é o melhor de todos? Preciso ser sincero e te informar que essa não será a resposta. 

Já te explico o motivo: 

Escuto muito as pessoas colocarem Scrum e Kanban em uma batalha no mundo ágil em que precisa ter um vencedor, mas isso não é verdade. 

Antes de compararmos as duas ferramentas mais populares para desenvolvimento de software hoje, precisamos entender melhor sobre ambas. Para entender o que significa cada uma delas e suas diferenças continue lendo o artigo. 

Framework Scrum vs Framework Kanban

Entendendo a duração e os objetivos de cada um deles

O Scrum é uma ferramenta time-boxed, com duração igual das Sprints (ex: 2 semanas), em que as equipes definem quais estórias devem ser desenvolvidas naquele Sprint. 

Durante esse período de tempo, a equipe ficará focada em desenvolver aquelas estórias, para que ao final da Sprint, algo de valor seja entregue.

Diferente do Scrum, o Kanban não possui time-box de desenvolvimento e seu trabalho deve ser constante. Um dos principais objetivos do Kanban é a eliminação de desperdício, ajudando equipes a ajustar seu fluxo de valor para que o trabalho seja entregue o mais rápido possível – e com qualidade.

Planejamento Scrum e planejamento Kanban

Em times Scrum, o planejamento acontece sempre antes de cada Sprint. As estórias que estão no backlog são estimadas pelo time utilizando Story Points (ou qualquer outro método de estimativa) e são selecionados de acordo com prioridade e com a capacidade do time de produção.

No Kanban, não há um rito fixo para planejamento. As estórias são adicionadas ao fluxo de valor conforme vão sendo priorizadas e repriorizadas. Esse processo ajuda a evitar os desperdícios, uma vez que as tarefas vão sendo adicionadas de acordo com a necessidade.‍

Métricas & Gráficos 

As principais métricas medidas em times que rodam o Scrum são Velocity (produtividade de cada Sprint) e Projected Capacity (capacidade do time projetada – baseado no seu time atual). Para acompanhamento dos times, utiliza-se os gráficos de Burndown ou Burnup e também a Velocity Chart, como apresentado abaixo.‍

‍

‍‍

No Kanban, as métricas são diferentes. Entre as principais métricas, estão o Lead Time – tempo entre a entrada da demanda no board até a sua entrega – e Cycle Time – tempo entre dois status pré-selecionados. 

‍

Além das métricas, os gráficos também são diferentes. Os times costumam utilizar o CFD (Cumulative Flow Diagram) para entender gargalos e métricas.
‍

Board & Acompanhamento

No Scrum, os times costumam utilizar apenas 3 status para as tarefas do Sprint: To do, In progress, Done. Eles são o termômetro para saber o trabalho que está sendo feito, o que ainda temos pendente e o que já foi realizado. O board é reiniciado toda vez que uma nova Sprint é iniciada para que o seu controle seja apenas da Sprint atual, tornando seu controle muito mais simples e organizado.

Já no Kanban, o board deve refletir a vida de uma demanda, desde a sua criação até o término. O board nunca é resetado (como no Scrum) e ele vai sendo alimentado com novas estórias. Para uma melhor utilização do Kanban, o board deve ser sempre lido da direita para a esquerda (o que está mais próximo de ser finalizado, deve ter prioridade). 

São exemplos de status no Kanban: To do, Prototyping, Developing, Testing, Done, por exemplo. Esse fluxo é chamado de Value Stream Map.

Por conter cada estado do seu fluxo, é muito mais fácil enxergar gargalos no Kanban. Se você tem muitas tarefas na coluna de Prototyping, você pode fazer um deep-dive para entender por qual motivo as tarefas estão demorando muito tempo para saírem dessa coluna.

Leia também Java vs Kotlin: Vantagens, Desvantagens e Performance

Concluindo...

A verdade é que, não existe um framework melhor que o outro em todas as situações. Suas utilizações são situacionais e dependem muito do contexto. Importante é que nenhum desses frameworks seja imposto por algum líder dentro dos times. Quem deve tomar a decisão do que é melhor para a organização do time é o próprio time. Qualquer framework que seja “instalado” pode gerar desconforto e burocratizar o processo de desenvolvimento.

Para cada situação é preciso entender sua necessidade

Em times onde as demandas são melhores organizadas e planejadas, acredito que o Scrum saia na frente do Kanban. Digo isso pois o Kanban é um framework que precisa de muita maturidade do próprio time para sua utilização. 

No Scrum, o trabalho torna-se mais organizado com as sprints e a gestão da equipe é mais fácil. Contudo, em times que as demandas são mais voláteis, o Kanban larga na frente, pois a entrega é contínua e a repriorização também.

Vale lembrar que a adesão do time é o principal fator na escolha de um framework. Se a equipe não está feliz com a metodologia de trabalho adotada, tenho certeza de que a produtividade jamais será otimizada, qualquer seja o framework. 

‍

A equipe precisa entender os benefícios da metodologia adotada, para que façam o melhor uso e possam evoluir seu dia a dia.

‍

Por fim, evoluir e criticar o processo é o principal fator de sucesso das equipes. Não importa o framework que você esteja utilizando, procure sempre pontos que podem ser melhorados no seu processo, de acordo com feedback da sua equipe.

Eles são a chave do sucesso – não o framework que você utiliza.

E você, qual sua experiência com esses dois frameworks? Conta pra gente nos comentários! 

‍

É um profissional da área? 

Veja aqui nossas vagas abertas de desenvolvimento.