Scrum é um framework leve que ajuda a gerar valor por meio de soluções adaptativas para

problemas complexos com elementos com propósitos específicos e essenciais, mudar o

modelo central, remover elementos ou não seguir as regras limita os benefícios do Scrum,
podendo até torna-lo inútil.

Scrum é baseado no empiricismo e Lean Thinking. O Empiricismo prega que o conhecimento

vem da experiencia e da tomada de decisões com base no que é observado. O Lean Thinking
reduz o desperdício e se concentra no essencial.

Scrum prega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar
o risco.

Scrum envolve grupos de pessoas que, coletivamente, possuem todas as habilidades e

conhecimentos necessários para fazer o trabalho compartilhando e adquirindo habilidades
conforme necessário.

Pilares empíricos do Scrum:

Transparência
O processo e o trabalho devem estar visíveis tanto para quem executa quanto para quem
recebe o trabalho. As decisões importantes são baseadas nos três artefatos formais.

Inspeção
Os artefatos e o progresso em direção às metas acordadas devem ser frequentemente
inspecionados. Para ajudar na inspeção o framework fornece cadência em seus cinco eventos.

Adaptação
Se algo desviar fora dos limites aceitáveis serão necessários ajustes o mais rápido possível para
minimizar novos desvios.

As pessoas devem ser empoderadas e auto-gerenciadas pois espera que o time se adapte no
momento em que aprende algo novo por meio da inspeção

Valores do Scrum
Compromisso
O time se compromete a atingir os objetivos e suportar uns aos outros

Foco
Foco no trabalho da Sprint para fazer o melhor progresso em direção à essas metas.

Abertura
O time e os stakeholders são abertos quanto ao trabalho e aos desafios

Respeito
O time se respeita quanto a serem capazes e independentes e são respeitados pelas pessoas
com quem trabalham

Coragem
O time tem coragem de fazer a coisa certa e trabalhar em problemas difíceis.
Scrum team
Consistem em um pequeno time de pessoas: Um Scrum Master, um Product Owner e
developers. Não há sub-times ou hierarquias, é uma unidade focado em um objetivo de cada
vez: a Meta do Produto.

É multifuncional: o time possui todas as habilidades necessárias para criar valor a cada Sprint.

É auto-gerenciavel: Decidem internamente quem faz o que, como e quando.

É pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho
significativo em uma sprint, normalmente 10 ou menos pessoas.

Se o time ficar muito grande deve se considerar a reorganização em diversos times com foco
no mesmo produto, por isso compartilham a mesma meta do produto, Product backlog e
Product Owner.

É responsável por criar um incremento valioso e útil a cada sprint.

Papéis
Developers
É quem está comprometido em criar qualquer aspecto de um incremento utilizável a cada
sprint.

São responsáveis por:

1. Criar um plano para a Sprint (Sprint Backlog)

2. Introduzir gradualmente qualidade aderindo a uma definição de pronto
3. Adaptar seu plano a cada dia em direção a meta da Sprint
4. Responsabilizar-se mutuamente como profissionais.

Product Owner
A principal responsabilidade é maximizar o valor do produto resultado do trabalho do time.

Também é responsável pelo gerenciamento do Product Backlog:

1. Desenvolver e comunicar a meta do produto

2. Criar e comunicar os itens do product backlog
3. Ordenar os itens do product backlog
4. Garantir que o product backlog seja visível, transparente e compreensível.

Ele pode delegar as tarefas acima porém sempre é o responsável

Qualquer alteração no Product backlog deve ser feita pelo Product Owner.

Scrum Master
Promove um ambiente onde:

1. Um Product Owner ordena o trabalho para um produto complexo em um Product

Backlog
2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor
durante uma Sprint
3. O Scrum Team e os stakeholder inspecionam os resultados e se ajustam para a
próxima Sprint.
Eventos
Sprint
Evento que contém os demais eventos

Duração: Fixa um mês ou menos.

Gatilho: Logo após a conclusão da sprint anterior

Durante a sprint não se coloca em risco a meta da sprint com alguma mudança, a qualidade
não diminui, são realizados refinamentos e o escopo pode ser negociado com o PO.

Só pode ser cancelada pelo Product Owner se a meta da sprint se tornar obsoleta.

Planning
Gatilho: Inicio da sprint

Participantes: Scrum Team e convidados para fornecer conselhos

Duração: máxima de 8 horas para uma sprint de um mês, para sprints mais curtas geralmente
é mais curto.

Todo o scrum team colabora para definir a meta da sprint.

Com discussões com o PO, os Developers selecionam itens para incluir na sprint atual podendo
haver refinamento

Somente os Developers montam o plano da Sprint, mais ninguém.

Sprint Backlog consiste em: Meta da Sprint, Itens do Product Backlog selecionados e o Plano
para entrega.

Daily Scrum
Propósito: inspecionar o progresso em direção a meta da sprint e adaptar o sprint backlog
conforme necessário

