Apostila - Scrum Master

Prévia do material em texto

Agenda
1 dia
2 dia
 Mindset ágil
 Conceitos de ágil e scrum
 Práticas scrum
 Papéis no scrum;
 Eventos scrum
 O Backlog e a sua importância
 Definição de pronto;
 Planejamento e estimativas
 Monitoramento projetos com Scrum
 Conceitos avançados do Scrum
Agile Subway Map
Projeto
• Projeto é um esforço temporário empreendido para criar 
um produto, serviço ou resultado exclusivo.
• Ele é temporário, por ter uma data prevista para iniciar e 
uma data prevista para terminar, gera entregas exclusivas 
que podem ser serviços ou produtos com resultados 
específicos.
Conceito de gerenciamento de projetos 
Vislumbrar Especular
1
2
3
4
5
6
7
Lista de 
Funcionalidades
Plano de Implementação Explorar
Produto Final Encerrar
Definição de SCRUM
É um framework de gerenciamento de projetos e desenvolvimento ágil de PRODUTOS, no
qual as pessoas podem tratar e resolver problemas complexos e adaptativos, de forma
produtiva e criativa entregam produtos com o maior valor possível.
Simples de 
Entender Leve
Difícil de 
Implementar
SCRUM
Foco em
Produto
Pessoas Comunicação
Flexibilidade
Uso do SCRUM para:
1. Pesquisar e identificar mercados viáveis, 
tecnologias e funcionalidades de produtos;
2. Desenvolver produtos e melhorias;
3. Liberar produtos e melhorias frequentes, 
chegando a várias vezes por dia;
4. Desenvolver e sustentar a Nuvem (online, 
segura, sob demanda) e outros ambientes 
operacionais para uso de produtos;
5. Sustentar e renovar produtos.
Origem do nome Scrum
O Nome Scrum vem de uma
formação do Rugby, um esporte
coletivo originário da Inglaterra.
Scrum ou formação ordenada é
uma formação frequente no
Rugby, geralmente usada após
uma jogada irregular ou em
alguma penalização. Nesta
formação, 8 jogadores de cada
time devem se encaixar para
formar uma muralha. Nesta
formação é muito importante
que seja realizado um trabalho
em equipe, pois se um dos
jogadores na formação falhar,
toda a jogada será
comprometida.
Ciclo interativo e incremental
Interação 1
Incremento de 
Produto
Analisar
Desenhar
Construir
Integrar
Testar
Interação 2
Incremento de 
Produto
Analisar
Desenhar
Construir
Integrar
Testar
Interação 3
Incremento de 
Produto
Analisar
Desenhar
Construir
Integrar
Testar
Interação 4
Incremento de 
Produto
Analisar
Desenhar
Construir
Integrar
Testar
Interação 5
Analisar
Desenhar
Construir
Integrar
Testar
Pilares do SCRUM
Transparência
• As informações devem ser transmitidas de forma clara e
precisa, possibilitando que todos tenham o mesmo
entendimento;
• Praticado por todos os envolvidos no projeto;
• Toda a equipe deve ter a mesma fala.
Adaptação
• Sempre que algo indesejado ocorrer, deve-se adaptar o
que for necessário no processo para evitar a sua
recorrência;
• Inspeção e adaptação costumam ocorrer juntas;
• Realizado pelo Time.
Inspeção
• Significa que os processos, práticas e atividades devem
ser analisados com frequência suficiente para que as
variações inaceitáveis possam ser detectadas o mais
cedo possível
• Evita que o cliente receba um produto com qualidade
inadequada
Valores do Scrum
Coragem
O Scrum Team deve ter 
Coragem para fazer a coisa 
certa e trabalhar em 
problemas difíceis.
Foco
Todos focam no trabalho da 
Sprint e nos objetivos do 
Time Scrum.
Comprometimento
As pessoas se comprometem pessoalmente em alcançar 
estes objetivos do Time Scrum.
Respeito
Os membros do Time Scrum 
respeitam uns aos outros 
para serem pessoas capazes 
e independentes.
Abertura
Os membros do Time Scrum 
respeitam uns aos outros 
para serem pessoas capazes 
e independentes.
Manifesto Ágil
01
Indivíduos e 
interações
08
Processos e 
ferramentas
m
a
is q
ue
02
Software em 
funcionamento
07
Documentação 
abrangente
m
a
is q
ue
03
Colaboração com 
o Cliente
06
Negociação de 
contratos
m
a
is q
ue
04
Responder às 
mudanças
05
Seguir um 
plano
m
a
is q
ue
Valor 1: Indivíduos e interações mais que 
processos e ferramentas
Indivíduos e interações com alto 
valor
Processos e ferramentas com 
alto valor
• Membros da equipe de
desenvolvimento devem possuir a
capacidade de se envolver, se
responsabilizar e inovar;
• As pessoas podem criar uma super
dependência dos processos em vez de
encontrar as melhores maneiras de
criar bons produtos
• As pessoas também terão de deixar o
egoísmo, porque a colaboração é
que está valendo.
• Um processo não se encaixa em todas
as equipes – pessoas diferentes têm
diferentes estilos de trabalho;
• Um processo não cabe em todos os 
projetos
• A comunicação pode ser ambígua e 
demorada
Valor 2: Software em funcionamento mais do 
que documentação abrangente
Em projetos ágeis, a única maneira de medir se cumprimos com os
requisitos do produto é o de produzir sua funcionalidade associado com
aos requisitos;
Tarefas que distraiam o desenvolvimento devem ser avaliadas para ver
se as mesmas auxiliam ou atrapalham o produto de trabalho;
Todos os projetos exigem documentação. Em projetos ágeis, no entanto,
os documentos devem ser apenas suficientes para atende-los;
As equipes de projetos ágeis produzem menos documentos (e mais
simplificados), que exigem menos tempo para se manter e proporcionar
uma melhor visibilidade sobre possíveis problemas.
Valor 3: Colaboração com o cliente mais do 
que negociação de contratos
Em gerenciamento de projetos o envolvimento do cliente normalmente ocorre em três ocasiões:
Inicio do projeto Alterações de escopo Fim do projeto
Valor 4: Responder a mudanças mais que seguir 
um plano
A metodologia ágil entende que as colaborações, em vez de confronto, produzem um produto melhor, mais enxuto e mais funcional.
Equipes de projetos tradicionais muitas vezes seguem incondicionalmente um plano, perdendo oportunidades de criar produtos mais 
valiosos para o cliente.
2 anos – sem mudanças
2 anos
Potencial 
mudança Potencial 
mudança Potencial 
mudança Potencial 
mudança Potencial 
mudança Potencial 
mudança
12 Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor;
2. Aceitar Mudanças de Requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças
3. Entregar software com frequência , na escala de semanas até meses, com preferência a períodos mais curtos
4. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente , durante todo o curso
do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles um ambiente e suporte necessário, e confiar que farão
seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através
de uma conversa cara a cara.
7. Software funcional é a medida primária do progresso
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinitivamente passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser efetuado.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis
12. Em intervalos regulares o time reflete em como ficar mais efetivo, então, se ajusta e otimiza seu comportamento de acordo as
necessidades.
Outros frameworks ágeis
Crystal
Foi criado com o
principio de ser uma
abordagem de
desenvolvimento de
software que priorizasse a
adaptabilidade.
Possui como
característica a
comunicação
cooperativa e a entrega
de software útil em
funcionamento
Os métodos Crystal são
focados em talentos e
nas suas habilidades
Cada método Crystal é 
caracterizado por uma 
cor, de acordo com o 
número de envolvidos
Crystal 
Clear
1-8
Yellow
10-20
Orange 
(web) 
20-50
Red
50-100
As 7 propriedades do Crystal
Crystal
Ambiente 
técnico 
ágil
Entregas 
frequentes
Melhoria 
reflexiva
Comunicação 
osmótica
Fácil 
acessoSegurança 
Pessoal
Foco
Desenvolvimento orientado a testes
Método que começa com
um desenvolvedor criando
um teste para um requisito
que ele precisa criar
Depois executa o teste que
irá falhar pois o requisito
ainda não existe. O
desenvolvimento continua
até o sucesso do teste
Usando TDD quando
terminamos o
desenvolvimento realmente
acabamos. Dificilmente
precisaremos retornar ao
código devido as falhas
terem sido detectadas
durante a confecção dos
testes.
Extreme programming (XP)
Metodologia de desenvolvimento de software, nascida nos Estados
Unidos ao final da década de 90.
Auxilia a criação de sistemas de melhor qualidade, que são produzidas
em menos tempo e de forma mais econômica que o habitual
Princípios:
• Se o teste for bom, vamos testar o tempo
todo;
• Se as revisões de código são boas,
reveja o código o tempo todo;
• Se o design é bom, refatore o tempo
todo;
• Se a integração é boa, integre o tempo
todo;
• Se a simplicidade é boa, faça a coisa
mais simples e funcional;
• Se interações curtas são boas,
tornaremos a mais curta possível.
V
A
L
O
R
E
S
 Comunicação
 Coragem
 Feedback
 Simplicidade
 Respeito
