O documento descreve o papel e as responsabilidades do Scrum Master, destacando a importância de remover impedimentos, garantir a proteção do time e promover a melhoria contínua. Enfatiza também que não cabe ao Scrum Master definir soluções técnicas ou gerenciar tarefas, além de fornecer dicas para motivação e eficiência do time. A atuação do Scrum Master depende da maturidade do time e do ambiente, e deve focar em criar uma cultura de feedback e adaptação.

1. Guia do Papel e
Responsabilidade do Scrum
Master

2. ● Remover os impedimentos do time. Sejam técnicos, operacionais
ou organizacionais.
● Garantir que o time não sofra interferência externas, mantendo o
time protegido.
● Garantir que o método seja seguido sempre buscando a melhoria
contínua.
● Facilitar as cerimônias realizando toda a organização e a
preparação.
O Papel do Scrum Master

3. ● Garantir que o time se comprometeu com as entregas, não
permitindo que o time assuma mais trabalho do que realmente
consegue entregar.
● Motivar a produtividade do time mostrando os resultados.
● Gerar transparência do andamentos das demandas.
● Garantir o compromisso do time com os critérios de aceite
estabelecidos pelo P.O..
● O Scrum Master é o responsável por garantir que o scrum seja
entendido e aplicado.
● Transparência, inspeção e adaptação.

4. Não é Papel do Scrum Master
● Definir a solução técnica, arquitetura ou modelo de
desenvolvimento.
● Estimar o trabalho a ser realizado.
● Definir as tarefas necessárias para a entrega de cada requisito.
● Gerenciar o time. O time é auto-gerenciável.
● Priorizar as histórias ou alterar a priorização definida pelo P.O..
● Distribuir as tarefas entre os membros do time.
● Definir os critérios de aceite das entregas.
● Estabelecer os critérios de aceite.
● Detalhar os requisitos ou definir regras de negócios.

5. Dicas 1/7
❏ Impedimentos... Um bom Scrum Master precisa se atentar aos detalhes do dia a dia para se
antecipar a possíveis impedimentos que o team possa ter (Victor Eiras)
❏ Motivação... Acredito que seja de fundamental importância um Scrum Master saber motivar sua
equipe, seja mostrando os resultados para todos, seja conversando com cada um
individualmente, pois cada pessoa é diferente da outra, existindo maneiras únicas de se sentir
motivada, portanto o Scrum Master precisa entender essas formas de abordagens para cada
perfil (Victor Eiras)
❏ Entregas.. o time precisa ter software funcionando sem bugs(ou já corrigidos) ao final da sprint.
Se assumir mais trabalho que a capacidade terão iniciado muitas tarefas, porém sem concluir,
ou com muitos bugs abertos. Conceito Lean de Jidoka - fazer certo já na primeira vez, isto traz
uma produtividade muito grande ao time (Thiago Torricely)
❏ "Priorizar as histórias ou alterar a priorização definida pelo P.O": Nesse ponto, concordo que
não seja uma atribuição do SM, mas o SM pode sempre auxiliar o PO nessa tarefa (Paulo
Lomanto)
❏ O SM é a consciência (bom ou ruim) do Time ;) (Cihangir Deniz Ozdemir)

6. Dicas 2/7
❏ Mostrando resultados... Se o time não tem visibilidade de seus resultados, logo sentirão
desmotivados (Thiago Torricely)
❏ Mais trabalho que a capacidade...Times podem ser otimistas em sua capacidade de concluir
demandas, mas fazendo isto podem falhar em reduzir o débito técnico e afiar suas serras.
Gerentes também pressionam times para entregar acima da capacidade por uma falta de
entendimento básico de práticas Lean. O estresse em cima de escopo excessivo pode causar
desaceleração maciça na equipe. Muri - uma das 3 formas de desperdício no Lean. Logo não
conseguirão completar o backlog da sprint, fazendo o time se sentir desmoralizado e
sobrecarregado, todos ficam infelizes.E não terão tempo para pensar claramente sobre como
melhorar o trabalho na próxima sprint. Todos exibirão os sintomas de times de esportes quando
perdem. Pegando menos trabalho na Sprint irá maximizar a probabilidade de sucesso, e através
das melhorias contínuas o time conseguirá aumentar a capacidade de aceleração gradualmente
(Thiago Torricely)
❏ Complementando o comentário do Thiago Torricely. O importante é o time entender que deve
parar de começar e comece a terminar. Limitando o trabalho em andamento e focando nas
estórias, uma vez que já foram definidas as prioridades. Após termos a expertise de quantas
estórias em paralelo o time suporta com qualidade na execução, podemos tomar as decisões
em aumentar o fluxo em andamento ou não (Vitor Martinez)

7. Dicas 3/7
❏ Os itens “Não é Papel do Scrum Master” não são executados pelos Scrum Master, porém o
Scrum Master também precisa garantir que isto esteja sendo feito da melhor forma, realizando
coach do time para melhorar nestes pontos. Exemplo: Ajudar o PO a como estabelecer e
elaborar melhores critérios de aceite, Ajudar aplicar melhor os conceitos de INVEST nas
histórias até virar habito do time, Fazer coach do time em utilização de técnicas de estimativas
como Story Points, Verificar juntamente a equipe se os requisitos e regras de negócios estão
claras, e o que pode ser melhorado. Engraçado, que pode existir muita atividade para o SM
ajudar o time onde não está muito explícito sua atuação (Thiago Torricelly)
❏ Sobre "gerenciar o time". Até o time conseguir ser auto-gerenciavel, pode ser papel do SM um
certo nível de interferência, mas não de forma muito intrusiva e autoritária, no processo de
gerenciamento. O SM pode adotar algumas técnicas que direcionam o time, mas sempre
mostrando a eles que caberá no futuro a eles as suas decisões. Afinal, nenhuma equipe
"nasce" auto-gerenciável e pode necessitar de alguns passos iniciais, e ninguém melhor que o
SM para dar esse "empurrãozinho" (Paulo Lomanto)
❏ A atuação do Scrum Master vai depender muito da maturidade do time (Cihangir Deniz
Ozdemir)

8. Dicas 4/7
❏ Será que um scrum master pode fazer parte do team(desenvolvendo)? Um scrum master que
assume a responsabilidade de uma tarefa perde a visão do "todo", deixando o processo
vulnerável (Victor Eiras)
❏ Este item é interessante. Eu já fiz parte de equipe de code e ainda sendo scrum master. Eu
deixava fora da velocidade da equipe a minha capacidade de produção, para que a equipe não
contasse comigo nas suas metas (Abu)
❏ Abu, perfeito comentário. Já atuei também como coder de algumas equipes das quais eu
também era SM. A sua colocação sobre o tempo é essencial nesse caso. As atividades que um
SM pode assumir durante a Sprint não podem ser contabilizadas como tempo útil, visto que a
sua demanda em atividades que não as de coder podem acabar por prejudicar a performance
da sprint (Paulo Lomanto)
❏ Ainda na linha de garantir padrões, o SM não é responsável pela solução técnica, mas deve
garantir que os padrões técnicos e arquiteturais são seguidos (Douglas Serra Braga)

