Scrum é um framework leve que ajuda pessoas, equipas e organizações a gerar valor através de soluções adaptativas para problemas complexos.

Características:

• Framework leve e simples de entender
• Difícil de dominar
• Baseado em empirismo e pensamento lean
• Iterativo e incremental

O Scrum baseia-se no empirismo, que afirma que o conhecimento vem da experiência e da tomada de decisões baseada no que é observado.

Três Pilares:

1. Transparência - O processo emergente e o trabalho devem ser visíveis
2. Inspeção - Os artefactos e progresso devem ser inspecionados frequentemente
3. Adaptação - Ajustar quando necessário para minimizar desvios

O sucesso do Scrum depende das pessoas internalizarem cinco valores:

• Compromisso - Comprometer-se pessoalmente a alcançar os objetivos do Sprint
• Foco - Concentrar-se no trabalho do Sprint para fazer o melhor progresso possível
• Abertura - Ser aberto sobre o trabalho e os desafios
• Respeito - Respeitar a capacidade e independência de cada membro
• Coragem - Ter coragem para fazer a coisa certa e trabalhar em problemas difíceis

Scrum também segue princípios do pensamento lean:

Princípios:

• Eliminar desperdício - Focar no que traz valor
• Amplificar aprendizagem - Iterações rápidas e feedback
• Decidir o mais tarde possível - Manter opções abertas
• Entregar o mais rápido possível - Ciclos curtos
• Capacitar a equipa - Autogestão
• Construir integridade - Qualidade desde início
• Ver o todo - Visão sistémica do produto

Scrum é especificamente desenhado para problemas complexos.

Tipos de Trabalho:

• Simples: Processos repetitivos, soluções conhecidas
• Complicado: Requer análise especializada, mas previsível
• Complexo: Incerto, imprevisível, requer experimentação

Porquê Scrum para Complexidade?

• Permite inspeção e adaptação frequentes
• Facilita aprendizagem através da experiência
• Reduz risco através de entregas incrementais

Todos os eventos Scrum são timeboxed (têm duração máxima fixa).

Durações Máximas (Sprint de 1 mês):

• Sprint: 1 mês ou menos
• Sprint Planning: 8 horas
• Daily Scrum: 15 minutos
• Sprint Review: 4 horas
• Sprint Retrospective: 3 horas

Porquê Timeboxes?

• Cria ritmo e consistência
• Evita reuniões infinitas
• Força foco e eficiência
• Proporcional para Sprints mais curtos

Um produto é um veículo de valor para entregar aos stakeholders.

Tipos de Produtos:

• Software ou website
• Serviço
• Produto físico
• Uma combinação de todos acima

Product Goal:

• Descreve um estado futuro do produto
• A equipa foca num objetivo de cada vez
• Deve ser alcançado antes de começar outro
• Fornece direção a longo prazo

Podem ser criados múltiplos Incrementos dentro de um Sprint.

Regras:

• Cada Incremento deve estar "Pronto"
• Todos os Incrementos são apresentados na Sprint Review
• A soma de Incrementos cria valor acumulado
• Um Incremento pode ser entregue aos stakeholders

Benefícios:

• Feedback mais frequente
• Entrega de valor contínua
• Redução de risco

Nota: O Product Owner pode decidir entregar Incrementos imediatamente.

Stakeholders são pessoas externas à Equipa Scrum com interesse no produto.

Envolvimento:

• Participam na Sprint Review
• Podem dar feedback sobre o Incremento
• Não fazem parte das decisões da equipa
• Product Owner representa os seus interesses

Exemplos:

• Clientes e utilizadores
• Gestão e executivos
• Equipa de marketing
• Investidores

A transparência no Scrum permite inspeção e adaptação eficazes.

Métricas Comuns:

• Burndown Chart: Trabalho restante ao longo do tempo
• Burnup Chart: Trabalho completo ao longo do tempo
• Velocity: Média de trabalho por Sprint
• Cumulative Flow: Estado dos itens no fluxo

Importância:

• Ajudam a prever entrega futura
• Identificam problemas cedo
• Suportam decisões baseadas em dados