Práticas de XP
6,5
1. Jogo de 
Planejamento 2. Toda equipe
3. Padrões de 
Codificação
4. Sistema de 
Metáforas
5. Propriedade 
coletiva do código 6. Ritmo sustentável
7. Programação 
em pares 8. Melhoria de design
6,59. Design Simples
10. Desenvolvimento 
Orientado a Testes
11. Integração 
Contínua 12. Refatoração
13. Pequenos 
lançamentos
3. Padrões de 
Codificação
Papeis e Responsabilidades
Comprometimento X Envolvimento
Para o Scrum existe dois tipos de papéis, os envolvidos e os comprometidos:
Pigs: comprometidos Chicken: envolvidos
Product Owner
É o especialista no produto, nas necessidades e prioridades do cliente, por
isso, toma decisões sobre o que o produto faz e também aquilo que não
faz. Ele é o responsável pelo backlog de produtos (product backlog).
Chamado de representante do cliente em ambientes não Scrum.
Desenvolve estratégia, 
direção e metas
Reúne, prioriza e 
gerencia os 
requisitos de 
produto
Aceita, rejeita e apresenta 
os trabalhos completos
Responsável pelo 
orçamento e 
rentabilidade
Transfere 
conhecimento de 
produto e decide 
data de liberação
Scrum Master
Também chamado de facilitador do projeto em ambientes não-
scrum,
Responsável por apoiar a equipe de desenvolvimento,
abrindo barreiras organizacionais e mantendo os processos fiéis
aos princípios ágeis.
Atua como um 
treinador do processo
Promove a 
cooperação entre as 
partes interessadas e 
a equipe scrum.
Ajuda a remover os 
impedimentos do 
projeto
Facilita a construção de 
um consenso na equipe 
Scrum
Protege a equipe 
Scrum de distrações 
organizacionais
SCRUM MASTER 
trabalhando para:
PRODUCT OWNER:
 Garantir que os objetivos, escopo e domínio do produto sejam
entendidos o melhor possível por todos do Time Scrum;
 Encontrar técnicas para o gerenciamento efetivos do Backlog do Produto;
 Ajudar o Time Scrum a entender as necessidades para ter itens do
Backlog do Produto claros e concisos;
 Compreender o planejamento do Produto em um ambiente empírico;
 Garantir que o Product Owner saiba como organizar o Backlog do Produto
para maximizar o valor;
 Compreender e praticar a agilidade;
 Facilitar os eventos conforme exigidos ou necessários.
SCRUM MASTER 
trabalhando para:
TIME DE DESENVOLVIMENTO:
 Treinar o Time de Desenvolvimento em 
autogerenciamento e interdisciplinaridade;
Ajudar o Time de Desenvolvimento na criação de produtos 
de alto valor;
Remover impedimentos para o progresso do Time de 
Desenvolvimento;
Facilitar os eventos SCRUM conforme exigidos ou 
necessários;
Treinar o Time de Desenvolvimento em ambientes 
organizacionais nos quais o Scrum não será totalmente 
adotado e compreendido.
SCRUM MASTER 
trabalhando para:
ORGANIZAÇÃO:
Liderando e treinando a organização na adoção do SCRUM;
Planejando implementações SCRUM dentro da organização;
Ajudando funcionários e partes interessadas a
compreender e tornar aplicável SCRUM e o
desenvolvimento de produto empírico;
Causando mudanças que aumentam a produtividade do
Time Scrum;
Trabalhando com os outros Scrum Masters para aumentar a
eficácia da aplicação do Scrum na organização.
Equipe de desenvolvimento
Pessoas que criam o produto. Os programadores, testadores,
designers., escritores e qualquer outra pessoa que tenha
um papel de “colocar a mão na massa” no
desenvolvimento do produto.
Diretamente 
responsável pela 
criação de entregas do 
projeto.
Auto organizada e auto 
gerenciada
Cross-funcional
Dedicada ao projeto 
durante toda sua 
existência
Idealmente alocada e 
trabalhando em 
conjunto numa mesma 
área do escritório
Resumo
Outros Papeis
Stakeholder é qualquer pessoa com interesse no projeto. O grupo
pode ser extenso e pode incluir pessoas de diferentes
departamentos, ou até mesmo de empresas
diferentes.
Exemplos: Clientes, pessoas técnicas, departamentos jurídicos,
vendas, marketing, especialistas em produtos
STAKEHOLDERS
O Agile Cocha/Mentor é alguém que possui experiência na
implementação de projetos ágeis e irá compartilhar suas
experiências através de feedbacks e conselhos.
Atua como orientador e não faz parte da equipe Scrum, sendo
muitas vezes alguém de fora da organização.
AGILE COACH
Outros papéis
Arquiteto
• Decide sobre estrutura, Modelo, etc...
• Revisa design e códigos;
• Possui skill técnico
Testador
• Constrói Frameworks para automatização dos testes;
• Auxilia nos testes orientados.
Gerente de Configuração
• Mantém repositório de Código
• Automatiza controle de código fonte.
Gerentes no Scrum
O Scrum não menciona o papel de “gerente”. A equipe Scrum
realiza a sua autogestão e é apoiada pelo Scrum Master.
A equipe é orientada pelo Product Owner em termos do
trabalho que é necessário fazer, bem como a sua priorização.
Comprometimento X Envolvimento
Comprometidos (porcos) Envolvidos (galinhas)
• Clientes
• Usuários finais
• Dono da empresa
• Gerência Sênior
• Arquiteto, etc ...
Equipes ágeis
Nas equipes ágeis devem existir todas as funcionalidades
necessárias para o desenvolvimento do trabalho, tonando-se assim
mais eficientes.
Características:
 Trabalham para expandir 