9. Dicas 5/7
❏ Ref. Impedimentos: Visando o Futuro do time, com o objetivo de elevar a maturidade do time,
dependendo da maturidade atual, o SM também deve ajudar o time a remover impedimentos
(Cihangir Deniz Ozdemir)
❏ Ref. Imepdimentos/ Limitacoes: Ajudar o Time a aceitar as coisas que nesse momento não
podem ser mudadas e aprender conviver com as limitações, sem sacrificar a motivação
(Cihangir Deniz Ozdemir)
❏ Três simples verdades: 1. é impossível enxergar todos os requerimentos no começo do projeto;
2. Não importa os requerimentos que você tenha, é garantido que eles irão mudar; 3. Sempre
haverá mais para fazer do que tempo e dinheiro disponível. Aceitando a primeira verdade quer
dizer que você não terá mais medo de começar sua jornada sem saber tudo que está pela
frente.Você descobre que requerimentos são feitos para serem descobertos. Aceitando a
segunda verdade quer dizer você não terá mais medo da mudança, você sabe que ela virá.
Você adapta seu plano quando necessário e segue em frente. E aceitando a terceira verdade
você não irá mais se estressar quando sua To-Do list exceder seu tempo e recursos, esse é o
estado normal de qualquer projeto interessante (Diego Busin Poblete)