Nota: O Scrum Guide não exige métricas específicas.

Os Developers são os profissionais na Equipa Scrum comprometidos em criar qualquer aspeto de um Incremento utilizável em cada Sprint.

Responsabilidades:

• Criar um plano para o Sprint (Sprint Backlog)
• Garantir qualidade aderindo à Definição de Pronto
• Refinar diariamente o plano (Daily Scrum)
• Responsabilizar-se mutuamente como profissionais

Nota: Não há subtítulos ou hierarquia entre Developers.

O Product Owner é accountable por maximizar o valor do produto resultante do trabalho da Equipa Scrum.

Responsabilidades:

• Desenvolver e comunicar explicitamente o Objetivo do Produto
• Criar e comunicar claramente os itens do Product Backlog
• Ordenar os itens do Product Backlog
• Garantir que o Product Backlog é transparente e compreendido

Importante: Uma pessoa, não um comité. Pode representar necessidades de stakeholders, mas decisões finais são suas.

O Scrum Master é accountable pela eficácia da Equipa Scrum.

Responsabilidades:

• Guia a Equipa Scrum na eficácia e autogestão
• Remove impedimentos ao progresso da equipa
• Facilita eventos Scrum conforme necessário
• Coacha a equipa no contexto Scrum

Para a Organização:

• Lidera e guia a organização na adoção do Scrum
• Planeia e aconselha implementações
• Ajuda os funcionários a entenderem o Scrum

A Equipa Scrum é uma unidade coesa de profissionais focados num objetivo.

Características:

• Autogerida - Decide internamente quem faz o quê, quando e como
• Multifuncional - Tem todas as competências necessárias
• Sem hierarquias - Não há sub-títulos ou divisões

Dimensão:

• 3-9 Developers
• 1 Product Owner
• 1 Scrum Master
• Total: 5-11 pessoas

O Scrum Guide 2020 usa "accountabilities" em vez de "papéis".

Porquê a Mudança?

• "Accountability" enfatiza responsabilidade e propriedade
• Evita confusão com títulos hierárquicos tradicionais
• Foca no que a pessoa é responsável entregar

Diferenças:

• Papel tradicional: "Sou tester" (descrição de função)
• Accountability: "Sou accountable pela qualidade" (responsabilidade)

Nota: Todos os Developers são igualmente accountable pela criação do Incremento.

O Product Owner é accountable por maximizar o valor do produto.

Técnicas de Maximização:

• Ordenação do Backlog: Itens de maior valor no topo
• Análise ROI: Retorno sobre investimento
• Validação com stakeholders: Feedback frequente
• Métricas de valor: KPIs e OKRs

Decisões do PO:

• O que construir primeiro
• O que não construir
• Quando lançar
• Quando pivotar

Nota: O PO pode delegar trabalho, mas não a accountability.

O Scrum Master é um líder servidor para a Equipa Scrum.

Estilo de Liderança:

• Serve a equipa, não manda
• Facilita em vez de dirigir
• Remove impedimentos
• Protege a equipa de interrupções

O que NÃO faz:

• ❌ Não é gestor de projeto
• ❌ Não atribui tarefas
• ❌ Não reporta status à gestão
• ❌ Não toma decisões técnicas

Os Developers devem ter um conjunto complementar de competências.

Tipos de Skills:

• Programação: Frontend, backend, mobile
• Testes: Manual, automatizado, QA
• Design: UX/UI, arquitetura
• Análise: Requisitos, negócio
• DevOps: CI/CD, infraestrutura

T-Shaped Professionals:

• Especialização profunda numa área
• Conhecimento amplo em várias áreas
• Capacidade de colaborar em diferentes tarefas

Embora cada papel tenha accountabilities específicas, há responsabilidades partilhadas.

Toda a Equipa Partilha:

• Qualidade do produto: Todos responsáveis
• Melhoria contínua: Kaizen mindset
• Comunicação: Transparente e aberta
• Resolução de problemas: Colaborativa

Accountabilidades Únicas:

• PO: O quê e porquê (valor)
• SM: Processo Scrum
• Devs: Como construir