habilidades
 Ajudam quem enfrenta obstáculos
 Equipes flexíveis
 Não possuem funções/cargos
Equipes auto organizadas aproveitam melhor o conhecimento e 
experiência de seus membros
Características
 Compromisso com as metas das sprints
 Identificar suas tarefas
 Estima esforço dos requisitos e tarefas
 Comunicação transparente
Equipes ágeis
Auto gestão está diretamente relacionada a auto-organização. A equipe scrum tem a
responsabilidade de garantir o sucesso do projeto, garantindo assim o controle de como
eles funcionam.
Características:
 Permitir que a liderança flua normalmente
 Relatar progresso regularmente e de forma transparente
 Gerenciar problemas dentro da equipe de desenvolvimento
 Criar contrato de equipe
 Participar ativamente
Equipes ágeis são pequenas, pois quanto maior o tamanho maior é o esforço de gestão
da comunicação e gestão.
Características:
 Limitar o tamanho da equipe
 Desenvolver de habilidades incentivado
 Facilitar a boa comunicação 
 Manter a unidade da equipe
 Promover a comunicação face a face
Eventos SCRUM
Time-Boxing
 Cada evento possui um tempo máximo pré-
determinado, que garante uma quantidade
adequada de tempo em cada evento sem
desperdício.
 Time-boxing deve ser entendido como um intervalo
de tempo para realização de uma tarefa.
 O conceito de time-boxing também é aplicado para
as sprints (duração de 2 a 4 semanas)
VANTAGENS
Time-Boxing
VANTAGENS
1. Reuniões mais focadas e objetivas, conforme o
assunto a ser trabalhado
2. Os gestores e a equipe possuem melhor visão da
velocidade de trabalho e quantos itens do
backlog são entregues em cada Sprint.
3. Equipe focada nos itens a serem entregues.
4. Eliminação do desperdíciode tempo
5. Evita postergar tarefas difíceis de serem
realizadas
6. Valorização do tempo de trabalho da equipe
7. Dedicação exclusiva para as atividades dentro
do time-boxing
Input de Clientes, 
Equipes, Stakeholders, 
etc ...
A equipe define a 
partir da lista o que é 
será entregue até ao 
final da Sprint
Detalhamento das 
Tarefas
SCRUM MASTER
Sprints de
1-4 semanas
Reunião de 
Planejamento da Sprint
Backlog da Sprint
Reunião Diária 
Scrum (Daily)
Entregáveis e data final 
da Sprint não podem 
ser alterados
Revisão da Sprint
DoD
Trabalho Finalizado
Retrospectiva da Sprint
Dev Team
Sprint
Backlog da Produto
DoR
Input de Clientes, 
Equipes, Stakeholders, 
etc ...
A equipe define a 
partir da lista o que é 
será entregue até ao 
final da Sprint
Detalhamento das 
Tarefas
Sprints de
1-4 semanas
Reunião de 
Planejamento da Sprint
Backlog da Sprint
Reunião Diária 
Scrum (Daily)
Entregáveis e a data 
final da Sprint não 
poderão ser alterados
Revisão da Sprint
DoD
Trabalho Finalizado
Retrospectiva da Sprint
Dev Team
Planejamento da Sprint
Backlog da Produto
DoR
SCRUM MASTER
Entradas
Capacidade 
do Time
Backlog de 
Produto
Condições 
do Negócio
Incremento 
do produto 
recente
Tecnologia
Reunião de Planejamento da Sprint
Priorização da Sprint
• Análise e avaliação dos itens do Backlog
do Produto.
• Definição da Meta da Sprint.
Parte 1
Planejamento da Sprint
• Definição de como alcançar a
meta/objetivo da Sprint.
• Criação do Backlog da Sprint (tarefas) a
partir dos itens do Backlog do Produto
(histórias de usuário/funcionalidades).
• Estimativa do Backlog da Sprint em
pontos.
Parte 2
Entradas e Saídas da reunião de planejamento da 
Sprint
Saídas
Itens 
selecionados 
para a Sprint
Itens 
selecionados 
para a Sprint
Backlog da 
Sprint
Input de Clientes, 
Equipes, Stakeholders, 
etc ...
A equipe define a 
partir da lista o que é 
será entregue até ao 
final da Sprint
Detalhamento das 
Tarefas
Sprints de
1-4 semanas
Reunião de 
Planejamento da Sprint
Backlog da Sprint
Reunião Diária 
Scrum (Daily)
Entregáveis e a data 
final da Sprint não 
poderão ser alterados
Revisão da Sprint
DoD
Trabalho Finalizado
Retrospectiva da Sprint
Dev Team
Reunião Diária (Daily)
Backlog da Produto
DoR
SCRUM MASTER
Input de Clientes, 
Equipes, Stakeholders, 
etc ...
A equipe define a 
partir da lista o que é 
será entregue até ao 
final da Sprint
Detalhamento das 
Tarefas
Sprints de
1-4 semanas
Reunião de 
Planejamento da Sprint
Backlog da Sprint
Reunião Diária 
Scrum (Daily)
Entregáveis e a data 
final da Sprint não 
poderão ser alterados
Revisão da Sprint
DoD
Trabalho Finalizado
Retrospectiva da Sprint
Dev Team
Revisão da Sprint
Backlog da Produto
DoR
SCRUM MASTER
DoD – Definição de Pronto
A definição de finalizado é expressa através de critérios, ou seja,
etapas até que uma funcionalidade seja considerada pronta, essas
etapas variam de projeto para projeto e geralmente são definidas no
inicio.
A definição de pronto deve ser alinhada entre o Product Owner, time
desenvolvimento e o Scrum Master.
Exemplos de critérios que podem estar no DoD:
 Testar unitariamente ( utilizar TDD)
 Testar a integração com outros componentes (quando for o caso)
 Testar seguindo os critérios de aceitação estabelecidos com o cliente
 Com a entrada de nova funcionalidade, avaliar a necessidade de realizar refatoração em algum módulo do sistema
 Atualizar a documentação (se for necessário)