Duração: fixa de 15 minutos

Participantes: Developers

Os developers definem a estrutura da reunião desde que se concentre no progresso em

direção à meta e ocorrem no mesmo horário e local para reduzir complexidade.

Review
Propósito: inspecionar o resultado da Sprint e determinar adaptações futuras

Participantes: Scrum Team e stakeholders

Gatilho: penúltimo evento da Sprint

Duração: máximo de 4 horas para uma sprint de um mês, para sprints menores, geralmente é
mais curto.

Sprint Retrospective
Propósito: Planejar maneiras de aumentar a qualidade e eficácia

Participantes: Scrum team

Gatilho: Último evento da sprint

Duração: 3 horas para uma sprint de um mês, para sprint menores geralmente mais curto.

É discutido oque funcionou e o que não funcionou e como foi resolvido, identificadas ações
que devem ser endereçadas o mais rápido possível e podem até entrar no backlog da próxima
sprint.

Artefatos
São projetados para maximizar a transparência das informações gerando uma base central
para adaptações

Product Backlog
Compromisso: Meta do Produto -> é um estado futuro do produto sendo a meta de longo
prazo do time que deve cumpri-lo ou abandoná-lo antes de assumir outro.

É a única fonte de trabalho de um time scrum com uma lista ordenada e emergente.

Os Developers são responsáveis pelo dimensionamento. O PO somente auxilia

Sprint Backlog
Compromisso: Meta da Sprint -> É inalterada depois de definida, embora é possível realizar
negociações entre developers e PO para alterar o escopo da sprint sem alterar a meta.

Meta da Sprint, conjuntos de itens do product backlog selecionados e plano de ação para
entregar o incremento

É feito pelos Developers, uma imagem do que eles planejam realizar durante a sprint para
alcançar a meta, é atualizado no decorrer da sprint e deve ter detalhes suficientes para ser
inspecionado na Daily Scrum.

Incremento
Compromisso: Definição de pronto -> É a descrição formal do estado do incremento quando
atende as medidas de qualidade exigidas para o produto. Caso a organização tenha uma
definição de pronto todos os times devem segui-las como o mínimo, se não o Scrum Team
deve criar uma definição de pronto. Se vários times estão trabalhando no mesmo produto a
mesma definição de pronto deve ser utilizada.

Cada incremento deve ser utilizável, completamente verificado e adicionado aos anteriores
garantindo que todos funcionem juntos. Não é necessário esperar a review para entregar os
incrementos e para ser entregue deve atender a definição de pronto
Glossário
Coerência: A qualidade da relação entre itens do product backlog tomando em considerando o
todo (goal)

Emergence: O processo de vir a tona fatos que não existiam, que se tornaram visíveis
inesperadamente

Empirismo: Somente o passado é dado como certo e é usado como base para tomada de
decisões futuras, três pilares: Transparencia, adaptação e inspeção (TIA)

Engineering Standards: Padrões de desenvolvimento e técnicas para criar incrementos de valor

funcionais.

Forecast (of functionality): a seleção de itens que os desenvolvedores acham viáveis para uma
sprint

Increment: O trabalho de valor e completo durante uma sprint, a soma dos incrementos forma
um produto.

Product Backlog: Lista de trabalho que deve ser feita pelo time ordenada e gerenciada pelo PO

Product backlog Refiniment: Atividade em que os desenvolvedores e o PO colocam mais

granularidade nos PBI com mais detalhes.

Product Owner: Papel responsável por maximizar o valor do produto, expressa expectativas de
negócio e funcionais

Product Goal: descreve o estado futuro do Produto que serve como objetivo para o time, está
no product backlog, o resto do product backlog descreve o que será feito para atingir o
product goal.

Ready: Um entendimento compartilhado entre o PO e os Developers do nível de qualidade dos

PBIs na Planning

Scrum: Um framework leve que ajuda na geração de valor através soluções adaptativas para
problemas complexos.

Scrum Board: Quadro de informação para e feito pelo time scrum para gerenciar a Sprint
backlog, são opcionais

Scrum Master: Papel que guia, treina a auxiliar o time Scrum e o ambiente inserido a entender
o papel do Scrum

Scrum team: time auto-organizado de um Scrum Master um PO e vários desenvolvedores.

Scrum Values: Compromisso, Foco, Abertura, Respeito e Coragem

Self managing: o Time é Cross-funcional que significa que tem todas as habilidades para criar
valor a cada sprint, decide quem faz, o que faz e quando faz.

Sprint: evento de um mês ou menos de duração que contém os outros eventos, são continuas
sem intervalos

Stakeholder: Pessoas externas ao time que são interessadas no produto, representados pelo
PO e participante da Review
Techinical Debt: Carga de manutenção do produto, que pode ter sido causada decisões não
ideais

Velocity: Indicator opcional mais bastante usado que mostra q quantidade de itens de backlog
transformados em incrementos funcionais que a equipe consegue entregar por sprint.