Noções de Scrum e Kanban

Nível: Iniciante | Duração estimada de leitura: 15 minutos | Categoria: Trilha Iniciante — Módulo 4

Introdução

Quando você entra em uma empresa como PO, alguém vai te perguntar em algum momento: "Você trabalha com Scrum ou Kanban?"

E a resposta honesta que ninguém dá é: depende do time, depende do produto, e às vezes é os dois ao mesmo tempo de formas que não estão em nenhum livro.

Scrum e Kanban são frameworks — conjuntos de práticas e princípios para organizar o trabalho de times que desenvolvem produtos. Eles não são religiões, não são concorrentes e nenhum dos dois vai resolver os problemas do seu time se os fundamentos de gestão de produto estiverem errados.

O que o PO precisa saber sobre esses frameworks não é o que está na certificação. É o que acontece na segunda-feira de manhã quando o time começa a sprint, quando o board está emperrado, quando a cerimônia não está funcionando.

É isso que você vai aprender aqui.

O que é Scrum

Scrum é um framework para desenvolver, entregar e sustentar produtos complexos em ambientes onde os requisitos mudam com frequência. Ele foi formalizado por Ken Schwaber e Jeff Sutherland no Scrum Guide — um documento de menos de 15 páginas que é a referência oficial.

O Scrum organiza o trabalho em ciclos fixos chamados sprints — geralmente de 1 a 4 semanas. A ideia central é simples: em vez de tentar planejar tudo de uma vez e entregar no final, você divide o trabalho em fatias, entrega valor de forma incremental e aprende com cada ciclo.

Os três papéis do Scrum:

Product Owner — Você. Responsável por maximizar o valor do produto gerenciando o backlog, definindo prioridades e garantindo que o time esteja construindo a coisa certa.

Scrum Master — O facilitador do processo. Garante que o time está seguindo as práticas do Scrum, remove impedimentos e protege o time de interferências externas. Não é gerente — é servo-líder.

Developers (time de desenvolvimento) — Todos os profissionais que trabalham para entregar o incremento do produto a cada sprint. Podem ser devs, designers, QAs. São auto-organizados e cross-funcionais.

Os três artefatos do Scrum:

Product Backlog — A lista ordenada de tudo que precisa ser feito no produto. Sob responsabilidade do PO. Você já conhece bem esse artefato do módulo anterior.

Sprint Backlog — Os itens selecionados para a sprint atual mais o plano do time para entregá-los. É do time, não do PO.

Incremento — O resultado da sprint: um conjunto de itens do backlog entregues que agregam valor e estão "prontos" (de acordo com a Definition of Done do time).

As quatro cerimônias do Scrum:

Sprint Planning — Reunião no início de cada sprint onde o PO apresenta os itens do topo do backlog e o time decide o que vai conseguir entregar. Resultado: Sprint Goal (objetivo da sprint) e Sprint Backlog definidos.

Daily Scrum — Reunião diária de 15 minutos do time de desenvolvimento para sincronizar o trabalho e identificar impedimentos. O PO geralmente não conduz — pode participar como observador.

Sprint Review — No final da sprint, o time apresenta o que foi feito para os stakeholders. O PO valida se os itens atendem aos critérios de aceitação. É aqui que o feedback entra.

Sprint Retrospective — O time reflete sobre como trabalhou (processo, ferramentas, relacionamentos) e define melhorias para a próxima sprint. O foco é no time, não no produto.

O que o PO faz em cada cerimônia (de verdade)

O Scrum Guide descreve os papéis em teoria. A realidade é um pouco diferente.

No Sprint Planning, o PO é a estrela. Você chega com o backlog refinado, histórias com critérios de aceitação claros e um Sprint Goal proposto. Apresenta os itens do topo, responde às perguntas do time e negocia o escopo. Se você chega no planning sem isso, a reunião vai durar o dobro e terminar com comprometimentos frágeis.