DoD – Definição de Pronto
Quem define a definição de “pronto”?
o Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento
da organização, todos os Times Scrum devem segui-la;
o Se “pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de
Desenvolvimento do Time Scrum, deve estruturar uma definição de “pronto” apropriada para o produto;
o Se houver múltiplos Times Scrum trabalhando no lançamento do software ou produto, os times de desenvolvimento
de todos os Times Scrum devem trabalhar em conjunto para estruturar a definição de “pronto”.
O Dono do Produto precisa aprovar a definição de “pronto”?
o O Time de Desenvolvimento estrutura a definição de “pronto”;
o É essencial que todos do Time Scrum estejam cientes da definição de “pronto”;
o Não há necessidade de obter aprovação do Product Owner.
Input de Clientes, 
Equipes, Stakeholders, 
etc ...
A equipe define a 
partir da lista o que é 
será entregue até ao 
final da Sprint
Detalhamento das 
Tarefas
Sprints de
1-4 semanas
Reunião de 
Planejamento da Sprint
Backlog da Sprint
Reunião Diária 
Scrum (Daily)
Entregáveis e a data 
final da Sprint não 
poderão ser alterados
Revisão da Sprint
DoD
Trabalho Finalizado
Retrospectiva da Sprint
Dev Team
Retrospectiva da Sprint
Backlog da Produto
DoR
SCRUM MASTER
Scrum Vs PDCA
• Dividir e Conquistar
 Dividir o trabalho complexo em pequenas tarefas
 Dividir as organizações em pequenas equipes’
 Dividir o tempo em pequenas etapas (sprints)
• Inspecionar e Adaptar
 Rever os planos/premissas regularmente
 Otimizar o valor entregue pelo produto
 Otimizar o processo
• Criar transparência
 Tornar o trabalho visível para os membros da equipe e as 
partes interessadas
 Conduzir a “saturação de comunicação” entre as equipes
 As pessoas decidem melhor quando possuem todas as 
informações 
Estabelecendo a 
Melhoria Contínua
Nos projetos de Melhoria Contínua precisamos
ter um backlog semelhante ao de
desenvolvimento de software. Este backlog
deverá acompanhar todo o esforço para adotar
o Scrum na organização
Os Backlogs de melhoria são dinâmicos, com
itens iniciais (Conscientização e Desejos). Se a
transformação já está em andamento, seu
Backlog poderá conter itens de
desenvolvimento dos times e as "ondas" de
implantação na organização.
Visão geral de Planejamento de Releases
Release N
Incremento
Planejamento
da release
Reuniões 
Diárias (time)
Planejamento
da Sprint 1
Sprint 
de Implantação
(P.O, AN, ARQ.)
Sprint 6
(2 Features)
Devs, AN, Q.A(Fábrica)
PO e SM (Azul)
Time
Sprint 5
(3 Features)
Sprint 4
(2 Features)
Sprint 3
(4 Features)
Sprint 2
(5 Features)
Sprint 1
(12 Features)
Release 1
Incremento Incremento
Revisão e 
Retrospectiva 
da Sprint
2 semanas 2 semanas 2 semanas 2 semanas 2 semanas 2 semanas
5 dias02/05 à 12/05 15/05 à 26/05 29/05 à 09/06 19/06 à 30/06 03/07 à 14/07 17/07 à 28/07 
Incremento Incremento Incremento
Grooming
contínuo
do backlog
Backlogs
Backlog de Produto
Product Owner
Responsável pela 
criação e manutenção 
do backlog de produtos
Equipe scrum
Utiliza o backlog no 
planejamento da 
Sprint e durante o 
projeto. Lista de todas as 
histórias de usuários 
associadas ao projeto
O backlog de produtos 
pode conter: 
 A descrição dos requisitos
 Ordem das histórias 
priorizadas
 Estimativas de esforço
Backlog do Produto precisa ser:
Detalhado de maneira apropriada: Claro o suficiente para executar, mas não detalhado demais. Itens
de Backlog que serão desenvolvidos na próxima Sprint precisam ser suficientemente entendidos e
detalhados. Itens que não serão desenvolvidos, podem estar descritos com menos detalhes
Estimado: todos os itens tem uma estimativa associada. O Backlog de Produto é mais que uma lista de
trabalho que precisa ser desenvolvido. Ele é também uma ferramenta de planejamento (plano de projeto).
Emergente: o Backlog evolui para refletir as novas necessidades, ele não é estático. Ele evoluirá com a
passar do tempo e novos itens poderão ser adicionados, ou itens removidos, atualizados, reordenados, etc.
Priorizado: determinado a encantar clientes e entregar valor. Deverá ser ordenador com os itens de maior
valor (importância) no topo.
Backlog da Sprint
Lista de histórias de usuários associadas a Sprint atual e tarefas relacionadas.
Ao planejar a Sprint, devemos:
 Estabelecer metas para a Sprint
 Escolher as histórias de usuários aderentes a metas da Sprint Quebras de histórias de usuários em tarefas específicas do desenvolvimento
 Criação de um Backlog da Sprint.
Backlog da Sprint:  Lista de histórias dentro da Sprint em ordem de prioridade
 Estimativa de esforço relativo para cada história de usuário
 Tarefas necessárias para o desenvolvimento de cada história de usuário
 O esforço em horas para concluir cada tarefa.
Histórias de usuário
Simples descrição de um requisito do produto em termos do que essa exigência deve
realizar e para quem.
- Independente (Independent)
- Negociável (Negotiable)
- Valioso (Valuable)
- Estimável (Estimable)
- Pequeno (Small)
- Testável (Testable)
Histórias de usuário épicas
Épicas são requisitos muito grandes que suportam uma
funcionalidade e contém várias ações. Torna-se
necessário quebra-las antes que possamos criar um
requisito de produto à partir delas.
A regra de ouro usual é de que “uma história
possa ser concluída dentro da interação”.
Técnicas quepodemos utilizar:
 Static v/s Dynamic
 Api Only v/s User Interface
 Buy v/s Build
 Bath v/s Onlin
 Single User v/s Multi-user
 Spike v/s Implementation.
Refinando os Itens do Backlog de Produto
Backlog da Produto
O Refinamento de Itens do Backlog representa o ato de rever e
revisar itens do Backlog de Produto, normalmente envolve a adição
de detalhes, estimativas, e ordem para eles.
Product Owner:
 Responsável por Ordenar (priorizar) os
