SCRUM

Definição do SCRUM Framework que implementa os princípios Ágeis

Transparência

Características do SCRUM Inspeção

Adaptação

Necesisdade

Backlog do Produto

Fluxo do SCRUM
Sprint

Daily Scrum

Entrega

Product Owner

Papéis da Equipe
SCRUM Master

SCRUM Team
Princípio #1:
Empirismo

Princípio #2: Auto-

Organização

Princípio #3:
Colaboração
Prinípios do SCRUM Princípio #4:
Priorização baseada
em valor

Princípio #5:
Timeboxing
 Princípio #6:
iterativo e
incremental

Iniciar

Fases do SCRUM
Planejar e Estimar
 Implementar

Revisão e
Retrospectiva (da
Sprint)

Release
 SCRUM

Framework que implementa os princípios Ágeis

Comunicação, menos burocracia, mais visibilidade: reuniões diárias, gráficos públicos, backlog
visível, comunicação aberta e quadro de tarefas.
Para cada operação há inspeções semanais
Replanejamento, aceitar as validações: reuniões diárias, solicitações de mudanças, atualização do
backlog, identificação de risco e ajustes no processo.
De onde o projeto surge. É preciso reconhecer qual é a necessidade, criar a "Declaração de Visão do
Projeto".
Lista do que precisa ser criado com o projeto (funcionalidades, valores ou serviços qu precisam ser
entregues pelo projeto). Os "escopos" são as "Histórias do Usuário".
De 2 a 4 semanas, é entregue uma das histórias do usuários. O Sprint precisa possuir um backlog
também, onde será desenvolvido ("backlog da Sprint").
Reuniões diárias para ajustar e acompanhar o backlog da sprint.
Produto ou incremento do cliente.
O projeto retorna ao backlog paa reforma da sprint ou para o planejamento da próxima sprint.
Atendimento da conta, aquele que está dentro do universo do cliente e sabe exatamente o que é
prioridade. É quem testa o produto antes de apresentar ao cliente.
Aquele que lidera a equipe. É o decisor de prioridades dentro da equipe, sugere funções e recursos.
Destrava os processos.
Desenvolvedores do produto, multidisciplinar. No máximo 9 pessoas.
Manter o que dá certo, trocar o novo. Mas com flexibilidade. Se objetiva a eficiência. Aplica-se as
características (transpaência, inspeção e adaptação)

Metas de uma equipe auto-organizada: entender bem a visão do projeto (declaração de visão do
projeto); influência na expertise do time, ajudando os parceiros; proatividade; operacionalização
(espírito de execução); aberto a aprender coisas novas; continuamente aprimora conhecimentos e
habilidades; entrega de resultados tangíveis periodicamente.

Trabalhar como um time: consciência/empatia; articulação (saber dividir esforço); apropriação

(saber assumir e se responsabilizar por suas atividades e a dos outros quando necessário)

O time prioriza o que tem maior valor, entrega isso mais cedo, de forma iterativa e incremental
(sprint após sprint).

Cada elemento possui um tempo fixo para ser executado, já que as pessoas tendem a executar tudo,
com o máximo esforço, nas últimas horas (Teoria do Estudante). Traz objetividade, foco e mais
produtividade.
Contínuo, sem parada, não tem intervalos. Uma entrega puxa a outra e as entregas de valor
precisam ser periódicas.

Criar a Declaração de Visão do Projeto: título, objetivo (SMART - eSpecífico, Mensurável, Atingível,
Relevante/Realista e Temporal), justificativa do projeto, descrição geral do projeto, equipe, partes
interessadas (gerir a atenção e importância das partes interessadas), premissas (assunção de
verdades que estão fora do controle), restrições, escopo excluído (o que não será feito pelo projeto),
riscos preliminares do projeto (o que pode dar errado).

Definição da Equipe: além de selecionar uma equipe ágil e autônoma, flexível e comprometida, com
um ambiente que facilite o exercício de suas habilidades.

SCRUM Master: capacidade de resolver problemas, foco, líder pelo exemplo, capacidade de dar
feedbacks, disponibilidade e proatividade, comprometimento.

Product Owner: empatia, gestor, senso de priorização, maturidade, planejador.

Equipe SCRUM: conhecimentos e habilidades técnicas, proativo, colaborador, companheiro,

disposto.

Backlog do produto: requisitos que as partes interessadas (entrevista ou reuniões em grupo, com
todos os envolvidos); registrar as histórias do usuário (como x eu gostaria de Y para Z)*.
Priorização no backlog do produto (responsabilidade do PO): utilizar sistema de prioridades (1, 2, 3
etc) - MOSCOW (Must have, Should Have, Could have, Won't have for now).

* Épicos: histórias de usuário que não cabem num sprint, e precisam ser quebradas em mais sprints.

Planejamento de Releases: estimativa de quando serão liberadas algo para que o cliente possa
utilizar de modo real.
O PO refina o backlog e quebra um Épico em diversas Histórias (quebrando tarefas em tarefas
menores) e definindo os "Critérios de Aceitação" para cada História.

Backlog da Sprint: na Reunião de Planejamento da Sprint o PO negocia com o time o tempo e o

esforço para a execução das histórias e encaixa as histórias que farão parte da próxima sprint, com
foco no valor que será entregue ao cliente. O time pode realizar o método Poker Planning, em que
cada membro sugere um tempo e se for próximo, assume-se este tempo.

Sempre respeita-se a opinião do time técnico que sabe exatamente o que é necessário para a
execução da tarefa. Histórias podem ser distribuídas internamente pelo time, em forma de tarefas,
para que sejam executadas. Terminadas as tarefas, elimina-se a história.
O Painel Público de Tarefas mostra quem está fazendo o quê e qual a situação de cada tarefa
(Kanban).

Reuniões Diárias devem ser realizadas pelo SCRUM Master e em pé (stand-up meeting), com
timeboxing (15 minutos ou menos) e responsabilidade fixa (hora e local). Perguntar: o que fiz ontem
para realizar o projeto; o que farei hoje; o que me impede.

SCRUM Master realiza a lista de "Impedimentos Levantados" e corre para eliminar esses
impedimentos logo após a reunião.
Ferramenta: Burndown Map (planejado x realizado).
Revisão do Backlog do Produto: novas histórias podem entrar no backlog do produto, histórias
revisadas entram no backlog do produto, mudanças de histórias só acontecem em histórias que não
estejam na sprint (se houver necessidade, a sprint é cancelada).

Dono do Produto (e as principais partes do cliente, se possível) devem revisar o que foi entregue na
sprint. É o momento de Entrega de Valor ao cliente (com a possibilidade de o cliente poder rever).
O que for reprovado volta para o Backlog e repriorizados pelo PO e pode voltar na próxima sprint.

A Reunião de Retrospectiva deve acontecer antes do início de uma próxima sprint. Verifica-se a
necessidade de mudanças para a execução da próxima sprint (reunião de lições de aprendidas).

As entregas das sprints podem ser protótipos; mas o release é uma entrega real, de algo que está
ponto e pode ser utilizado.

É comum que o cliente faça pagamentos por release entregue.

Retrospectiva do Projeto: Reunião com a Equipe SCRUM para falar das lições aprendidas do projeto
como um todo.