Como os papéis tradicionais se mapeiam para Scrum:

Mapeamento Comum:

• Project Manager → Divide-se entre PO e SM
• Team Lead → Developer sénior (sem título)
• Business Analyst → PO ou Developer
• Tester → Developer com skill de testes
• Designer → Developer com skill de design

Princípio:

• Não há sub-títulos em Developers
• Todos são igualmente "Developer"
• Especializações são competências, não títulos

O Sprint é o recipiente para todos os outros eventos. É um evento de duração fixa de um mês ou menos para criar consistência.

Características:

• Duração fixa (tipicamente 2-4 semanas)
• Um novo Sprint começa imediatamente após o anterior
• Não são feitas alterações que ponham em perigo o Sprint Goal
• A qualidade não diminui
• O Product Backlog é refinado conforme necessário

Cancelamento: Apenas o Product Owner pode cancelar um Sprint.

O Sprint Planning inicia o Sprint definindo o trabalho a ser realizado.

Duração:

Máximo de 8 horas para um Sprint de um mês (proporcional para Sprints mais curtos).

Três Temas:

1. Porquê é este Sprint valioso? → Define o Sprint Goal
2. O que pode ser feito? → Seleciona itens do Product Backlog
3. Como é que o trabalho escolhido será feito? → Planeia as tarefas

Resultado:

Sprint Backlog criado com Sprint Goal, itens selecionados e plano de ação.

A Daily Scrum é uma reunião diária de 15 minutos para os Developers da Equipa Scrum.

Propósito:

• Inspecionar o progresso em direção ao Sprint Goal
• Adaptar o Sprint Backlog conforme necessário
• Ajustar o trabalho emergente planeado

Formato:

Acontece à mesma hora e local todos os dias úteis. Apenas Developers participam ativamente.

Estrutura Típica (não obrigatória):

• O que fiz ontem?
• O que farei hoje?
• Quais os impedimentos?

A Sprint Review inspeciona o resultado do Sprint e determina futuras adaptações.

Duração:

Máximo de 4 horas para um Sprint de um mês.

Atividades:

• Product Owner comunica o que foi completo e o que não foi
• Equipa demonstra o trabalho completo e responde a perguntas
• Inspeção do que foi realizado e do ambiente atual
• Adaptação do Product Backlog conforme necessário

Nota: Não é apenas uma demonstração! É uma sessão de trabalho colaborativa.

A Sprint Retrospective planifica formas de aumentar a qualidade e a eficácia.

Duração:

Máximo de 3 horas para um Sprint de um mês.

Objetivos:

• Inspecionar como foi o último Sprint (pessoas, interações, processos)
• Identificar o que correu bem e o que pode melhorar
• Criar um plano de melhorias para implementar no próximo Sprint

Foco:

A equipa identifica as melhorias mais úteis e de maior impacto e adapta a definição de "Pronto" se necessário.

O Product Backlog é uma lista ordenada e emergente de tudo o que é necessário no produto.

Características:

• Fonte única de trabalho para a Equipa Scrum
• Emergente - nunca está completo
• Ordenado - itens de maior valor no topo
• Detalhado o suficiente para Sprint Planning

Compromisso: Objetivo do Produto (Product Goal)

Descreve um estado futuro do produto. A Equipa deve realizar (ou abandonar) um objetivo antes de assumir o próximo.

O Sprint Backlog é composto pelo Sprint Goal, itens do Product Backlog selecionados e o plano de ação.

Características:

• Criado durante o Sprint Planning
• Plano em tempo real e visível do trabalho
• Atualizado ao longo do Sprint
• Detalhe suficiente para Daily Scrum

Compromisso: Sprint Goal

Objetivo único para o Sprint. Fornece direção e motivação. Pode ser refinado durante o Sprint, desde que não seja posto em causa.

Um Incremento é um bloco de construção concreto em direção ao Objetivo do Produto.

Características:

• Feito de todo o trabalho completo do Sprint
• Cada Incremento é aditivo a todos os anteriores
• Deve ser utilizável e funcional
• Pode ser entregue aos stakeholders

Compromisso: Definição de Pronto (Definition of Done)