10. Dicas 6/7
❏ Garantir que o time não assuma MAIS e nem MENOS trabalho que consiga entregar conforme a
velocidade dele (isso implica que o Scrum Master deve garantir que a velocidade do time seja medido,
pois a velocidade muitas vezes não tem mas deve ter (Cihangir Deniz Ozdemir)

11. Dicas 7/7
❏ Gosto muito da relação com um time de futebol, onde o papel do Scrum Master seria a de um
técnico. Ele não entra em campo para fazer gol e defender, mas orienta, motiva, auxilia o time
para alcançar o objetivo, que no caso do futebol seria ganhar a partida e o campeonato, e no
caso do Scrum seria entregar uma Sprint e o produto (Victor Eiras)
❏ Ainda sou "beginner" em Scrum, mas acredito que o papel do Scrum Master, é semelhante ao
do maestro, orquestrando vários processos. Seu objetivo, é garantir a plena utilização das
atividades e políticas estabelecidas, buscando a percepção de valor (Luiz Antonio Gimenez)

12. P.O. Team
Scrum
Master
Fazer o
que
é
certo
Fazer certo
Fazer rápido
Foco do
Scrum Master

13. Dicas
❏ Scrum Master é o responsável pelo processo, quando ele está vendo as coisas saírem errado,
ele vai aguardar o Team tomar uma atitude e isso pode levar mais tempo que o projeto
comporta ou ele como dono do processo vai fazer a intervenção? (Abu)
❏ Como responsável pelo processo, ele DEVE zelar pelo bom andamento do todo. Se ele, ao
perceber uma possível situação que pode causar danos, é sua função procurar entender e atuar
sempre que necessário. Se ele sempre deixar o TEAM se auto-ajustar, isso pode não ocorrer e
corre-se o risco de ter que efetuar intervenções de maiores escalas, quando pequenas
atuações mais constantes nos momentos iniciais podem evitar dores de cabeça muito maiores
(Paulo Lomanto)
❏ Ainda agregando ao comentário do Paulo Lomanto aqui, acho que o momento ideal para essa
pequenas intervenções, são os dailys, visto que dia a dia temos a oportunidade de corrigir o
prumo de algo que está indo para o rumo errado, um dos melhores momentos para o coach por
que é a chance de falar a todos do time e não somente a um membro isolado (Anderson
Agustinho)

14. Dicas
❏ Fazer rápido não é trabalhar mais rápido e sim ter foco em
remover os desperdícios definidos pelo Lean (Abu)
Lean é uma metodologia ágil, mas também pode
ser encarada como uma filosofia
Desperdício é tudo que não acrescenta valor ao que está fazendo
● Aprenda a enxergar o desperdício;
● Ele aparece quando você deixa algo pela metade;
● Se faz algo que não serve pra nada;
● Se faz algo sem necessidade;
● Na atenção que perde quando se faz várias tarefas ao mesmo tempo;
● No tempo que se perde esperando algo de alguém;
● Na movimentação que pode ser evitada;
● Criando-se defeitos;
● No excesso de controle;
Estratégico
Tático
Operacional

15. Atitudes de um Scrum Master
● Disruptivo:
❏ Capaz de mudar um “status “quo” atual e ajudar a criar um
novo caminho de trabalho.
❏ Eliminar distrações.
❏ Busca da causa raiz e eliminar.
● Respeito:
❏ Pelo team, pela organização e ser íntegro.

16. Dicas
❏ Distuptivo... eu vejo a necessidade de quebrar paradigmas de como fazer as coisas. Um
exemplo: Não basta apenas pegar requisitos em formato de histórias, por que não ter um
ambiente que permita realmente contar uma historia, utilizar técnicas como "storytell"? (Abu)
❏ Distrações... como realmente tirar as distrações do Team? Não é neste momento que um
Scrum Room realmente faz sentido? (Abu)
❏ Causa raiz... Não basta apenas fazer lições aprendidas, temos que buscar a raiz do problema. 5
Why? Espinha de Peixe? Aplique essas técnicas na Retrospectiva (Abu)

17. Como garantir um ambiente de Disruptivo?
❏ Patrocínio do CEO
❏ Blindar a equipe para que ela não seja remanejada para atividades incrementais quando estão desempenhando
atividades de Ruptura
❏ Foco no “Owner”. Ter o “empowerment” de se reorganizar (reconstruir) para atender as necessidades do
cliente. Este item é muito importante inclusive para inibir interesses pessoais no modelo de trabalho ou na
solução a ser adotada.
❏ Os Teams no modelo Scrum desenvolvem processos conforme a necessidade, mas temos que fazer os
processos externos da equipe não tirar a performance de execução da equipe. Isso vai gerar uma melhor
eficiência operacional
❏ Criar pessoas que sejam a referencia da mudança que a empresa deseja ter e ser. Com isso temos que focar
nos gerentes, para que eles possam ser os professores de suas equipes. Este é o modelo Lean de trabalho,
onde o gerente é o professor
❏ Com relação aos Teams o foco continua sendo pessoas e principalmente “indivíduos e interação entre eles,
mas do que processos e ferramentas”
❏ Temos que ter o modelo de promover funcionários com habilidades de realizar vários tipos de tarefas. Quanto
menor uma equipe é relacionada a necessidades de habilidades para entregar um produto, mais a equipe se
torna multidiciplinar, a restrição de recursos leva a este modelo. Empresas grandes disponibilizam recursos
abundantes acreditando que isso vai melhorar a performance de execução das tarefas.

18. Dicas
❏ O segredo todo esta neste "disruptivo", isto é, fazer diferente. Afinal já sabemos os resultados
no nosso modelo de trabalho, para resultados diferentes temos que fazer diferente (Abu)
❏ Uma forma de promover habilidades diferentes seria criando um Tour de ocupação do
funcionário. Por exemplo 1 ano trabalhando em projetos com Java, depois 1 ano trabalhando
com projetos de mobile, depois 1 ano com projetos de Front-end. O mesmo pode ser feito nas
áreas de negócios, fazendo a pessoa desenvolver habilidades de várias áreas, construindo uma
visão mais abrangente do todo. A pessoa terá crescimento real na carreira, e a empresa irá se
beneficiar de equipes motivadas com multiplas habilidades (Thiago Torricelly)
❏ Complementando essa discussão, esse é um fator realmente complexo para muitos SMs,
equipes, empresas, projetos. É fácil encontrar diversos profissionais que preferem o caminho da
especialização ao invés da multidisciplinaridade. Raros são os casos de profissionais que
"aceitam" ou gostam de atuar em diversas especialidades (Paulo Lomanto)
❏ Ambiente. Tudo o que as pessoas veem, escutam e sentem deve ser controlado. Os Líderes
em geral influenciam e muito no ambiente, portanto, para mudar um ambiente devemos mudar
os líderes (Douglas Serra Braga)

19. ● Inspirador:
❏ Gerar entusiasmo e energia para outras pessoas.
❏ Sinergia no foco da meta da sprint.
❏ Burndown ou Up ajudar na transparência.
● Treinar:
❏ Indivíduos e teams.
❏ Fazer desenho de como grandes team trabalharam no
passado.
❏ Foco no team e não no individuo.

20. Dicas
❏ Meta... Se não for estabelecido uma meta a ser alcançada, o team não compreenderá
facilmente o valor gerado (Victor Eiras)
❏ Eu sempre gostei de comunicação visual, podemos mostrar como grandes equipes trabalharam
no passado fazendo desenhos e até mesmo processos (Abu)
❏ Alguns elementos básicos não devem ser negociados com o team. Eu entendo que cerimonias
e ferramentas do Scrum são de responsabilidade do Scrum Master. Dashboard Visual e em
papel (não eletrônico), Burndown, Calendário de Datas Importantes do projeto, Timeline para
todos terem visão do todo são alguns exemplos de ferramentas originais e complementares ao
Framework. O Scrum Master tem que entender bem o Framework e Princípios Ágeis e fazer o
que é certo para o processo. Quando ele abre mão desta responsabilidade como o team vai ter
o seu "porto seguro"? (Abu)
❏ O que o Scrum Master deve fazer quando se deparar com um team de baixa qualidade técnica,
onde a entrega fique comprometida? É responsabilidade dele? Code review; Pair programming
(Victor Eiras)

21. Dicas
❏ Ainda sobre comunicação visual X meta do time, uma coisa legal a se fazer é colocar no board
o nome da feature que o time entregará ao final da Sprint, assim fica fácil de mostrar a todos
qual o valor estaremos entregando ao final daquela iteração (Anderson Agustinho)

22. ● Desembaraçado:
❏ Remover impedimentos para aumentar a produtividade.
❏ Na retrospectiva pergunte ao team como você pode ser um
Scrum Master melhor.
❏ Grandes Scrum Masters encorajam seu team a ser adaptativo,
ter ação, divergir, ter avaliação, explorar (aprofundar), tentar,
envolver, visualizar e exibir.

23. Dicas
❏ Desenvolver uma cultura de Feedback constante, do produto, processo, team e também do
próprio Scrum Master, para que o Scrum Master possa se tornar um Scrum Master melhor
(Douglas Dornel)
❏ Complementando: o SM não deve esperar apenas as retrospectivas para alcançar esses
feedbacks. Ele deve buscar isso o tempo todo. Inclusive, são em conversas informais com
membros dos TEAMS e em particular que o SM muitas vezes obtém os melhores insights para
seu aperfeiçoamento com o TEAM (Paulo Lomanto)
❏ Complementando… Essa troca de feedbacks entre SM e team coloca todos no mesmo eixo,
melhora a sinergia e faz ambas as partes se sentirem importantes e respeitados em suas
atividades. Mas sempre tomando o cuidado de como apontar os pontos a melhorar, pois nem
sempre é aceito por todos de forma agradável, podendo gerar futuros problemas de
relacionamento à equipe (Vitor Martinez)
❏ Uma forma de aprendizado para o Scrum Master é participar, como ouvinte, de cerimônias com
outros teams para conhecer diferentes formas de processos, já que no Scrum não existe certo e
errado, mas sim uma adaptação de acordo com o contexto em questão (Victor Eiras)

24. ● Alternativa:
❏ Saber propor uma alternativa para a cultura atual.
❏ Scrum Master deve ajudar a transformar a cultura da empresa
para que o team scrum possa prosperar. Exemplos: ted.com e
“the marsh mallow challenge” or “the penny game”.
❏ Usar a técnica de t-shaped people para equipes
multidiciplinares (responsabilidade compartilhada).
❏ O team deve entender sua definição de “done”.

25. O Scrum Master deve promover debates ao término de cada
sprint:
❏ Novas prioridades.
❏ Nova release.
❏ Novo requisito.
❏ Novo processo.
❏ Novo design.
❏ Novo plano.
❏ Novas estimativas.
❏ Nova velocidade.
O Scrum Master deve evitar mini-waterfalls.

26. Dicas
❏ Novos Processos: Introduzir mudanças de forma fragmentada a cada nova sprint, pode ser uma
forma sábia de entender o que faz aumentar a velocidade do time. Ao invés de ter muitas
mudanças ao mesmo tempo, e não ter como acompanhar quais realmente influenciaram na
melhoria dos resultados. É uma prática de Kaizen, fazer melhorias no processo passo-a-passo
como numa escada, obtendo aceleração a cada nova sprint (Thiago Torricelly)
❏ Perfect! Só adicionaria um item nesse pensamento: mudanças, mesmo que pequenas,
precisam ser mensuradas (antes X depois) e precisam de um tempo de maturação. Não
podemos correr o risco de efetuar uma pequena mudança, e no final de apenas 1 sprint, tomar
conclusões definitivas. Toda mudança, ao meu ver, precisa de acompanhamento, ajustes e
observação ao longo do tempo para medir a sua efetividade (Paulo Lomanto)

27. ● Tato
❏ Sabe lidar com cada individuo do time.
● Capacitar
❏ Ajudar outras pessoas a serem mais efetivas.
❏ O Scrum Master deve treinar o team para que o team não
necessite dele.
❏ O Scrum Master deve buscar grandes fustrações da equipe e
removê-las (retrospectiva).
❏ Ter um mapa funcional da empresa ajuda a melhorar o
relacionamento e abrangência de influência.

28. Dicas
❏ Sobre "Tato", costumo brincar com algumas pessoas dizendo sempre que o SM é, além de
tudo, um psicólogo (além de engenheiro, médico, advogado, etc), pois ele tem que se envolver
com cada indivíduo, entender como está a sua vida, a sua rotina, entender o que o motiva ou
não, saber se está com algum problema que afete o seu dia-a-dia. Enfim, um bom SM cria uma
conexão empática com os membros dos times (Paulo Lomanto)

29. Não ter proxies entre o P.O. e o team
Métricas:
❏ Iterations.
❏ Testing.
❏ Users Stories.
❏ Product Owner.
❏ Product Backlog.
❏ Estimates.
❏ Burndown.
❏ Team Disruption.
❏ Team Ownership.
Trabalhar com nível de maturidade do teams aos princípios ágeis.
Observação: Anexo 2

30. Dicas
❏ Uma metrica super interessante eh o custo de ter um proxy entre o PO o Team, por exemplo o
PO fica 2 dias sem responder definiçoes de negocio para o time, isso gerou uma dificuldade
para o time progredir nas atividades, entao eh realizado um calculo das horas improdutivas do
time (em R$) aguardando resposta do PO (Douglas Dornel)
❏ Sim podemos ter métricas… (Abu)

31. ● Empatia:
❏ Sensível aos que o rodeiam.
❏ Aprender a escutar as pessoas (vale para Scrum Master e
Team).

32. Cerimônias
Executar:
❏ Sprint Planning.
❏ Sprint Review.
❏ Sprint Retrospectiva.
❏ Daily.
❏ Grooming.
Observação: Anexo 1

33. Dicas
❏ O maior ganho na realização de retrospectivas, reviews, daily, debates e outras dinâmicas ágeis
é nos aproximar uns dos outros, deixando de ser apenas mais uma pessoa da equipe.
Devemos fomentar a sinergia, amizade a ajuda entre os membros da equipe, deixando claro
para a equipe como está a situação de trabalho e o rendimento de cada envolvido (Douglas
Chaves)
❏ No Scrum cerimonias não tem negociação e é responsabilidade do Scrum Master executa-las
(Abu)

34. Ferramentas
Executar:
❏ Release Burndown.
❏ Sprint Burndown.
❏ Software (se necessário).
❏ Dashboard.

35. Dicas
❏ A beleza destas ferramentas é que mostram o progresso do time e o quanto resta de trabalho
em direção ao Objetivo da Sprint/Release. Se a linha do burndown está muito abaixo, o time
precisa rapidamente implementar um padrão com um procedimento de emergência. O Scrum
Master precisa ajudar o time agir antecipadamente, antes de derrapar com a falha da sprint. Ser
Ágil é responder rápido a mudanças (Thiago Torricelly)
❏ Temos que usar as ferramentas para promover uma comunicação mais efetiva, de novo,
ferramentas do Scrum, não tem negociação, é de responsabilidade do Scrum Master utilizar
(Abu)

36. Processos
A empresa define processos necessários e o Scrum Master
deve trabalhar respeitando esses processos.
Exemplo:
❏ Itil.
❏ Cobit.
❏ Segurança.
❏ Compras (Aquisição).
❏ PMO
❏ etc.

37. Dicas
❏ Por mais que alguns dos processos pareçam implicar em "não agilidade" (ex.: ITIL) ela deve ser
incorporada às equipes ágeis. Se pensarmos em todos os processos nesse slide, eles podem
co-existir sem problemas nos princípios ágeis, com as suas devidas adaptações (Paulo
Lomanto)
❏ Concordo Plenamente. O grande ponto é que "Não existe equipe Ágil" se não existir
"Organização Ágil". Definir o Valor, Eliminar os desperdícios utilizando o VSM (Value Stream
Mapping), Garantir a Fluidez nos Processos, Fazer com que a Demanda seja Puxada mais a
Busca pela Perfeição … Processos ITIL ou de PMO mal implementados, irão gerar gargalos e a
"Equipe Ágil" irá sofrer as consequências (Douglas Serra Braga)

39. Dicas
❏ Um exemplo de processo end-to-end. Eu não gosto do scrum master apenas dentro do Team,
eu entendo que ele deve olhar o processo de ponta a ponta e desempenhar suas funções nesta
abrangência (Abu)

40. Anexo 1
Serie: “Como Fazer”

41. Como Fazer Daily Meeting

42. O que é?
● Reunião de 15 minutos realizada pela equipe para o alinhamento e sincronismo, das atividades
que estão sendo realizadas, vão ser realizadas, já terminadas e problemas que estão
impossibilitando a conclusão dos trabalhos.
O que não é?
● Reunião de debates técnicos de como vamos fazer nossas atividades. Também não é uma
reunião de atribuição de trabalho as pessoas, em Scrum a equipe deve se auto- organizar com
as atividades que devem ser realizadas.
● Daily também não serve para passar o status da tarefa para o superior
Organização
● Ser realizado em frente ao Dashboard ou monitor com a ferramenta de gestão utilizada(Trello,
Kanbanize, Jira,..).

43. Execução
● Todos da equipe falam o que estão fazendo, vão fazer, já terminaram de fazer e se possuem
impedimentos;
● Product Owner também fala o que está preparando para a próxima Sprint;
● Scrum Master fala os impedimentos que já resolveu e os que pretende resolver;
● Responsáveis pela execução do plano de ação da retrospectiva anterior lembrar do plano ao
término da Daily Meeting;
● Scrum Master atualiza o Sprint Burndown;

44. Saída do Processo
● Dashboard ou ferramenta de gestão com tarefas atualizadas;
● Sprint Burndown atualizado;
Boas Práticas
● Uso de ”Token” para sinalizar quem fala;
● Todos sempre estarem na frente do quadro de post-its ou monitor segurando / mostrando o
post-it que refere-se ao que está sendo falado;
● Muta para quem chegar atrasado, faltar ou não lembrar o que fez no dia anterior;
● Painel de retrospectiva ao término da Daily Meeting com a informação se a equipe gostou ou
não da reunião;

45. Exemplo
● Team Scrum na frente do quadro (Product Owners, Scrum Masters e Equipe).
● Todos falam: o que fiz, o que pretendo fazer e quais os impedimentos que possuo.

46. Token
● Qualquer item pode ser um Token, caneta, lápis, relógio, um bloco de post-its, brinquedos, etc;

47. Quadro de Feedback do Daily
● Pegar ao término da Daily Meeting a opinião de todos e já identificar o que podemos melhorar.

48. Caixa de Multa por Falhas no Daily Meeting
● MULTA para quem: Chegar atrasado, não lembrar o que foi feito, não saber o que vai fazer, etc

49. Como Fazer Sprint Planning

50. O que é?
● Reunião em que o Team Scrum faz o entendimento do Sprint Backlog;
● Reunião em que o Team Scrum define a estratégia de solução e testes do Sprint Backlog;
● Reunião em que o Team Scrum determina as tarefas necessárias para a entrega do Sprint
Backlog;
Organização
● Convidar todos os interessados com antecedência;
● Reservar sala;
● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;
Documentos de Entrada do Processo
● Histórias aderentes ao conceito de Ready;
● Calendário da Sprint;

51. Execução
● Product Owner apresenta a meta da Sprint;
● Product Owner apresenta todas as histórias da Sprint para a equipe;
● Equipe revisa se as histórias apresentadas atendem a meta da Sprint;
● Equipe faz a estimativa de cada história utilizando Planning Poker;
● Equipe se compromete com a quantidade de histórias que ela consegue fazer na Sprint, de
acordo com sua velocidade;
● Equipe pega cada história e quebra em tarefas;
● Equipe faz a estimativa de horas de cada tarefa utilizando Planning Poker;
● Scrum Master atualiza a velocidade da equipe;
● Product Owner fica disponível durante toda a cerimônia de planejamento de Sprint;
Saída do Processo
● Sprint Backlog;
● Dashboard ou Jira com tarefas estimadas em horas;
● Sprint Burndown;

52. Como Fazer Sprint Review

53. O que é?
● Reunião de oficialização das histórias aceitas e rejeitadas pelo Product Owner.
O que não é?
● Reunião de apresentação do produto para o Product Owner.
Observação
● As histórias devem ser entregues ao Product Owner durante a execução da Sprint e não
apenas na Sprint Review;
● Isso permite fazer os pequenos acertos necessários durante a execução da Sprint para que o
Product Owner possa dar o aceite na história;
● Este modelo de trabalho evita deixar para as próximas Spritns os pequenos acertos que
poderiam ser resolvidos no momento de apresentação ao Product Owner;

54. Organização
● Convidar todos os interessados com antecedência;
● Reservar sala;
● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;
Documentos de Entrada do Processo
● Sprint Backlog;
● Calendário da Sprint;
● Conceito de Done;
● Sprint Burndown;

55. Execução
● Equipe apresenta as histórias em conformidade com o conceito de Done ao Product Ower;
● Product Owner da o aceite integral, parcial ou recusa a história;
● Scrum Master atualiza o documento de Sprint Review;
Saída do Processo
● Documento de Sprint Review.

56. Como Fazer Retrospectiva

57. O que é?
● Reunião de melhoria do processo para reduzir desperdícios;
● Reunião de foco a busca da causa raiz que levou a não entrega de um item de backlog;
Organização
● Convidar todos os interessados com antecedência;
● Reservar sala;
● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;
● Ter na reunião as informações do Sprint Planning e Sprint Review;
● Ter na reunião as informações da retrospectiva anterior;
Documentos de Entrada do Processo
● Sprint Planning;
● Sprint Review;
● Plano de Ação da Sprint Anterior;

58. Execução
● Scrum Master apresenta as informações do plano de ação da retrospectiva anterior,
identificando o que foi solucionado e não solucionado;
● Todos escrevem os pontos positivos da Sprint sem diálogo entre os participantes;
● Todos escrevem os pontos negativos da Sprint sem diálogo entre os participantes;
● Scrum Master lê todos os post-its deixando aberto o diálogo para entendimento de todos;
● Scrum Master promove a priorização dos pontos negativos utilizando a técnica de Dot Poitns;
● Scrum Master junto com todos elaboram o plano de ação;
● Scrum Master deixa o plano de ação visível a todos no local que é realizado o Daily Meeting;
Saída do Processo
● Plano de Ação da Retrospectiva;

59. Quadro de Retrospectiva - Continuar, Melhorar e Parar

60. Quadro de Retrospectiva - Positivo e Negativo

61. Como Fazer Grooming

62. O que é?
● O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog;
● O Grooming (preparação) do Product Backlog é o ato de adicionar detalhes, estimativas e
ordem aos itens no Product Backlog.
● É um processo contínuo em que o PO e o time colaboram com os detalhes dos itens do Product
Backlog.
● Durante o Grooming os itens são analisados e revistos, no entanto, eles podem ser atualizados
a qualquer momento.
Organizar o backlog é um processo contínuo que
envolve:
● A descoberta de novos itens, assim como alteração e remoção de itens antigos;
● Quebrar histórias muito grandes;
● A priorização dos itens do backlog (trazendo os mais importantes para o topo);
● Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;
● Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);
● Incluir critérios de aceitação;