itens, e a equipe de desenvolvimento é
responsável por estimar.
Tarefas de usuário
- Específica (Specific)
- Time-Boxed (Tempo máximo)
- Mensuável (Measurable)
- Alcansável (Achievable)
- Relevante (Relevant)
Planejamento no Scrum
Planejamento no Agile – Entregando Valor
Visão Roadmap
do produto
Plano de 
Liberação
Reunião diária 
scrum
Revisão da 
sprint
Retrospectiva 
da sprint
Planejamento da sprint
Planning Onion
Estratégia 
Empresarial
Estratégia 
Empresarial
Visão do ProdutoVisão do Produto
Roadmap do 
Produto
Roadmap do 
Produto
Planejamento 
de Liberação
Planejamento 
de Liberação
Planejamento 
da Sprint
Planejamento 
da Sprint
Planeja
mento 
Diário
Planeja
mento 
Diário
Posicionamento do projeto no Planejamento Estratégico da
empresa.
Qual a visão de produto? Aonde queremos chegar? Quais
são as metas?
Como faremos para entregar a visão do produto? Qual a
estratégia? Como entregar valor antecipadamente?
Como faremos para entregar a visão do produto? Qual a
estratégia? Como entregar valor antecipadamente?
O que entregaremos na proxima interação?
Vamos cumprir o objetivo? Há necessidade de adaptação?
Planejamento de Entregas
Implantação
Grupo de funcionalidades
utilizáveis de um produto que
será implantado em produção
Versão de Software
Grupo de funcionalidades
mínimas para comercialização
que podemos efetivamente
implantar e promover no
mercado
Planejamento
Estabelecer o conjunto de
funcionalidades e a data de
lançamento
Planejamento da versão de entrega
1. Determine as 
condições de 
satisfação
2. Estimar 
histórias de 
usuários
3. Selecione a 
duração de Sprint
4. Estime a 
velocidade
5. Priorize as 
histórias e a data 
de liberaçao
Fazer em qualquer sequência
5. Selecione as 
histórias e a data 
de liberação
Sprint de
1-4 semanas
Planejamento da Sprint
Sprint é uma interação
consistente de um tempo que a
equipe cria um grupo específico
de funcionalidades do produto
do começo ao fim.
Sprint é uma interação
consistente de um tempo que a
equipe cria um grupo específico
de funcionalidades do produto
do começo ao fim.
 Planejamento da Sprint no início de cada
uma delas;
 Reuniões diárias do Scrum;
 Tempo de desenvolvimento – a maior pare
da Sprint;
 Revisão da Sprint e um Retrospectiva da
Sprint no final de cada uma.
Cada Sprint incluí o seguinte:
A reunião de planejamento da sprint
No primeiro dia de cada Sprint a
equipe Scrum deve realizar a
reunião de Planejamento da
Sprint
Timeboxing: Não devem durar
mais que duas horas por semana
de Sprint.
Dividir a reunião em duas partes:
 Definir a Meta da Sprint e
escolher as histórias de
usuários;
 Quebrar as histórias de usuário
em tarefas individuais;
Definindo a meta da sprint
P.O Time de 
Desenvolvimento
Scrum 
Master
 No Início da reunião de planejamento da Sprint, o Product
Owner e a equipe de desenvolvimento devem determinar
uma meta para a Sprint.
 Através da meta da Sprint determinamos as histórias de
usuários que pertencem a esta Sprint. Também obtemos
um outro olhar em relação as estimativas para estas
histórias e podemos propor alteração nas estimativas,
para os casos onde seja necessário.
 A segunda parte da revisão de histórias de usuários irá
confirmar se as estimativas de esforço para cada história
de usuário estejam corretas. Ajustar as estimativas se
necessário.
 Uma vez que definimos a meta da Sprint, histórias de