Descrição formal do estado do Incremento quando atende às medidas de qualidade necessárias. Se um item não está "Pronto", não pode ser apresentado na Sprint Review.

O Product Goal é o compromisso com o Product Backlog.

Características:

• Descreve um estado futuro do produto
• A Equipa pode perseguir apenas um objetivo de cada vez
• Deve ser alcançado ou abandonado antes de começar outro
• Fornece direção a longo prazo

Exemplos:

• "Lançar versão beta para utilizadores externos"
• "Alcançar 10,000 utilizadores ativos"
• "Implementar sistema de pagamentos completo"

A Definition of Done (DoD) é o compromisso com o Incremento.

Propósito:

• Cria transparência sobre o que está completo
• Garante qualidade consistente
• Evita "quase pronto" ou "90% feito"

Exemplo de DoD:

• ✅ Código revisto por peers
• ✅ Testes unitários passam
• ✅ Testes de integração completos
• ✅ Documentação atualizada
• ✅ Deploy em ambiente de staging

Nota: Se múltiplas equipas trabalham no mesmo produto, devem definir e cumprir a mesma DoD.

Regras:

• Developers: 3-9 pessoas
• Product Owner: 1 pessoa
• Scrum Master: 1 pessoa

Total: 5-11 pessoas na Equipa Scrum.

Porquê estes limites?

• Equipas menores → menos interação e produtividade reduzida
• Equipas maiores → demasiada complexidade na coordenação

Nota: Se a equipa for demasiado grande, considere dividir em múltiplas equipas Scrum coesas, partilhando o mesmo Produto.

A Equipa Scrum é autogerida e multifuncional.

Autogestão significa:

• A equipa decide quem faz o quê
• A equipa decide quando fazer
• A equipa decide como fazer

Multifuncional significa:

• A equipa tem todas as competências necessárias
• Não depende de pessoas externas à equipa
• Cada membro pode contribuir para diferentes áreas

Importante: O Scrum Master não atribui tarefas aos Developers!

O refinamento é o ato de adicionar detalhes, estimativas e ordenação aos itens do Product Backlog.

Atividades:

• Dividir itens grandes em itens menores
• Adicionar descrições claras e critérios de aceitação
• Estimar esforço (se a equipa usar estimativas)
• Reordenar baseado em novas informações

Quando acontece:

É uma atividade contínua, não um evento formal. Normalmente consome até 10% da capacidade do Sprint.

Um Sprint pode ser cancelado apenas pelo Product Owner.

Quando cancelar:

• O Objetivo do Sprint torna-se obsoleto
• Mudanças nas condições de mercado
• Mudanças na direção estratégica da empresa
• Tecnologia tornou-se obsoleta

O que acontece:

• Itens completos são revistos e aceites
• Itens incompletos voltam ao Product Backlog
• Realiza-se uma nova Sprint Planning

Nota: Cancelamentos são raros e perturbadores. Devem ser evitados.

Quando múltiplas equipas Scrum trabalham no mesmo produto:

Regras:

• Todas partilham o mesmo Product Goal
• Todas partilham o mesmo Product Backlog
• Todas partilham a mesma Definição de Pronto
• Cada equipa cria Incrementos que são parte do todo

Coordenação:

• Podem necessitar de sincronização entre equipas
• Scrum Masters podem coordenar trabalho
• Evitar dependências excessivas entre equipas

Importante: Não existe "Scrum de Scrums" oficial no Scrum Guide.

Erros frequentes que quebram o Scrum:

Anti-Patterns:

• ❌ Sprint como mini-cascata: Design → Dev → Test em sequência
• ❌ Scrum Master como chefe: Atribui tarefas em vez de facilitar
• ❌ Product Owner ausente: Não está disponível para a equipa
• ❌ Daily como reporting: Reportar ao gestor em vez de planeamento
• ❌ Retrospectiva ignorada: Não implementa melhorias
• ❌ Definition of Done fraca: Permite bugs em produção

Como Evitar:

• Seguir o Scrum Guide rigorosamente
• Inspeção e adaptação constantes
• Formação contínua da equipa