63. Como Fazer Dashboard

64. O que é? Para que Serve?
● Quadro com as atividades que a equipe esta executando
● Permite a gestão compartilhada das atividades pela equipe
● Permite gestão “radiano” onde todos conseguem ter a percepção que algo foi mudado
● Mostra a visão do “todo”
Documentos de Entrada do Processo
● Sprint Backlog
● Tarefas de cada item do Sprint Backlog

65. Execução
● Desenhar o quadro em local que todos da equipe possam visualizar
● Ter a informação da equipe, pode ser “avatar”
● Pode ser processual, quadro para técnica de Kanban onde o processo fica visível ou
pode ser de Scrum onde o processo é apenas “A fazer”, “Fazendo”, “Impedimento” e
“Feito”
● Deixar claro o que cada pessoal esta fazendo
● Deixar claro o que já esta pronto
● Deixar claro o que esta com impedimento
● Deixar claro o serviço que não foi previsto
● Deixar claro os indicadores de entregas durante a Sprint
Saída do Processo
● Dashboard montado

66. Quadro de Dashboard

67. Indicadores da Sprint
Avatar

68. Quadros Modernos

69. Quadro Sofisticado

70. Quadro de Bugs (Vivo com, Crítico, Fazer

71. Como Fazer Agenda da Sprint

72. Organização
● Não se aplica
Documentos de Entrada do Processo
● Não se aplica
Execução
● Scrum Master deve montar um calendário visual com as datas importantes da Sprint,
como planning, retrospectiva, review, daily meeting, grooming
● Scrum Master deve colocar no calendário eventos já definidos e conhecidos como
reuniões, treinamentos ou feriados
● Scrum Master deve deixar em observação a ausência já conhecida de profissionais da
equipe, seja por motivos de ferias, medico, etc
● Scrum Master com esses dados deve calcular a capacidade da equipe, sempre
lembrando de subtrair 15% para cerimonias do Scrum e 10% para grooming
Saída do Processo
● Calendário da Sprint

73. Como Fazer Ready e Done

74. Organização
● Convidar todos os interessados com antecedencia
● Reservar sala
● Disponibilizar na sala post-its, canetas, projetos, notebook, acesso a internet
Documentos de Entrada do Processo
● Não se aplica
Execução
● Todos devem definir em conjunto o conceito de Preparado e Pronto por Bloco
Saída do Processo
● Documento de Ready and Done da Sprint
● Documento de Ready and Done da Regressão
● Documento de Ready and Done da Transição
● Documento de Ready and Done da Operação

75. Como Fazer Estimativas

76. O que é? Para que Serve?
● Técnica de medir esforço de todos os itens do Product Backlog, Release Backlog, Sprint
Backlog, Grooming, etc
● Importante: do esforço buscamos o tempo e nunca a busca do tempo em primeiro lugar
● A estimativa vai garantir com que a equipe esteja entendendo a demanda, seguindo o
principio que conseguimos apenas estimar o que entendemos
● Ao termino da estimativa a equipe sabe o que fazer para planejar como fazer e a
empresa tem a visão do tempo necessário para fazer as demandas
Organização
● Convidar todos os interessados com antecedencia
● Reservar sala
● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet

77. Documentos de Entrada do Processo
● Documento de Ready e Done
● Calendário da Sprint
● Product Backlog
Execução
● Product Owner apresenta todas as histórias do product backlog para a equipe
● Equipe identifica uma história para ser utilizada como ancora de referencia na
estimativa de todas as outras histórias
● Equipe faz estimativa de pontos de esforço utilizando planning poker para cada história
● Scrum Master monta em uma parede colunas com os números da régua de fibonacci
● Equipe vai colocando na parede e na coluna adequada a história com o esforço
estimado
● Equipe sempre vai validando todas as histórias de uma determinada coluna, garantindo
com isso coerência entre as histórias que estão nessa coluna
● Equipe define a sua velocidade com as informações obtidas pela estimativa e tamanho
da Sprint

78. Saída do Processo
● Product Backlog estimado
Exemplo
Quadro de Estimativas
● Monte os números de fibonacci em colunas. Para cada coluna coloque um desenho que
representa o número, pode ser cachorros, dinossauros, copos de bebidas, etc
● Pegue um item de backlog para ser referencia de medição dos demais itens de backlog,
chamamos de ancora de referencia
● A ancora de referencia é uma boa pratica receber valor igual a 2 (dois)
● Estime todos os itens de backlog necessários utilizando o conceito de Planning Poker
● Coloque cada item de backlog estimado na coluna correspondente
● Valide sempre se todos os itens de backlog de uma coluna são de mesma grandeza de
esforço.

80. Planning Poker Sem Baralho e Com Baralho
● Os valores devem ser mostrados ao mesmo tempo, para que nenhuma pessoa possa
ser influenciada por outro colega do Team
● Esta técnica permite termos respeito a opinião de todos
● Quando não existe consenso na estimativa mas os valores são vizinhos na régua de
fibonacci podemos deixar o pior caso
● Quando não existe consenso na estimativa e os valores não são vizinhos na régua
de fibonacci devemos pedir para as pessoas justificarem sua estimativa e jogamos o
Planning Poker de novo
● Quando os valores estimados são muito grandes, devemos quebra o item de backlog
em pedaços menores e estimar carda pedaço
● Depois de três jogadas de Planning Poker para um item de backlog e este item de
backlog não ter um consenso, colocamos ele como “?” e aguardamos a remoção de
algumas incertezas pelo Product Owner até o item de backlog ser possível de ser
estimado

81. Exemplo de Planning Poker

82. Como Fazer a Inception

83. O que é?
● Reunião de transformação de um plano de negócio em um produto, seu Roadmap e
priorização do que vai fazer parte do MVP (minimum viable product)
Organização
● Convidar todos os interessados com antecedencia
● Reservar sala
● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet
Documentos de Entrada do Processo
● Canvas de Negocio

84. Execução
● Product Owner apresenta o Canvas de Negócio a todos
● Equipe junto com o Product Owner desenvolvem as histórias
● Equipe monta arquitetura inicial do produto
● Equipe monta mapa de navegação de interfaces
● Equipe monta modelo de domínio do produto
● Usar paredes para arquitetura inicial, modelo de domínio, mapa de navegação, histórias
etc
Saída do Processo
● Product Backlog
● Roadmap
● Visão do Produto
● Arquitetura Inicial do Produtp

85. Exemplo
Nome do Produto, Roadmap, etc

86. Mapa de Navegação, Histórias, etc

87. Story Boards

88. Canvas de Negócio

89. Product Box

90. Anexo 2
Exemplo de Indicadores

91. Backlog
❏ Projeto possui backlog
❏ Projeto possui backlog estimado
❏ Projeto possui backlog priorizado
❏ Projeto possui tamanha das sprints definidos (1, 2, 3, ou 4 semanas)
❏ Projeto possui Scrum Master
❏ Projeto possui Product Owner
❏ Projeto possui cronograma (backlog distribuído por sprint's)
❏ Projeto possui centro de custo para contabilização de custos
❏ Projeto possui repositório de versionamento de código
❏ Projeto possui custo médio da equipe para calculo de custo por sprint
❏ Riscos identificados do projeto (backlog)

92. Sprints
❏ Pontos planejados por sprint
❏ Pontos entregues e aceitos por sprint
❏ Pontos entregues e não aceitos por sprint
❏ Pontos entregues e aceitos parcialmente por sprint
❏ Pontos não executados por sprint
❏ Capacidade em horas de trabalho da equipe na sprint
❏ Total de todas as tarefas estimadas em horas por
sprint
❏ Total de horas da equipe utilizada para Scrum (gasto
no framework)
❏ Diferença entre total de horas de trabalho da equipe e
total de horas das tarefas executadas pela equipe
(identificar a perda real da equipe, exemplo 8:48
contrato de trabalho mas de produção 7:00)
❏ Quantidade de histórias não previstas adicionadas na
sprint
❏ Total de pontos não previstos das histórias adicionadas
na sprint
❏ Quantidade de histórias da sprint
❏ Quantidade de histórias prontas para desenvolvimento
da sprint (Ready) colocadas no planning
❏ Quantidade de histórias realmente prontas para
desenvolvimento identificadas pela TIME na review
❏ Data e hora de abertura de um impedimento
❏ Data e hora de fechamento de um impedimento
❏ Percentual de cobertura de TDD dos algoritmos da
sprint
❏ Riscos identificados na sprint
❏ Categorização de impedimentos (infra, qualidade, regra
de negocio, api de terceiros, etc)
❏ Total de bugs gerados na sprint
❏ Possui a meta da sprint definida
❏ Quantidade de pontos da meta da sprint

93. Histórias
❏ Possui pontos
❏ Possui priorização
❏ Possui critério de aceite
❏ Possui tarefas

94. Tarefas
❏ Possui estimativa em horas, com intervalo de 1 a 8 hrs

95. Outros
❏ Total de tarefas novas por dia
❏ Total de impedimentos por dia
❏ work real de cada história
❏ wait real de cada história
❏ Banco de horas por pessoal da equipe ao termino de cada sprint
❏ Incidentes em produção
❏ % turnover do projeto
❏ Produto possui roadmap
❏ Happiness Index das pessoas envolvidas

96. Agenda de Trabalho
❏ Possui agendado as reuniões de planejamento da sprint
❏ Possui agendado as reuniões de retrospectiva
❏ Possui agendado as reuniões de review
❏ Possui agendado as reuniões de daily

97. Evidencias de Execução
❏ Planejamento de Sprint
❏ Retrospectiva
❏ Review
❏ Daily

98. Review – Satisfação de Produto
❏ Possui a informação das histórias aceitas pelo PO
❏ Possui a informação das histórias não aceitas pelo PO
❏ Possui a informação das histórias aceitas parcialmente pelo PO

99. Qualidade
❏ Quantidade de Bugs
❏ Quantidade de Necessidades de Refactory
❏ Quantidade de Incidentes
❏ Quantidade de Problemas
❏ Cobertura de testes automatizados
❏ Testes de regressão do produto não automatizados

100. Tempo e Custo

101. Portfólio
❏ SPI consolidado do portfólio
❏ CPI consolidado do portfólio
❏ Índice de pontualidade do portfólio: percentual de projetos que estão com o cronograma
em dia.
❏ Índice de projetos dentro do orçamento: percentual de projetos que estão com o
cronograma em dia.
❏ Índice de pontualidade financeira do portfólio: pode ser calculado pela seguinte fórmula
= orçamento_total_disponível_para_o_portfólio_até_hoje_em_R$ -
total_gasto_no_portfólio_até_hoje_em_R$
❏ ROI (Retorno do Investimento) do portfólio: pode ser calculado pela seguinte fórmula =
(lucratividade_dos_projetos_em_R$ - custo_total_dos_projetos_em_R$) /
custo_total_dos_projetos_em_R$
❏ Índice de clima organizacional da equipe: a partir de pesquisa de clima organizacional
❏ Índice de satisfação dos clientes internos e externos: a partir de pesquisa junto a clientes
internos e externos

102. Anexo 3
Scrum Room

103. Scrum Room
❏ Sala do time aberta, estimulando comunicação face a face e interações regularmente
❏ Espaço na parede para Kanbans com post-its, Backlog do Produto e da Sprint, Dashboards de
acompanhamento do projeto, diagramas de arquitetura, e outros artefatos que desejar colocar
na parede.
❏ Eliminar fios onde puder (laptops na rede wireless, mouses sem fio, etc) para boa mobilidade da
equipe
❏ Quadro branco - Indispensável (móvel se possivel)
❏ Espaço para a Daily standup meetings
❏ Televisão para Demo meetings e outras reuniões
❏ Webcam da sala para comunicação com times externos
❏ Mesa extra para reuniões ou desenhos de cartões
❏ Mobilia móvel para reconfigurar o espaço
❏ Mesas sem divisórias
❏ Ergonomia: cadeiras de qualidade para boa produtividade
❏ Algum espaço privado para utilizar quando necessário
❏ Conveniências: Café, Impressora, Armários, Frigobar

104. Dicas
❏ Gostei da Idéia do Scrum Room. Funciona como as Salas onde se reúnem as equipes Kaizen.
Naturalmente, as pessoas reagem ao ambiente a qual estão inseridas e criar um ambiente onde
as pessoas possam VIVER o Projeto certamente traz muito resultado. É o funcionamento
natural do Cérebro e não tem como fugir (Douglas Serra Braga)

105. Anexo 4
Ferramentas

106. Skill / Team

107. Canvas de
Risco

108. Aderência ao Processo / Métricas

109. Canvas de Entregas

110. Canvas de Treinamento

111. Mapeamento de Processos

112. Canvas de Negocio

113. Big Picture

114. Anexo 5
Dinâmicas para Ajudar na Mudança de
Cultura

115. Exercício – 1
Aumentando Produtividade pela Redução de
Estoques

118. Exercício – 2
Aumentando a Produtividade por Executar uma
Tarefa por Vez

123. Exercício – 3
Aumentando a Produtividade por Executar uma
Tarefa por Vez

128. Exercício – 4
Scrum na Pratica

129. ✓
✓
✓
☑
☑
✓
✓
✓
✓
✓
✓
59

130. Exercício – 5
Boneco de Papel

132. Exercício – 6
Eficiência Operacional

134. Anexo 6
Glossário

135. Behavior Driven Development - BDD
O que é?
● Técnica de desenvolvimento Ágil que encoraja a colaboração entre desenvolvedores, setores
de qualidade e pessoas não-técnicas ou de negócios num projeto de software.
Benefícios
● Melhora a comunicação;
● Documentação dinâmica;
● Visão do todo;
Práticas de BDD
● Envolver as partes interessadas no processo através de Outside-in Development
(Desenvolvimento de Fora para Dentro);
● Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código;
● Automatizar os exemplos para prover um feedback rápido e testes de regressão;

136. Palavras Chave
● Dado que
● Quando
● Então
Exemplo
Cenário 1:
Estoque disponível
DADO QUE o estoque da coca-cola é de 50 unidades
QUANDO informo uma venda de 40 unidades
ENTÃO a venda é registada
E o estoque passa a ser de 10 unidades

137. Cenário 2:
estoque
indisponível
DADO QUE o estoque da coca-cola é de 50 unidades
QUANDO informo uma venda de 60 unidades
ENTÃO a venda não é registada
E é exibida na tela a mensagem "estoque insuficiente!"

138. Cartão de Histórias
O que é?
● Técnica de captura de requisitos;
● Pode ser desenvolvido na reunião de Grooming ou na cerimônia de Sprint Planning;
● Deve ser escrito a partir de uma perspectiva do usuário, logo, não deve possuir jargões
técnicos;
Ele tem o objetivo de capturarmos:
● Conversa de cada história;
● Conversa de cada critério de aceite;
● Capturar cada comportamento esperado pelo Product Owner;
● Conversa de como vamos testar a história, seus critérios de aceite e comportamentos;

140. Dashboard
O que é? Para que serve?
● Quadro com as atividades que a equipe está executando;
● Permite a gestão compartilhada das atividades pela equipe;
● Permite gestão “radiano” onde todos conseguem ter a percepção que algo foi mudado;
● Mostra a visão do “todo”;
Documentos de Entrada do Processo
● Sprint Backlog;
● Tarefas de cada item do Sprint Backlog;

141. Execução
● Desenhar o quadro em local que todos da equipe possam visualizar;
● Ter a informação da equipe, pode ser “avatar”;
● Pode ser processual, quadro para técnica de Kanban onde o processo fica visível ou pode ser
de Scrum onde o processo é apenas “A fazer”, “Fazendo”, “Impedimento” e “Feito”;
● Deixar claro o que cada pessoa está fazendo;
● Deixar claro o que já está pronto;
● Deixar claro o que está com impedimento;
● Deixar claro o serviço que não foi previsto;
● Deixar claro os indicadores de entregas durante a Sprint;
Saída do Processo
● Dashboard montado;

142. Quadro de Dashboard
Indicadores da Sprint

143. Gestão Visual
Utilizar Gestão Visual para Entendimento de
Todos
● Utilizar as paredes para colocar o Sprint
Backlog;
● Utilizar as paredes para colocar desenhos
de arquitetura;
● Utilizar as paredes para colocar os
Cartões de Histórias;
● Fazer com que o trabalho manual seja
realizado por todos;
● Fazer a equipe desenhar o negócio com
DDD (Domain Driven Design) para
garantir que estão entendendo o Sprint
Backlog;

144. Grooming
O que é?
● O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog;
● O Grooming (preparação) do Product Backlog é o ato de adicionar detalhes, estimativas e
ordem aos itens no Product Backlog.
● É um processo contínuo em que o PO e o time colaboram com os detalhes dos itens do Product
Backlog.
● Durante o Grooming os itens são analisados e revistos, no entanto, eles podem ser atualizados
a qualquer momento.
Organizar o backlog é um processo contínuo que envolve:
● A descoberta de novos itens, assim como alteração e remoção de itens antigos;
● Quebrar histórias muito grandes;
● A priorização dos itens do backlog (trazendo os mais importantes para o topo);
● Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;
● Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);
● Incluir critérios de aceitação;

145. MoSCoW
O que é? Para que serve?
● Técnica de priorização;
● Vai permitir uma busca de
funcionalidades obrigatórias do
projeto, na visão do Product
Owner.
Técnica
● MUST – Tem que ter;
● SHOULD – Deveria ter;
● COULD – Poderia ter;
● WANT – Interessante ter;

146. Pair Programming
O que é?
“Boa prática” da metodologia Extreme Programming – XP;
Execução
Programação feita em par;
Revezar, periodicamente, as duplas;
Benefícios
Entendimento da regra de negócio;
Nivelação do conhecimento técnico;
Minimização de erros;

147. Planning Poker
O que é?
● Técnica de medir esforço de todos os itens do Product Backlog, Realease Backlog, Sprint Backlog,
Grooming, etc.
Planning Poker Sem Baralho e Com Baralho
● Os valores devem ser mostrados ao mesmo tempo, para que nenhuma pessoa possa ser
influenciada por outro colega do Team;
● Esta técnica permite termos respeito a opinião de todos;
● Quando não existe consenso na estimativa mas os valores são vizinhos na régua de fibonacci
podemos deixar o pior caso;
● Quando não existe consenso na estimativa e os valores não são vizinhos na régua de fibonacci
devemos pedir para as pessoas justificarem sua estimativa e jogamos o Planning Poker de novo;
● Quando os valores estimados são muito grandes, devemos quebra o item de backlog em pedaços
menores e estimar carda pedaço;
● Depois de três jogadas de Planning Poker para um item de backlog e este item de backlog não ter
um consenso, colocamos ele como “?” e aguardamos a remoção de algumas incertezas pelo
Product Owner até o item de backlog ser possível de ser estimado;

148. Product Backlog
O que é?
● Lista de requisitos do produto;
● Geralmente é feito em um arquivo excel e compartilhado entre o Team Scrum;
Tema Item Importância Estimativa Como demonstrar Notas Status
Paciente
Sendo um paciente
posso fazer meu
cadastro para
agendar uma
consulta.
100 8
Entrar no site, ir para
página de cadastro
de paciente, fazer o
cadastro, ir para
página de login e
logar-se.
Criptografar
senha do
paciente. Concluído
Login
Sendo um usuário
posso logar no
sistema.
30 5
Entrar no site, ir para
página de login e
logar-se.
Pendente

149. Definition of Ready
Definition of Ready
● É uma história que já pode ser estimada pela equipe, porque
ela atende a todos os quesitos necessários para seu
desenvolvimento, ou seja, é uma história clara e entendida
por todos.
● A definição de Ready é elaborada em comum acordo entre o
time e o PO, podendo variar de equipe para equipe, e
também entre projetos.
● O acordo entre equipe e PO é necessário para que exista a
preocupação de preparar a história antes do planejamento da
Sprint.

150. Definition of Done
● É uma história que teve seu desenvolvimento terminado, e já
pode ser avaliada na reunião de revisão pelo PO.
● A definição de Done é elaborada em comum acordo entre o
time e o PO.
● Esse acordo é necessário para que o time saiba quais são
todos os artefatos que devem ser gerados durante o
desenvolvimento de uma história.
● Essa definição deve conter uma lista simples de atividades
que agregam valor ao produto.

151. Roadmap
O que é?
● “Mapa” que visa organizar as metas de desenvolvimento de um software.

152. O que é?
● Gráfico utilizado para representar, diariamente, o progresso do trabalho em desenvolvimento,
fazendo um comparativo entre o planejado e o realizado;
● Eixo X : Dias da Sprint;
● Eixo Y : Total de pontos por história;

153. Story Point
O que é?
● Um Story Point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma
feature, a complexidade desse desenvolvimento, o risco contido nele, e por aí vai.” [Mike Cohn,
Agile Estimation and Planning];
● Importante: do esforço buscamos o tempo e nunca a busca do tempo em primeiro lugar;

154. Test Driven Development - TDD
O que é?
● Desenvolvimento orientado a testes;
● Técnica de desenvolvimento de software que baseia em um ciclo curto de repetições;
● Não é um método para testar software, mas para construir software;
● Vem do conceito de “test-first programming” do XP (Extreme Programming);
Objetivo
● “Clean Code That Works”;
● Código limpo que funciona;

155. Benefícios
● Maior produtividade;
● Qualidade do código;
● Compreensão do negócio;
Passos: Vermelho-verde-refatora
● Codifique o teste;
● Faça ele compilar e executar (não deve passar – vermelho);
● Implemente o requisito e faça o teste passar (verde);
● Refatore o código;

156. User Story
O que é?
● Forma de especificação de requisito;
Perguntas à serem respondidas
● Quem? Para quem estamos desenvolvendo a funcionalidade.
● O que? Uma descrição resumida da funcionalidade em si.
● Por que? O motivo pelo qual o cliente precisa desta funcionalidade. Se possível citando o valor de
negócio obtido.
Técnica para responder
SENDO
POSSO
PARA QUE

157. Visão do Produto
O que é?
● Breve descrição, em auto nível, do produto a ser desenvolvido.
● Não tem o objetivo de ser uma apresentação detalhada dos requisitos;
● Pode ser melhorada ao longo do projeto, não sendo uma regra a sua apresentação apenas no início do
projeto;
Técnica: Declaração do Elevador (Elevator Statement)
PARA [cliente-alvo]
QUE [indique a necessidade ou oportunidade]
O [Nome do projeto]
É UM(A) [categoria do produto]
QUE [indique o principal benefício; ou seja, a razão convincente que motiva a compra]
DIFERENTE [principal alternativa da concorrência]
NOSSO PRODUTO [indique a principal diferença]

158. PARA empresas médias de marketing e departamento de vendas
QUE necessitam de um sistema de CRM
O EeaseCRM
É UM software baseado na web, intuitivo e fácil de usar
QUE fornece a possibilidade de fazer a rastreabilidade de vendas, geração de
leads e possibilita o estreitamento do relacionamento com o cliente.
DIFERENTE De outros serviços ou produtos,
NOSSO PRODUTO Oferece a melhor relação custo benefício.

159. Product Vision Box
Product Vision Box
● O Product Vision Box é uma técnica que ajuda no entendimento da Visão do Produto, pois
quando fazemos uma representação visual do produto (embalagem, por exemplo) isto auxilia na
redução do nível de abstração.
Informações Sobre o Produto
● Nome do produto;
● Logotipo ou desenho que represente o produto;
● Principais benefícios que ajuda a “vender” o produto;
● Principais características e/ou funcionalidades do produto;
● Principais requisitos técnicos;

160. Feito por… (1/3)
Nome Email
Nelson Abu Samra Rahal Junior abu@abuzitos.com.br
Thiago Torricelly torricelly@hotmail.com
Victor Eiras da Silva victor.eiras@gmail.com
Douglas Chaves douglas@abuzitos.com.br
Carlos Freitas carlos@quantic.com.br
Douglas Dornel douglas.dornel@gmail.com
Paulo Lomanto paulo.lomanto@gmail.com

161. Feito por… (2/3)
Nome Email
Douglas Braga douglas_sb@hotmail.com
Vitor Martinez vtrmartinez@gmail.com
Anderson Agustinho ander.agustinho@gmail.com
Diego Poblete dipoblete@gmail.com
Rafael Capra eltiburon.bajista@gmail.com
Robertt Carvalho robervalho@gmail.com
Cihangir Deniz Ozdemir ozco.ltda@gmail.com

162. Feito por… (3/3)
Nome Email
Rodolfo Perenha rperenha@bionexo.com
Luiz Antonio Gimenez lagimenez40@gmail.com
Silvio Neto silvioneto.ti@gmail.com
Fabio Sanches fabiollsanches@gmail.com

163. Referencia Bibliografica
www.livroleanit.com