usuários para a Sprint, e o compromisso com a meta,
iremos para a segunda parte do planejamento da Sprint.
Quebrando histórias de usuários em tarefas 
individuais
Título
Como
Eu gostaria de
Para que
1. Criar uma tela de autenticação contendo um nome de usuário e senha, com um botão enviar;
2. Criar uma tela de erro para o usuário solicitando reinserir as credenciais novamente;
3. Criar uma tela de login (a inclusão da lista de contas será concluída na próxima história de
usuário.
Desmembramento 
das Tarefas
Equipe
Exemplo
Após quebrar as histórias em tarefas
deve ser atribuído um número de horas
para cada tarefa.
Sprint 1: 25 por cento do
que a equipe pensa que
pode realizar;
Sprint 2: 50 por cento do
que a equipe pensa que
pode realizar;
Sprint 3: 75 por cento do
que a equipe pensa que
pode realizar;
Sprint 4 e demais: 100 por
cento.
Velocidade
Velocidade no Scrum, é a agilidade de trabalho de uma equipe
de desenvolvimento.
É medida pelo número de pontos da história de usuário que a
equipe de desenvolvimento completa em cada Sprint.
Pontos de história de usuário são números relativos que descrevem a quantidade de
esforço necessário para desenvolver uma história de usuário.
Pontos da história é uma pontuação relativa para representar o valor do esforço para cada 
requisito.
Sequência de Fibonacci
É uma sequência de números inteiros começando por 0 ou 1,
na qual, cada termo subsequente corresponde a soma dos dois
anteriores.
A principal razão que nos leva a utilizar a sequência de
Fibonacci como melhor opção, é refletir na inerente incerteza
que podemos ter em estimativas de itens maiores.
Exemplo da sequência Fibonacci:
1, 2, 3, 5, 8, 13, 20, 40, 100
Story Points
• Story points são uma unidade de medida para
expressar o tamanho de um épico, feature ou
história. Ao estimar um item, deve-se atribuir a ele
um valor em pontos. O valor em si não é importante,
o que importa é um valor relativo a outro. Uma
história de dois pontos deve ser o dobro de uma
com 1 ponto e 2/3 de uma com 3 pontos.
• Não há uma fórmula para se calcular o tamanho de
uma história, mas devem ser consideradas
características como o esforço estimado, a
complexidade do desenvolvimento, o risco e outras.
Story Points ajudam a resolver 2 problemas
clássicos de estimativa de demandas:
1 – Pessoas costumam falhar ao predizer o
tamanho exato do trabalho;
2 – Processos complexos de estimativa;
Planning Poker
3 3
5
3
7
O significado dos valores é relativo – uma história de pontuação 8 demanda aproximadamente quatro vezes mais esforço que
uma de pontuação 2. Porém o tempo de execução (trabalho) não importa, somente o esforço.
Para começar a estimar, a equipe deve pegar a estória que julga ser a de menor esforço e atribuir a pontuação 2. Esta
primeira história é chamada de referência e as demais histórias deverão seguir uma pontuação relativa a essa primeira.
Dicas do Planning Poker
01
No caso da equipe jogar as cartas para estimar e a carta vencedora for a
carta de interrogação ou a 100, a equipe deve devolver a história ou a tarefa
para o Product Owner;
02 Sem um acordo sobre a estimativa de uma estória ou tarefa, maisumarodada deve ser realizada, com breves discussões entre elas;
03 Caso o limite seja atingido sem um acordo, a equipe deve optar pelaestimativa mais alta e encerrar as discussões da história;
04 Geralmente o número de rodadas limita-se no máximo a quatro por história;
05 Em uma equipe, a velocidade do mais lento deve ser considerada avelocidade da equipe toda.
Definindo Horas por ponto de história
História 1
3 Pontos
História 2
3 Pontos
História 4
1 Pontos
História 3
3 Pontos
Sprint 1
História 1
10 Pontos
História 4
10 Pontos
História 3
10 Pontos
Sprint 2
Total de 10 pontos
10 pontos = 8 horas de esforço
Total de 40 pontos
40 pontos = 8 horas de esforço
História 1
10 Pontos
Estimativas de afinidade
Planning pôquer pode ser eficaz, mas se
temos muitas histórias de usuário?
Vantagens:
 Rápido e eficaz;
 Fácil tomada de decisão;
 Experiência positiva sem 
confrontos
Muitas das estimativas são
provavelmente similares com uma
quantidade similar de esforço para
serem concluídas.
Categorize rapidamente as histórias
de usuários e aplique as estimativas
para essas categorias de histórias.
Estimativa de afinidade - processo
PP P M G GG
Menor Maior
 Selecione o conjunto de histórias e escreva uma história em um post-it ou em um
cartão
 Solicite aos membros da equipe que classifique as histórias da menor para a maior;
 Este processo pode exigir alguma discussão e interações para que a equipe
concorde com a ordem da classificação
Triangulação
Dias Ideais
Dias ideais não tem distrações como: email, 
atividade pessoal, paradas pra café, etc
Quantos dias durante 
uma semana podemos 
considerar como dias 
ideais de trabalho?
O agile usa seis horas ideais por dia (para um dia com 
oito horas) de cada membro da equipe. 
Este item deve ser
considerado e ajustado para
que o planejamento e
capacidade tenha sucesso
Ordenando os itens do Backlog de Produto
Cabe ao Product Owner encontrar a melhor maneira possível de ordenar os itens do Backlog de Produto,
mas os critérios habituais estão relacionados com os seguintes conceitos:
 Benefícios
 Custos
 Riscos
Valor para o negócio são os benefícios em relação a: Custo, Benefícios e Riscos e por isso 
devemos considerar todos.
Metodologia de desenvolvimento de sistemas 
dinâmicos
(D)
MoSCoW Must(Deve ter)
Should
(Deveria ter)
Could
(Poderia ter)
Won´t
(Não quer ter)
Must
Must
Must
Must
Must
Must
Must
Must
Should
Should
Should
Must
Won´t
Won´t
Could
Could
Tempo
Esforço
Monitoramento de Projetos com SCRUM
Índice de sucesso das metas das sprints
A Sprint pode não precisar de todos 
os requisitos e tarefas do Backlog da 
Sprint para ser concluído
Uma Sprint de sucesso deve possuir 
uma funcionalidade do produto de 
trabalho que cumpre com as metas 
da Sprint e atenda a descrição da 
equipe Scrum de pronto: 
desenvolvido, testado, integrado e 
documentado.
Ao longo do projeto, a Equipe Scrum
pode controlar a frequência com 
que ela consegue atingir as metas 
da Sprint e utilizar as taxas de sucesso 
para saber se a equipe está 
amadurecendo ou precisa corrigir 
seu curso.
Taxas de sucesso da Sprint é um 
ponto de partida útil para inspeção e 
adaptação.
Defeitos fugitivos
Um defeito fugitivo é aquele defeito que não foi
encontrado pela equipe de garantia da qualidade.
Normalmente esses defeitos são encontrados por
usuários finais após a versão de lançamento.
A métrica é utilizada para determinar o número de
novos defeitos fugitivos ao longo do período de tempo
(dia, semana e mês).
Duração do Projeto
Os projetos ágeis devem ser realizados mais rapidamente
que projetos tradicionais.
Ao iniciar o desenvolvimento mais cedo e cortar os bloatware
- requisitos desnecessários – equipes de projetos ágeis podem
entregar projetos mais rapidamente.
Medir a duração total do projeto ajuda a demonstrar a
eficiência.
Tempo para o Mercado
Tempo para o mercado é a quantidade de tempo que um projeto ágil leva para fornecer
valor ao lançar produtos de trabalho e funcionalidades para os usuários.
Custo total do Projeto
Os custos dos projetos ágeis estão diretamente relacionados a sua
duração. Como os projetos ágeis são mais rápidos do que processos
tradicionais eles também pode custar menos
As organizações podem usar as metas de custo de projeto para
planejar orçamentos e determinar o retorno sobre o investimento
Retorno sobre o investimento (ROI) é a renda gerada pelo produto,
menos os custos. Em projetos ágeis, o ROI é fundamentalmente diferente
do que em projetos tradicionais.
Projetos ágeis tem o potencial de gerar renda em sua primeira
versão e pode aumentar a receita em cada novo lançamento
Gráficos do Scrum
Gráfico Burn-Down
Poderosa ferramenta para a visualização do progresso e do
trabalho restante. O gráfico mostra o seguinte:
 O trabalho (em horas) no primeiro eixo vertical;
 Tempo, em dias, no eixo horizontal
Com o gráfico, podemos dizer
como o trabalho está progredindo:
 Esperado
 Mais complicado
 Menos complicado
 Não atualização
 Mentir
 Falhando rápido
Gráfico Burn-Down Bars
• Os gráficos de burndown com barras refletem o andamento
do projeto inteiro e não de uma interação isolada
• A partir do seu uso é possível identificar mudanças na
velocidade e no escopo do proeto.
• O progresso do projeto é mostrado acima da linha de base
do gráfico.
• Cada barra reflete uma interação (eixo
horizontal). A altura das barras demonstra a
quantidade de trabalho (esforço) que ainda falta
ser realizado no release, medido em pontos por
história, horas ou outra medida (no eixo vertical).
• Cada barra é desenhada antes do início de cada
interação com os dados referentes ao resultado a
interação anterior.
Gráfico Burnup Charts
• Os gráficos tipo “UP” mostram a quantidade de pontos
‘finalizados’, ‘prontos’, em vez do trabalho restante /
remanescente.
• A linha azul mostra o volume total de histórias definidas
no Backlog do Produto até o momento (incluindo as
histórias prontas que foram removidas do backlog do
produto), mostrando assim as mudanças que houveram
no Backlog do Produto.
• A linha vermelha mostra o volume de histórias prontas.
Diagrama de Fluxo Acumulativo
É o gráfico que lhe dá uma visão geral do que
está acontecendo em um projeto ou produto.
Por um lado, no diagrama de fluxo acumulativo
encontramos informações sobre o estado típico
de trabalho o quanto de trabalho está completo,
em andamento e em Backlog, e qual é o ritmo
de progresso, etc.
Kanban
Diagrama de Parking Lot
A codificação de cores baseada em semáforo representa a urgência. O tamanho de cada box é
relativo ao número de pontos de história que ele possui.
Em
andamento
Prazo perdido
No 
prazo
Gráfico de Defeitos Fugitivos
Demonstra o número de defeitos fugitivos encontrados ao longo do tempo (dia, semana ou mês)
Uma boa apresentação é um gráfico de barras, onde cada barra mostra o número de defeitos
fugitivos que foram encontrados (dia / semana / mês / trimestre / ano)
Uma boa apresentação é um gráfico de barras, onde cada barra mostra o número de defeitos
fugitivos que foram encontrados (dia / semana / mês / trimestre / ano)
Gráfico de Velocidade
Um gráfico de velocidade mostra a quantidade de esforço que a equipe relatou para completar cada Sprint.
A VELOCIDADE é calculado somando o número de pontos da História atribuídos a 
cada História de Usuário que a equipe completou durante a Interação.
1. Velocidade da Ultima 
Sprint.
2. Velocidade Média
Calendário Niko Niko
Radiador de Informações
É um grande display de informações críticas da equipe.
Localizado em um local onde as pessoas possam visualizar e
obter informações facilmente sobre como está o andamento
do trabalho ao longo do tempo.
Demonstra aos leitores informações que eles precisam, sem ter
que pedir a alguém. Isso significa mais comunicação com
menos interrupções e atualizações fácies de se manter.
Scrum para projetos de manutenção e contratos 
de preço fixo
Scrum em projetosde manutenção
Metodologias ágeis 
podem ser utilizadas 
para projetos de 
manutenção 
(correções e 
melhorias)
Práticas que podem ser utilizadas
para este tipos de projetos com
pouca ou nenhuma adaptação
• Reuniões diárias scrum;
• Scrum of scruns;
• Radiadores de informações;
• Uso de páginas wiki para colaboração
entre clientes e equipe;
• Workshop de requisitos para melhor
compreensão de defeitos completos
por parte da equipe;
• Revisão e retrospectiva.
Tipos de Contratos em
Projetos ágeis.
Projetos Preço Fixo
Comece com um orçamento definido. Em um projeto de
preço fixo, um fornecedor trabalha com o produto e cria
lançamentos até que utilize todo o dinheiro do orçamento,
ou até que tenha sido entregue as funcionalidades do
produto, ou o que ocorrer primeiro
Tipos de Contratos em
Projetos ágeis.
Projetos Tempo Fixo
Possuí prazos especificos. Com o projetos de tempo fixo,
determinamos os custos com base no custo da equipe do
fornecedor para a duração do projeto, juntamente com todos os
custos de recursos adicionais tais como hardware e software. Por
exemplo, Podemos precisar lançar um produto em tempo para a
próxima temporada de férias, para um evento específico, ou para
coincidir com o lançamento de outro produto.
Tipos de Contratos em
Projetos ágeis.
Projetos de Tempo e Materiais
São mais abertos do que projetos de tempo e preço fixo.
Dentro de projetos de tempo e materiais, o trabalho com
fornecedor dura até que a funcionalidade do produto esteja
complete o suficiente, sem levar em conta o custo total do
projeto. Em um projeto de tempo e materiais, sabemos o custo
total do projeto no final do projeto, uma vez que partes
interessadas determinam que o projeto possuem
funcionalidades suficientes para considerer o projeto completo.
Tipos de Contratos em
Projetos ágeis.
Projetos que não podem exceeder.
São projetos em que o tempo e os materiais possuem um
limite de preço fixo..
Papel do Scrum Master em Contratos
O Scrum Master é 
responsável por auxiliar na 
criação de um contrato 
(jurídico pode ajudar).
Deve adicionar valor ao 
contrato, trabalhando de 
maneira estreita com o 
fornecedor para melhor 
alinhamento.
Negocia detalhes do contrato 
e realiza encaminhamentos 
para aprovações internas.
Contratos
Um Contrato deve Incluir no mínimo:
 Descrição do trabalho que o fornecedor irá entregar;
 Abordagens ágeis que o fornecedor poderá utilizar. Elas podem
incluir:
 Reuniões que o fornecedor poderá participar;
 Entrega de funcionalidades de trabalho no final de cada Sprint;
 A definição de feito;
 Artefatos que o fornecedor irá fornecer;
 Se o fornecedor irá trabalhar no local de sua organização;
 Se o fornecedor irá usar o seu próprio Scrum Master e Product Owner;
 A definição do que pode constituir o final do contrato: o final de um 
orçamento fixo ou tempo fixo, ou suficientemente complexo, a 
funcionalidade de trabalho;
 Se o fornecedor não utiliza de abordagens ágeis, descrever
como o fornecedor e o seu trabalho irá integrar com a equipe e 
sprints do comprador.
Adotando
o Ágil
Cinco atividades são necessárias para adoção bem-
sucedida e duradoura do Scrum
A – CONSCIÊNCIA das falhas correntes
D - DESEJO de adotar o Scrum p/resolver os problemas
A - HABILIDADE de ser bem sucedido
P - PROMOÇÃO através da troca de experiências
T - TRANSFERÊNCIA do uso para toda a empresa.
Método ADAPT
A mudança começa com a consciência de que a
situação precisa ser mudada. No entendo,
conscientizar-se de que o que funcionou no passado
não está mais funcionando pode ser extremamente
difícil.
Razão comum pela qual os indivíduos podem demorar a
resolver uma consciência da necessidade de mudar a
falta de entendimento do todo.
 A necessidade de adotar o Scrum pode ser resultado
de uma série de fatores visíveis para todos.
 A necessidade de uma mudança pode vir de uma
série de fatores, entre eles, declínio nas vendas,
rumores de um novo concorrente, etc ...
Método ADAPT
CONSCIÊNCIA
Além de estar ciente da necessidade de mudança,
também é preciso ter o desejo de mudar.
Ter a consciência de que o processo de
desenvolvimento atual não está mais funcionando para
trocar de metodologia, pode ser muito difícil para as
pessoas.
Como desenvolver o Desejo:
 Comunique-se de uma maneira melhor
 Crie um senso de urgência
 Fazer um test drive com o SCRUM.
 Ajude as pessoas na adoção
 Não desfaça do passado dos projetos da empresa.
 Envolva o máximo de funcionários neste esforço
Método ADAPT
DESEJO
Toda a conscientização e o desejo do mundo não
levarão uma equipe a nenhum lugar se ela também não
adquirir a habilidade de ser ágil.
Ter sucesso com o Scrum requer que os membros da
equipe não apenas aprendam novas habiliaddes, mas
também desaprenderem os antigos.
Como desenvolver Habilidade:
 Fornecer coaching e treinamento
 Mantenha os indivíduos responsáveis
 Compartilhar informação
 Defina metas razoáveis
Método ADAPT
HABILIDADE
São 3 (três) objetivos durante a promoção do SCRUM:
1. Estabelecer bases para o próximo ciclo ADAPT.
Essas bases são feitas com a promoção dos
sucessos atuais para começar a criar
conscientização para o próximo ciclo.
2. Reforçar o comportamento ágil nas equipes
existentes, divulgando os progressos das equipes
ágeis.
3. Criar consciência e interesse entre os que não
participam das equipes que está implantando o
ágil.
Como fazer a Promoção?
- Divulgue os cases de sucesso
- atraia atenção e interesse da organização
Método ADAPT
PROMOÇÃO
Se as implicações do uso do Scrum não forem
transferidas para outros departamentos, as
necessidades destes departamentos acabarão
atrasando e matando todo os esforço de
transformação. Ou seja, toda a organização precisa se
entender e aceitar o Scrum.
Método ADAPT
TRANSFERÊNCIA
babiestefani89@gmail.com
Progresso da Comunicação
Comunicação
A comunicação é o principal forma de
resolver problemas no
desenvolvimento de software, seja ele
de entendimentos, regras definidas,
resultados esperados e até conflitos de
relacionamentos.
A melhor forma de comunicação é o 
diálogo e a comunicação face-to-face.
Comunicação
 O Scrum Master pode demonstrar o
funcionamento da sprint via
radiadores da informação, utilizando
quadro de tarefas e/ou Gráfico
Burndown, ao cliente, estimulando-
o a monitorá-lo e a acompanhar o
andamento e a evolução das sprints.
 Uma comunicação eficaz aumenta a
eficácia da transformação no cliente,
no que diz respeito a conceitos e
técnicas ágeis.
A função do Scrum Master na 
reunião diária é apenas garantir que 
ela ocorra com o Time de 
Desenvolvimento.
Reunião Diária
A reunião diária é uma oportunidade de
inspeção do progresso na direção da
meta da Sprint, mas não pode ser
realizada para resolver problemas, com
o objetivo de alcançar a meta.
Um formato muito utilizado para as
reuniões diárias é o Stand-up Meeting,
que significa "reunião em pé".
O time deve se encontrar diariamente para uma reunião de no máximo 15 minutos, 
chamada de reunião diária ou Daily Meeting.
Impedimentos
Um dos objetivos do Scrum Master, e que aparece
fortemente na reunião diária, é remover os
impedimentos ou problemas do Time na execução de
suas tarefas.
É tarefa do Scrum Master estimular os membros do
Time durante a reunião diária, para que eles
comuniquem impedimentos ao longo da reunião.
Impedimentos destes que podem ser comunicados
também durante todos os trabalhos do time.
Radiadores de Informações
Quadro de Tarefas (Kanban)
O quadro de tarefas (kanban) é um excelente
mecanismo de organização do trabalho do time e uma
maneira de ver rapidamente o trabalho restante. É
importante que este garanta flexibilidade na
organização do quadro e que demostre claramente
todas as tarefas que estão sendo trabalhadas e quais
estão disponíveis.
Gráfico de Gantt
O uso deste gráfico por algumas empresas para
prever, programar e coordenar tarefas. Porém este
gráfico era um dos principais de outro framework o
que levou a desuso depois da entradado Agile.
Porém pode ser um ótimo recurso para
demonstração de alocação de recursos nas
interações.
Acompanhando Bugs em um Quadro 
de Tarefas.
O framework não define uma forma dos times
trabalharem com os erros encontrados. Cada time
irá achar uma forma de trabalhar com eles no seu
Quadro de tarefas, destacando os mesmos em uma
“raia” prioritária ou com post-it de cor diferente.
Muitas vezes as equipes confundem Bugs com
Débitos Técnicos.
Débito Técnico
É um conceito no desenvolvimento de software que reflete o
custo implícito de retrabalho adicional causado pela escolha
de uma solução fácil (limitada) agora de usar uma abordagem
melhor que levaria mais tempo.
Assim como a dívida monetária, se a dívida técnica não for
paga, ela pode acumular 'juros', dificultando a
implementação de mudanças. A dívida técnica não
endereçada aumenta a complexidade no desenvolvimento de
software. A dívida técnica não é necessariamente uma coisa
ruim e, às vezes (por exemplo, como prova de conceito) é
necessária para avançar os projetos. Por outro lado, alguns
especialistas afirmam que a metáfora da "dívida técnica"
tende a minimizar o impacto, o que resulta em priorização
insuficiente do trabalho necessário para corrigi-lo.
Trabalhando
com projetos
complexos
Escalando Grandes Projetos
Grandes projetos são frequentemente mais críticos para a
empresa, estão sob maior cobrança e conflitos, podendo
também serem distribuídos em vários locais.
Daily com 100 pessoas (9 segundos para cada participante) ?
Gerenciamento do escopo da Sprint
Restrição do número de pessoas em uma equipe Scrum.
Medição de desempenho da equipe.
Product Backlog Único
Existe apenas um único Product backlog para todas as
equipes, entendido em um nível no qual as
dependências possam ser detectadas e minimizadas.
O Product Owner é o responsável pelo Product
Backlog, incluindo seu conteúdo, disponibilidade e
pedidos.
A divisão nos times será feita por Features e/ou
Componentes.
Scrum of Scrums
Equipe A
Equipe B
Equipe C
Scrum of scrums
Um Scrum of Scrums é o mecanismo usual
que coordena várias equipes trabalhando
em um único projeto, mantendo todas as
equipes atualizadas com as Informações e
todas as outras equipes.
Um representante de dada equipe vai a
reunião do Scrum of Scrums e:
• Ouve o que as outras equipes estão
fazendo,
• Conta o que sua equipe está fazendo e
• Depois da reunião, atualiza seus colegas.
Scrum of Scrums
Equipe A
Equipe B
Equipe C
Scrum of scrums
Problemas que podem ser enfrentados:
 Falta de visão unificada do 
produto/serviço;
 Redundância de trabalho;
 Comunicação falha;
 Integration hall (diferentes partes do 
produto com equipes diferentes);
 Dependências entre tarefas de times 
diferentes;
 Gestão de mudanças completas.
 ....
Grandes Projetos
EQUIPE C EQUIPE C
EQUIPE B
EQUIPE A EQUIPE A EQUIPE AEQUIPE A
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Trabalhando com equipes distribuídas
Boas práticas com equipes distribuídas
 Use tecnologias de videoconferência para simular conversas face-
to-face;
 Se possível, envie os membros da Equipe Scrum para reunião
pessoalmente em um local central;
 Use uma ferramenta de colaboração on-line;
 Inclua imagens dos membros da Equipe Scrum em ferramentas de
colaboração on-line;
 Seja consciente e flexível com as diferenças de fuso horário;
 Se tiver alguma dúvida sobre uma conversa ou um e-mail, peça
esclarecimentos;
 Esteja ciente das diferenças linguísticas e culturais entre os
membros;
 Discuta assuntos não relacionados ao trabalho.
Ferramentas - Gestão de Backlog/Tarefas
Ferramentas - Gestão de 
Backlog/tarefas
 Kanbanize – kanbanize.com
 ScrumHalf - http://myscrumhalf.com/?lang=pt
 Trello - https://trello.com
 Artia – artia.com
 Jira – https://www.atlassian.com/software/jira
137