Na Daily, o PO não conduz e idealmente não participa de forma ativa. A Daily é do time de desenvolvimento para sincronizar entre eles. Se você participa, seja observador. Se toda vez que você entra na daily o time para de falar sobre impedimentos técnicos para te reportar status, é sinal de que algo está errado na cultura do time.

Na Sprint Review, o PO valida o que foi entregue e facilita o feedback dos stakeholders. É sua oportunidade de mostrar o que o time construiu, coletar insumos para o backlog e realinhar expectativas. Não deixe essa reunião virar apresentação de slides — mostre o produto funcionando.

Na Retrospectiva, o PO pode (e deve) participar, mas com humildade. A retro é do time. Evite dominar a conversa ou usar o espaço para cobrar entregas. Ouça. O que o time está dizendo sobre o processo muitas vezes revela problemas que você não consegue ver de fora.

O que é Kanban

Kanban tem origem no sistema de produção da Toyota nos anos 1950. No contexto de desenvolvimento de software, foi adaptado por David J. Anderson e se popularizou como alternativa ao Scrum para times que precisam de mais fluxo contínuo e menos estrutura de sprints.

A ideia central do Kanban é visualizar o trabalho e limitar o trabalho em progresso (WIP — Work in Progress).

Os princípios fundamentais do Kanban:

Visualizar o fluxo — Todo o trabalho é representado em um board com colunas que representam os estados possíveis de um item (ex: A fazer → Em progresso → Em revisão → Feito). Nada fica invisível.

Limitar o WIP — Cada coluna tem um limite de quantos itens podem estar nela ao mesmo tempo. Se a coluna "Em revisão" tem limite de 3 itens e já tem 3, ninguém começa um item novo — o time foca em desbloquear o que está parado.

Gerenciar o fluxo — O objetivo é que os itens fluam pelo board da esquerda para a direita o mais rapidamente possível, com o mínimo de interrupções e blockers.

Melhorar continuamente — O time analisa o fluxo regularmente (métricas como lead time e cycle time) e identifica gargalos para melhorar.

No Kanban, não há sprints fixas, não há sprint planning formal, não há papéis definidos pelo framework. O trabalho entra na fila conforme a prioridade e sai conforme a capacidade do time.

Scrum vs. Kanban: quando usar cada um

Essa é a pergunta que todo PO faz e que ninguém responde direito. Aqui está a versão prática:

Scrum funciona melhor quando o produto tem sprints fixas (1 a 4 semanas), planejamento por ciclo, resistência a mudanças durante a sprint, papéis bem definidos (PO, SM, Devs) e a métrica principal é a velocity — pontos entregues por sprint. Ideal para produtos com entregas incrementais claras e times que precisam de previsibilidade.

Kanban funciona melhor quando o ritmo é de fluxo contínuo, o planejamento acontece conforme a capacidade do time, mudanças são aceitas a qualquer momento e não há papéis obrigatórios definidos pelo framework. A métrica principal é o lead time e o cycle time. Ideal para operações, suporte e times com demanda variável e imprevisível.

Use Scrum quando o produto tem ciclos de descoberta e entrega bem definidos, o time tem estabilidade e você precisa de previsibilidade de entrega por sprint.

Use Kanban quando o trabalho é mais operacional ou de suporte, as demandas chegam de forma imprevisível, ou quando o time está maduro o suficiente para se auto-organizar sem a estrutura das cerimônias.

E na prática? A maioria dos times usa um híbrido — Scrum como estrutura base com elementos de Kanban (boards visuais, limites de WIP). Isso tem nome: Scrumban. Funciona bem e é mais honesto do que fingir que o framework de livro se aplica exatamente ao seu contexto.

O que o PO não precisa se preocupar

Parte do trabalho de crescer como PO é aprender o que não é sua responsabilidade.

A estimativa é do time. Como o time estima (story points, t-shirt sizing, horas) é decisão dos Developers. O PO pode participar do refinamento para esclarecer dúvidas, mas não deve pressionar por estimativas menores ou questionar metodologia de estimativa.