O Sprint Goal é criado durante o Sprint Planning.

Como Criar:

• Identificar o objetivo de negócio
• Ser específico mas não demasiado detalhado
• Focar no valor, não nas tarefas
• Ser atingível dentro do Sprint

Exemplos Bons:

• ✅ "Permitir utilizadores fazerem login"
• ✅ "Processar pagamentos online"

Exemplos Maus:

• ❌ "Completar 15 user stories"
• ❌ "Trabalhar no backend"

O Scrum Guide não menciona User Stories, mas são amplamente usadas.

User Story Template:

Como [tipo de utilizador], quero [ação], para [benefício]

Outros Formatos:

• Bugs e defeitos
• Técnicas (refactoring)
• Spikes de investigação
• Melhorias

INVEST Criteria:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

O Scrum não exige estimativas, mas são frequentemente usadas.

Métodos Populares:

• Planning Poker: Cards com Fibonacci
• T-Shirt Sizes: XS, S, M, L, XL
• Story Points: Esforço relativo
• Horas ideais: Tempo sem interrupções

Boas Práticas:

• Estimar em equipa, não individualmente
• Usar referência de itens passados
• Re-estimar quando necessário
• Não usar estimativas como métrica de performance

A melhoria contínua é central ao Scrum.

Onde Acontece:

• Sprint Retrospective: Principal evento de melhoria
• Daily Scrum: Ajustes diários
• Refinamento: Melhoria do Backlog

Tipos de Melhoria:

• Processos e ferramentas
• Qualidade do produto
• Comunicação e colaboração
• Skills e competências

PDCA Cycle:

• Plan - Planear mudança
• Do - Implementar
• Check - Verificar resultados
• Act - Ajustar e standardizar

Impedimentos são obstáculos que impedem a equipa de progredir.

Exemplos Comuns:

• Falta de acesso a sistemas
• Dependências de outras equipas
• Requisitos pouco claros
• Problemas técnicos
• Interrupções externas

Quem Resolve:

• Scrum Master: Remove impedimentos
• Developers: Podem resolver alguns internamente
• Product Owner: Clarifica requisitos

Visualização:

Usar um Impediment Board para trackar status.

No Scrum, trabalho ou está "Done" ou não conta.

Regras:

• ✅ 99% completo = não completo
• ✅ "Quase pronto" = não pronto
• ✅ Testes a falhar = não Done
• ✅ Sem code review = não Done

Na Sprint Review:

• Apenas trabalho "Done" é demonstrado
• Trabalho "Undone" volta ao Product Backlog
• Não há crédito parcial

Mindset: Melhor entregar menos 100% Done que mais 80% Done.

Scrum pode ser escalado para organizações grandes.

Desafios:

• Coordenação entre múltiplas equipas
• Dependências complexas
• Cultura organizacional
• Governança e compliance

Frameworks de Scaling:

• Scrum@Scale
• LeSS (Large Scale Scrum)
• SAFe (Scaled Agile Framework)
• Nexus

Nota: Estes não são parte do Scrum Guide oficial.

Scrum e DevOps são altamente complementares.

Sinergias:

• CI/CD: Entrega contínua de Incrementos
• Automatização: Suporta Definition of Done
• Monitorização: Feedback rápido
• Infrastructure as Code: Reprodutibilidade

Benefícios:

• Entrega mais rápida de valor
• Melhor qualidade
• Feedback mais rápido
• Menos riscos de deployment

Nota: DevOps não é mencionado no Scrum Guide, mas é amplamente adotado.

Checklist rápida para validar Scrum:

Eventos:

• ✅ Sprints com duração fixa?
• ✅ Daily de 15 minutos?
• ✅ Sprint Review com stakeholders?
• ✅ Retrospectiva com ações de melhoria?

Artefactos:

• ✅ Product Backlog ordenado?
• ✅ Sprint Goal definido?
• ✅ Definition of Done cumprida?

Papéis:

• ✅ PO disponível e dedicado?
• ✅ SM facilita sem comandar?
• ✅ Equipa autogerida?

Se responder "não" a algum, há espaço para melhorar!