A Daily não é para você. Você não precisa saber o status de cada tarefa todo dia. Se precisar de atualização, converse diretamente com o dev fora da Daily — não use a cerimônia como check-in de gerente.

A Retrospectiva não é sua reunião. Você pode participar, contribuir e ouvir. Mas se o Scrum Master não estiver facilitando bem ou se o time não tiver psicológica segurança para falar, isso não é problema que o PO resolve — é do Scrum Master e da liderança.

A arquitetura técnica não é decisão sua. O PO define o que precisa ser feito e por quê. Como será feito é decisão do time técnico. Opinar sobre tecnologia, banco de dados ou estrutura de código tende a gerar mais problema do que ajuda.

Os erros mais comuns do PO nesses frameworks

Microgerenciar a sprint depois que ela começa. O Sprint Backlog está fechado. Se você continua adicionando, removendo ou repriorizando itens durante a sprint, você está destruindo o contrato que foi feito no planning. O time perde previsibilidade. Novas demandas urgentes? Vão para o backlog e entram na próxima sprint — salvo emergências reais, e emergências reais são raras.

Transformar o Sprint Goal em lista de tarefas. O Sprint Goal é um objetivo de negócio que a sprint deve atingir. Não é "entregar as histórias X, Y e Z". Quando o Goal é uma lista de itens, o time perde o norte quando algo inesperado acontece durante a sprint.

Participar da Daily como se fosse status report. Se o time está te reportando status na Daily em vez de sincronizar entre eles, há um problema de confiança ou de entendimento do framework. Corrija o padrão, não aproveite o relatório.

Aceitar velocity como medida de produtividade. Velocity (pontos entregues por sprint) é uma ferramenta de planejamento, não um KPI de performance. Times que inflamam estimativas para parecer mais produtivos são um sintoma de cultura doentia. Se você está usando velocity para comparar times ou cobrar resultado, está usando a métrica errada.

Ignorar a Retrospectiva. Muitos POs acham que a retro não é com eles. Mas o processo do time impacta diretamente a qualidade e a velocidade de entrega. Um time com problemas de processo não entrega bem — e isso é problema seu também.

O que realmente importa: a mentalidade por trás dos frameworks

Scrum e Kanban são ferramentas. Como qualquer ferramenta, podem ser usadas bem ou mal.

O que torna um time ágil de verdade não é a cerimônia que ele faz ou o board que ele usa. É a capacidade de inspecionar e adaptar — olhar para o que está acontecendo, aprender com isso e mudar o que precisa mudar.

Um time que faz todas as cerimônias do Scrum mas não muda nada com base no que aprende na Retrospectiva não é um time ágil. Um time que não usa nenhum framework mas entrega valor consistentemente, aprende com os erros e melhora o processo a cada ciclo está praticando agilidade de verdade.

Como PO, o seu papel nos frameworks é garantir que o time está construindo as coisas certas. O Scrum Master garante que o time está construindo da forma certa. O time garante que está construindo bem.

Quando cada um faz sua parte, o framework funciona. Quando um assume o papel do outro, começa o conflito.

Para ir além: certificações e onde estudar

Conhecer os frameworks na prática é o primeiro passo. Se você quiser aprofundar ou ter uma certificação que valide esse conhecimento no mercado, aqui estão os caminhos mais reconhecidos.

Certificações de Scrum

Scrum.org — Professional Scrum Product Owner (PSPO) Esta é a certificação mais respeitada para POs que trabalham com Scrum. Existe em três níveis: PSPO I (fundamentos), PSPO II (aplicação avançada) e PSPO III (liderança e mentoria). O PSPO I é o ponto de partida ideal para quem está começando.

Diferente de muitas outras certificações, a Scrum.org exige que você passe em uma prova com tempo limitado e nota de corte alta — não basta fazer um curso e receber o certificado automaticamente. Isso torna a certificação mais valorizada pelo mercado.

Scrum Alliance — Certified Scrum Product Owner (CSPO) É a certificação mais popular em volume de certificados emitidos no mundo. Exige a participação em um curso presencial ou online com um Certified Scrum Trainer (CST). Não tem prova — a aprovação vem pela participação no treinamento. Reconhecida globalmente, especialmente em empresas que adotaram o framework Scrum Alliance.

PMI — Professional Scrum with Kanban (PSK) / Agile Certified Practitioner (PMI-ACP) Para quem já tem background em gestão de projetos e quer validar conhecimento ágil de forma mais ampla, o PMI-ACP cobre Scrum, Kanban, XP e outros frameworks ágeis. Requer horas de experiência comprovada além da prova.

Certificações de Kanban

Kanban University — Kanban Management Professional (KMP) É a certificação de referência em Kanban, composta por dois módulos sequenciais: KSD (Kanban System Design) e KSI (Kanban System Improvement). Focada em profissionais que trabalham com times de fluxo contínuo ou que querem implementar Kanban em contextos complexos.

Lean Kanban University — Team Kanban Practitioner (TKP) Certificação de entrada para quem quer conhecer Kanban de forma estruturada. É o primeiro nível da trilha da Lean Kanban University, mais acessível e com menor custo.

Onde estudar antes de certificar

Leitura obrigatória e gratuita:

• Scrum Guide (scrum.org/resources/scrum-guide) — O documento oficial do Scrum. Menos de 15 páginas. Leia antes de qualquer curso ou prova.
• Kanban Guide (kanban.university) — O equivalente para Kanban. Igualmente conciso e direto.

Livros que valem o investimento:

• Scrum: a Arte de Fazer o Dobro do Trabalho na Metade do Tempo — Jeff Sutherland. O co-criador do Scrum explica o framework e o raciocínio por trás das decisões. Leitura rápida e envolvente.
• Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia — David J. Anderson. A referência definitiva em Kanban aplicado a software. Mais denso, mas essencial para quem quer se aprofundar.
• User Stories Applied — Mike Cohn. Conecta diretamente com o que você aprendeu no Módulo 2 sobre User Stories, mas com mais profundidade e exemplos reais.

Plataformas de cursos:

• LinkedIn Learning — Tem cursos de Scrum e Kanban com legendas em português. Bom para revisão de conceitos.
• Coursera / edX — Têm especializações mais longas, algumas com certificados reconhecidos por empresas.
• YouTube — Procure os canais oficiais da Scrum.org e Kanban University, que publicam conteúdo gratuito regularmente.

Qual certificação fazer primeiro?

Se você está começando na área e o time da empresa usa Scrum, vá direto para o PSPO I da Scrum.org. A prova exige preparação real, o que te obriga a estudar de verdade — e o certificado tem peso no mercado brasileiro.

Se o time usa Kanban ou você está em uma operação de suporte/sustentação, comece pelo TKP da Lean Kanban University.

Uma dica prática: antes de investir na certificação, verifique se a empresa onde você quer trabalhar (ou onde já trabalha) reconhece e valoriza esse certificado específico. Algumas empresas preferem Scrum Alliance, outras preferem Scrum.org. Saber isso antes de pagar o exame evita frustração.

Certificação não substitui experiência. O mercado valoriza quem consegue aplicar o framework na prática, tomar decisões difíceis no refinamento e liderar sem autoridade. A certificação abre a porta — o que você faz depois dela é o que fica.

Conclusão

Scrum e Kanban são o vocabulário comum do time de produto. Você precisa conhecer as regras do jogo para jogar bem — mas não precisa ser o árbitro.

Entenda as cerimônias, saiba qual é o seu papel em cada uma, respeite o espaço do time e use o framework como estrutura de apoio, não como camisa de força.

No próximo módulo, vamos entrar em algo muito prático: as ferramentas que POs usam no dia a dia — Jira, Trello e Notion. Como configurar, o que usar em cada contexto e como evitar que a ferramenta vire o centro do trabalho em vez do produto.

Até lá.