Manual Do Scrum Master

Centers Studio Agile Brasil
Manual do Scrum Master

Sumário
1. O que é agilidade ___________________________________________ 4

2. O que é o Scrum ___________________________________________ 5
3. Papéis e responsabilidades __________________________________ 7
3.1. Product Owner ______________________________________________________ 7
3.2. Scrum Master _______________________________________________________ 9
3.3. Dev Team __________________________________________________________ 10
3.4. Stakeholder ________________________________________________________ 11
4. Os artefatos ______________________________________________ 12
4.1. Objetivo do produto _________________________________________________ 12
4.2. Criação de backlog do produto _______________________________________ 13
4.2.1. PBB (Product Backlog Building) ____________________________________ 14
4.2.2. Hierarquia de construção __________________________________________ 16
4.3. Objetivo da Sprint___________________________________________________ 17
4.4. Definition of Ready (DoR) ____________________________________________ 18
4.5. Critérios de aceite __________________________________________________ 19
4.6. Definition of Done (DoD) _____________________________________________ 20
5. As cerimônias ____________________________________________ 21
5.1. Daily ______________________________________________________________ 21
5.2. Refinamento de negócio _____________________________________________ 23
5.3. Refinamento técnico ________________________________________________ 24
5.4. Planning __________________________________________________________ 25
5.5. Review ____________________________________________________________ 27
5.6. Retrospectiva ______________________________________________________ 29
5.7. Fluxo de trabalho ___________________________________________________ 33
5.8 Timebox ___________________________________________________________ 34
5.9. Calendário eventos Scrum ___________________________________________ 35
6. Histórias de Usuário _______________________________________ 36

6.1. Modelo ARO _______________________________________________________ 37
6.2. Modelo 3W _________________________________________________________ 37
6.3. Habilitadores _______________________________________________________ 38
7. Estimativas _______________________________________________ 39
7.1 T-Shirt ____________________________________________________________ 40
7.2 Fibonacci __________________________________________________________ 41
1
7.3 Exemplos usando Planning Poker _____________________________________ 41
8. As métricas que podemos usar no Scrum _____________________ 44

8.1. Burndown / Burnup _________________________________________________ 44
8.2. Velocity ___________________________________________________________ 47
8.3. Capacity ___________________________________________________________ 48
8.4. Scope Change______________________________________________________ 50
8.5. Backlog Health _____________________________________________________ 51
8.6. Lead Time e Cycle time ______________________________________________ 52
9. Comunicação _____________________________________________ 55
9.1. Comunicação não violenta ___________________________________________ 55
9.2. Rapport ___________________________________________________________ 57
9.3. Empatia ___________________________________________________________ 58
9.4. Gestão de equipes/pessoas __________________________________________ 59
9.5. Como redigir um bom e-mail __________________________________________ 60
9.6. Gestão do relacionamento com o Cliente _______________________________ 62
10. As Boas práticas do Scrum dentro dos times __________________ 63

10.1. Apoio ao P.O. ____________________________________________________ 63
10.2. Agilidade: Seja flexível (Não ser "by the book") “pense ágil” _____________ 65
10.3. Gestão de riscos __________________________________________________ 67
11. Ferramentas ______________________________________________ 71

11.1. Azure DevOps ____________________________________________________ 71
11.2. Jira _____________________________________________________________ 74
11.3. Miro ____________________________________________________________ 84
11.4. A importância de um Powerpoint bem-feito ___________________________ 87
11.5. Conteúdo essencial do Excel _______________________________________ 88
12. Gestão da rotina __________________________________________ 89

13. Leituras recomendadas_____________________________________ 90
13.1. Sprint a Sprint ____________________________________________________ 90
13.2. Funretrospective _________________________________________________ 90
13.3. Lean Inception ___________________________________________________ 91
13.4. Product Backlog Building (PBB) ____________________________________ 91
13.5. Kanban – David Anderson __________________________________________ 92
13.6. Scrum - A arte de fazer o dobro do trabalho na metade do tempo _________ 92
13.7. Treinamento de equipes ágeis ______________________________________ 93
13.8. Como fazer amigos e influenciar pessoas_____________________________ 93
13.9. Métricas Ágeis – Raphael Albino ____________________________________ 94
13.10. Comunicação não violenta _________________________________________ 94
2
IMPORTANTE!
Essa é uma versão em construção do manual,

está sendo elaborado de forma colaborativa,
qualquer sugestão ou correção enviar para o e-
mail: agilidade.centers.brasil@nttdata.com.
3
1. O que é agilidade
As práticas ágeis nos últimos anos tiveram um grande crescimento de popularidade,

principalmente nas áreas de produto, serviço e desenvolvimento de software. O problema que
se enfrenta é que estas estão sendo implementadas com foco na velocidade, baseadas no
conceito errado que a agilidade vai dar para as empresas maior rapidez na entrega.
O que tem que ficar claro é que agilidade não quer dizer apenas velocidade ou rapidez.
Quando se fala de agilidade, fala-se de um conjunto de características, que são: velocidade com
colaboração, flexibilidade, adaptação e sustentabilidade de acordo com os valores e princípios
do manifesto ágil publicado em 2001.
O “Manifesto Ágil”, foi elaborado em uma reunião formada por 17 pessoas que na época
trabalhavam usando metodologias, visando uma reformulação das técnicas existentes até aquele
momento. Nessa reunião foram identificados pontos em comum que todos utilizavam no dia a
dia.
A partir disso, chega-se à conclusão que, ser ágil não é ser rápido! Ser ágil é entregar
valor de forma flexível se adaptando às mudanças de forma colaborativa, entregando valor para
o cliente frequentemente com a melhor qualidade possível!
4
2. O que é o Scrum
O Scrum é um framework composto por papéis, artefatos e eventos (tópicos que serão
vistos respectivamente nos capítulos 3, 4 e 5) sustentado em 3 pilares: transparência, inspeção
e adaptação.
Tudo começa com um backlog de produto, tema que será aprofundado no capítulo 4.
Este é criado pelo Product Owner (PO) em conjunto com os Stakeholders (cujo papel será
detalhado no capítulo 3) e contém os itens necessários para melhorar ou construir um produto.
Este backlog de produto precisa ter um objetivo principal, chamado de meta do produto. A meta
pode ser a melhoria de um produto existente ou a construção de um novo para resolver algum
problema ou necessidade. Uma vez definida a meta, esta deverá ser cumprida ou abandonada
antes de assumir a próxima.
Todo trabalho necessário para atingir a meta do produto acontece dentro das sprints que
são períodos em que acontecem os desenvolvimentos e entregas de valor. Os itens do backlog
devem ser priorizados e ordenados de forma que seja possível trabalhar com alguns deles
durante uma sprint. O evento que vai selecionar quais itens serão trabalhados na sprint é
chamado de Sprint Planning.
Neste evento, detalha-se o que é e como será feito o trabalho de desenvolvimento durante
a sprint. Define-se também o objetivo ou meta para a sprint. Isso ajuda a ter coerência e foco no
que será trabalhado sempre considerando a meta do produto.
Durante a sprint, o trabalho é inspecionado diariamente com o objetivo de identificar
possíveis problemas e impedimentos para conseguir resolver ou pelo menos diminuir seus
impactos e adaptar o sprint backlog.
Já no final da sprint realiza-se um evento para apresentar o que foi desenvolvido para
todas as partes interessadas chamado de review e um outro evento onde o time reflete sobre o
que foi bem e o que pode melhorar nos processos internos e na forma de trabalhar do mesmo.
Esse trabalho por sprints cria previsibilidade e garante que o trabalho seja inspecionado e
adaptado em direção à meta do produto.
O Framework Scrum te diz a estrutura de trabalho que você deve seguir, mas não diz
exatamente como o time precisa fazer o trabalho. Isso vai depender das melhores práticas
usadas no contexto do time. Por exemplo, em um time de desenvolvimento de software, existem
boas práticas de codificação, de testes etc.
Outro exemplo aplicado ao framework é que não existe um evento definido para o
refinamento do backlog. O refinamento é uma boa prática na construção de um bom backlog pois
melhora o seu estado discutindo junto com o time o que precisa ser entendido para reduzir as
incertezas no desenvolvimento. Na seguinte figura apresenta-se de maneira gráfica toda a
estrutura do Scrum.
5
F RAMEWORK S CRUM
F O NTE : THELIBERATO RS . COM
Vale ressaltar que o Centers Studio Agile da NTT Data Brasil, leva para todas as alocações
em clientes a necessidade de ter flexibilidade e saber satisfazer os anseios do cliente pois o
framework é uma estrutura de trabalho complementada com boas práticas e não uma “receita
de bolo mágica” que vai resolver todos os seus problemas.
Dito isso, conclui-se que o objetivo da utilização desse framework é entregar um produto
que agregue valor para o cliente final. Esse valor pode ser agregado com entregas funcionais
contínuas e periódicas de qualidade, com respostas rápidas a mudanças. Isto permite estar
sempre prontos para reagir ao inesperado, financeiramente, gerando retorno sobre o
investimento feito pelo cliente e ainda por produtividade. Quando é priorizado o indivíduo e suas
interações e colaboração com o cliente, gera-se um ambiente de trabalho mais “leve”.
6
3. Papéis e responsabilidades
Neste capítulo será abordado cada papel que compõe um Time Scrum, que chamaremos
em certas ocasiões de Squad, e suas responsabilidades. Os principais papéis dentro de uma
squad que roda Scrum são na ordem:
1. Product Owner (PO)

2. Scrum Master (SM)
3. Dev Team
Além dos papéis que compõem um time scrum existe o papel dos Stakeholders que
embora não façam parte do time, vão aparecer em momentos específicos e, portanto, é
necessário considerar sua participação.
Quem trabalha com desenvolvimento de software está acostumado a ouvir os nomes
acima mencionados, mas nem sempre conhece quais as funções e responsabilidades de cada
papel. Por isso, este assunto tão importante será detalhado neste capítulo.
3.1. Product Owner
Product Owner é o profissional responsável por direcionar o time para que estejam
trabalhando em "atividades" que possuem um valor maximizado de acordo com a necessidade
do Cliente, visto que, ele é o dono do produto, entende as necessidades da empresa e as leva
para o time.
Qual a importância desse papel? A figura do PO é fundamental em projetos ágeis pois,
hoje em dia, as necessidades das empresas mudam a uma velocidade vertiginosa, de acordo
com alterações de escopo, objetivos ou mudanças de mercado. Para isso o PO precisa se
adaptar e flexibilizar para responder adequadamente às mudanças necessárias!
7
As principais responsabilidades desse papel são:
• Determinar os requisitos iniciais e gerais do projeto;

• Representar os usuários do produto;
• Analisar a viabilidade do projeto;
• Garantir que o produto seja entregue;
• Escrever histórias de usuário;
• Estabelecer critérios de aceite para histórias de usuário;
• Validar entregas;
• Criar e dar manutenção no Product backlog.
Por fim, é preciso salientar que o PO, necessita estar o tempo todo em contato com os
Stakeholders e com o Dev Team, mantendo desta forma uma comunicação clara e objetiva
para que se possa obter a melhor resposta possível às mudanças, com o maior valor
agregado.
8
3.2. Scrum Master
Este papel é o responsável por transmitir os pilares e valores do Framework Scrum. É um

dos 3 papéis que compõem o time Scrum, juntamente ao PO e o Dev Team. A principal
responsabilidade desse profissional é facilitar o trabalho de toda a equipe, principalmente sendo
o guardião do framework e facilitando a compreensão dos conceitos Scrum.
Dito isso, o SM é o membro da Squad que detém, em geral, maior conhecimento sobre o
framework, tornando-se dessa forma o responsável por potencializar a entrega de valor da
equipe e garantir que todos entendam e apliquem os pilares e valores.
Neste papel, uma das principais características que diferencia um bom profissional, ao
contrário de outros trabalhos técnicos, são as Soft Skills, que são habilidades como a
comunicação, facilitação e liderança servidora.
Além dessas habilidades um bom SM precisa ser proativo, extremamente receptivo a
mudanças, possuir “jogo de cintura” para ajudar o time no trabalho diário com a remoção de
impedimentos e conseguir direcionar as mudanças, baseadas em métricas de gestão ágil ou
boas práticas fora de “achismos”.
Partindo do cenário apresentado acima, criou-se uma lista de responsabilidades que o SM
precisa executar:
• Ajudar o time e a organização a entender a teoria e prática do Scrum;

• Remover impedimentos;
• Garantir o cumprimento de eventos;
• Apoiar o PO no gerenciamento do Product Backlog;
• Promover mudanças organizacionais;
• Disseminar a cultura ágil na organização;
• Ser um agente de mudança;
• Aumentar a produtividade do time usando métricas;
• Ser facilitador do trabalho e incentivar a colaboração da equipe;
• Fazer com que o time seja autogerenciável.
9
3.3. Dev Team
O Dev Team ou Time de Desenvolvimento, é o terceiro papel que compõe o Framework

Scrum. O Development Team é a equipe formada pelos profissionais responsáveis por
transformar o Product Backlog em um produto funcional. São eles que desenvolvem cada
incremento do produto “pronto” ao final de cada Sprint.
A característica principal de um Time de Desenvolvimento, dentro do Framework Scrum,
é ser auto organizável e multifuncional. Se auto-organizar gera um senso de responsabilidade
na equipe, sem precisar de uma figura no projeto que delegue as tarefas a serem executadas
para se chegar um incremento funcional.
Enquanto ser multifuncional não significa que todo o Dev Team deve saber executar várias
funções, pelo contrário, significa que dentro do time é necessário ter todas as funções
necessárias para desenvolvimento do projeto conforme planejado.
É importante ressaltar que o tamanho ideal de um Dev Team deve ser pequeno o suficiente
para se manter ágil e grande o suficiente para garantir a execução de uma quantidade
significativa do trabalho.
Vale lembrar que tamanho de Time de Desenvolvimento não é sinônimo de quantidade de
trabalho entregue, isso quer dizer que, se quer aumentar a quantidade de trabalho entregue não
necessariamente a contratação de mais desenvolvedores vai corresponder a necessidade.
Isso acontece devido ao fato de que quando a equipe se torna muito grande fica mais
difícil a comunicação e a organização do time, dificultando todo o processo demandado no
Framework Scrum aumentando a complexidade das interações interpessoais.
Resumindo as responsabilidades de um time de desenvolvimento são:
• Desenvolver um incremento potencialmente utilizável a cada sprint.
• Criar um plano de desenvolvimento para a Sprint (como vão construir o
incremento)
• Adaptar o plano a cada dia em direção à meta da sprint.
• Criar tarefas/tasks a partir das histórias que serão desenvolvidas na sprint.
• Garantir qualidade do incremento.
• Negociar adição de itens na sprint por causa de capacidade adicional.
10
3.4. Stakeholder
Como comentado anteriormente, Stakeholder não faz parte de um time Scrum. Porém,
neste guia este papel é ressaltado devido ao fato de ele estar presente e ter uma atribuição
importante no dia a dia das organizações.
Neste guia quando se fala de Stakeholder, geralmente refere-se às partes interessadas
de alguma forma com o resultado ou entrega do projeto/produto, desde gestores da empresa,
acionistas, colaboradores até fornecedores ou investidores/sponsors do projeto.
O papel em questão, nos projetos em que os funcionários da NTT Data atuam, tem a
função de demandante e patrocinador do projeto, sendo o interessado direto pela entrega do
produto. Em vários cenários o Stakeholder, junto ao PO, detém o conhecimento da visão do
negócio e qual objetivo ele quer alcançar com o produto, sempre pensando na visão de mercado
e no retorno de investimento que cada incremento irá gerar para a empresa.
Por estes, dentre outros motivos, o papel do Stakeholder é destacado, visto que na
vivência diária é este que, tanto o Scrum Master quanto o Product Owner, irão procurar na hora
de validar alguma decisão estratégica, já que são os interessados diretos no sucesso do produto
e são eles que viabilizam financeiramente.
Dito isto ressalta-se a importância de uma comunicação clara, objetiva e constante entre
todos os papéis, buscando sempre a maior transparência possível, capacidade de adaptação às
mudanças e inspeção contínua para garantir a qualidade da entrega e a colaboração entre as
partes para todos estarem sempre na “mesma página”.
11
4. Os artefatos
A proposta deste tópico é esclarecer os conceitos mais comuns sobre artefatos de forma
objetiva e sempre que possível trazendo vivências do dia a dia nas operações com alocação de
Agilistas da NTT Data. Um artefato representa o trabalho ou valor entregue e dá transparência
ao processo. Segundo o scrum guide, existem 3 artefatos principais: O Product backlog, o sprint
backlog e o incremento do produto. Cada artefato tem um compromisso que ajuda a aumentar o
foco e o alinhamento
• Product backlog: é a lista ordenada dos itens que são necessários para o
desenvolvimento ou melhoria de um produto. O PO é o responsável por ordenar e
priorizar o PB. Seu compromisso é a meta/objetivo do produto que ajuda a ao time a ter
um objetivo de longo prazo a se cumprir antes de se embarcarem em um novo.
• Sprint backlog: é uma lista ordenada dos itens que o time de desenvolvimento planeja
realizar durante uma sprint. Ele nasce a partir do product backlog e tem como
compromisso a meta/objetivo da sprint. Esta meta ajuda a manter o foco durante uma
sprint encorajando o Scrum Team a trabalhar junto ao invés de ter iniciativas separadas.
• Incremento: é a soma dos itens do sprint backlog completados em uma sprint. Cada
incremento é um passo para alcançar a meta do produto e deve funcionar junto com
outros incrementos entregues anterior ou posteriormente. O trabalho feito durante a
sprint não poderá ser considerado parte do incremento a menos que atenda o
compromisso da definição de pronto (DoD). DoD é uma descrição formal do que o time
deve considerar para afirmar que o trabalho está entregue.
A seguir serão abordados os compromissos dos artefatos com maior profundidade junto
com outros temas que ajudam a melhorar e manter os artefatos mencionados.
4.1. Objetivo do produto
Algumas perguntas recorrentes nas operações são: “por que estou desenvolvendo isso?”,
“qual o valor para o usuário final?”, “estou atendendo a necessidade do usuário, ou do negócio?”,
entre outras. Bom, dito isso, é necessário alinhar as expectativas e deixar claro o que se entende
por objetivo do produto.
Quando se fala de objetivo do produto o foco é sempre o negócio diferente de personas
cujo foco são os usuários. Partindo desta premissa e considerando as práticas de uma Lean
Inception (Ver capítulo de leituras recomendadas) em que as expectativas são alinhadas
podemos discursar sobre objetivo do produto.
Afinal, como saber qual é o objetivo do produto então? Para isso, é necessário em primeiro
lugar identificar um problema, que seja na sociedade, uma demanda de mercado ou uma
melhoria de algo existente. Após identificar um problema, será necessário propor soluções
12
práticas para esse problema, de forma que agregue algum benefício/valor tanto para a empresa
quanto para a persona (usuário final), que irá utilizar o produto ou serviço.
Uma boa prática para alinhar ideias e construir o produto certo do zero é rodar uma Lean
Inception. Esta prática vai ajudar o time a identificar problemas, propor soluções, alinhar
expectativas, identificar o público-alvo junto com jornadas de usuário, ou seja, como um usuário
interage com o produto. Tudo isto vai permitir que o time entenda o objetivo do produto e
identifique funcionalidades com o maior senso de valor.
O método acima vai direcionar e nortear o time para onde querem chegar, dessa forma,
eles terão uma meta clara, objetiva e palpável. Esta meta será o objetivo do produto.
4.2. Criação de backlog do produto
Definido o objetivo do produto e identificadas as funcionalidades que precisamos

desenvolver, chega a hora de materializar essas ideias, o famoso “colocar no papel”. Aqui nasce
o backlog do produto. O que é exatamente o backlog do produto?
O backlog do produto nada mais é do que uma lista priorizada de itens que podem ser
colocados em um produto, isto é, uma representação do business case estabelecido para o
produto.
Cada item que compõe o backlog do produto é chamado de PBI (Product Backlog Item) e
são esses itens, escritos pelo Product Owner, que serão priorizados do maior para o menor valor
agregado ao produto.
13
4.2.1.PBB (Product Backlog Building)
É importante destacar que não existe uma forma certa ou errada de se criar um backlog.
O que existem são boas práticas que podem ser adotadas para facilitar essa construção. Existem
muitos métodos que auxiliam nessa construção, aqui será apresentado um deles que é o PBB
criado pelo Fabio Aguiar. Ele servirá como apoio ao Product Owner caso ele precise definir um
Product Backlog ou melhorar um Product Backlog existente. Lembre-se que uma jornada de
criação de backlog precisa de todas as partes interessadas incluindo pessoas com domínio
técnico.
No PBB Canvas mostrado acima existem seis etapas que ajudam a construir um Backlog
de produto. O Canvas mostrado já está preenchido para auxiliar o entendimento com um
exemplo. O produto exemplo é uma plataforma para registrar e organizar palestras.
1. NOME DO PRODUTO
Essa é a parte em que se define o nome do produto.
2. PROBLEMAS
Nesta segunda etapa é muito importante que as pessoas de negócio consigam
identificar e compreender o estado atual do cliente, desta forma, destacando de
maneira colaborativa, quais problemas o cliente está enfrentando e que o produto
poderia resolver.
14
3. EXPECTATIVAS
No terceiro passo, o principal é identificar o estado desejado, ou seja, onde
queremos chegar, quais são as expectativas do cliente em relação ao produto.
Para alinhar as expectativas do estado desejado, é necessário propor soluções
para o estado atual, assim, chegando de forma compartilhada a um ponto comum.
4. PERSONAS
As personas ajudam a identificar quem é o público-alvo. É necessário definir
exatamente o tipo de persona que o produto quer atingir, para isso, é necessário
ser bem preciso, identificando características únicas e exatas da persona. É
interessante que a persona identificada esteja acompanhada do que ela faz
atualmente com produtos similares ou manualmente e o que ela espera que o
produto permita fazer.
5. FEATURES
Uma vez definidas as personas, é necessário identificar de maneira macro, as
features, ou funcionalidades. Uma funcionalidade é a descrição de uma ação ou
uma interação de um usuário com o produto. Na hora de escrever as
funcionalidades, é necessário verificar quais problemas resolve e quais benefícios
entrega para o usuário.
6. PBI: PRODUCT BACKLOG ITEMS

Nessa etapa é necessário detalhar as features do passo anterior em PBIs ou itens
do Backlog do Produto, entrando mais no detalhe da jornada que se deseja para
o produto. É necessário que os PBIs sejam escritos no modelo ARO (abordado no
capítulo 6.1.) e ordenados da esquerda para direita, de cima para baixo, do item
mais valioso ao menos valioso, de acordo com o entendimento de negócio do PO
ou das partes interessadas. Para identificar os PBIs o time precisa refletir no passo
a passo de cada feature, cada passo representa uma ação de um usuário com o
produto.
15
4.2.2.Hierarquia de construção
Hierarquia de construção é uma forma de organizar e refinar o Product Backlog até chegar
a um PBI que esteja pequeno e refinado o suficiente para se tornar um incremento do produto.
Como não existe um padrão de hierarquia de construção, variando de ferramenta para
ferramenta e do entendimento do time, isso ocasiona grande confusão. Portanto, será
apresentada a hierarquia usada no cotidiano dos agilitas da NTT Data.
ÉPICO - EPIC
HISTÓRIA DE USUÁRIO – USER STORY
TAREFA - TASK
Foi citado no tópico 4.2.1. a feature como uma funcionalidade macro. Essa funcionalidade
pode ser considerada como um épico na hierarquia de construção. Épico é uma história que
ainda não foi detalhada, é muito grande ou ainda possui muitas incertezas de negócio e/ou
técnicas. Os épicos, ainda precisam ser “quebrados” em histórias de usuário menores.
Exemplo de épico: Eu, enquanto praticante de esportes, desejo poder marcar jogos por
um aplicativo para que eu não precise ligar para tantos lugares.
Como mencionado acima, quando se quebra um épico em várias partes menores

identificam-se as histórias de usuário. Em resumo, uma User Story é um item do backlog
pequeno suficiente, de preferência que caiba dentro de uma sprint, que tem os requisitos
necessários para o seu desenvolvimento. Esta deve ser compreensível para clientes e usuários.
Exemplo de US 1: Eu, enquanto praticante de esportes, desejo reservar uma quadra por
um aplicativo para otimizar meu tempo.
Exemplo de US 2: Eu, enquanto usuário do aplicativo, desejo reservar a quadra mais

próxima da minha casa para economizar combustível e tempo.
A partir das histórias de usuário, finalmente chega-se às Tasks, itens técnicos

necessários para que uma US se transforme em um incremento funcional do produto. As tasks
são criadas pelo Dev Team pois está sob sua responsabilidade a construção do incremento e
definir como vai ser construído.
Exemplos de Tasks: Criar tela de cadastro, criar tabela no banco de dados, validar
campos etc.
16
4.3. Objetivo da Sprint
Segundo o Scrum Guide o objetivo da sprint é definido como: “Uma meta que serve como
guia para o time de desenvolvimento, pois ela reflete o que se espera alcançar ao final da Sprint,
do ponto de vista de negócio”.
É muito importante ter bem definida a meta da sprint e a prioridade de entrega, para que
todo o time saiba exatamente o porquê está desenvolvendo e onde necessita chegar
promovendo a colaboração, uma sprint sem meta clara e objetiva pode acabar perdendo o foco
e entregando no final dela algo que não agregue valor ao cliente.
Uma pergunta que poderia automaticamente surgir é: quem é o responsável por definir o
objetivo da sprint? Não existe uma pessoa específica ou papel que vai criar a meta sozinha, mas
ela pode ser identificada pelo PO olhando para o objetivo do produto e discutida/ajustada pelo
time. O PO consegue colocar todos na mesma página, dando um norte para o time.
Embora o ideal seria partir de uma pessoa de negócio como o PO, acontece também na
prática que o próprio Scrum Master e Dev Team precisam ter uma compreensão geral do produto
para conseguir identificar a meta na ausência de um PO.
Cabe ressaltar que a cada sprint o objetivo será diferente, mas sempre inserido no
contexto do produto e atrelado aos objetivos de negócio estabelecidos pela organização, por isso
é preciso que o time esteja na mesma página sempre alinhados com as expectativas claras.
17
4.4. Definition of Ready (DoR)
O DoR ou definição de preparado, é um conjunto de critérios definidos pelo time, que vão
detalhar o que uma US precisa ter ou cumprir para que possa ser desenvolvida pelo Dev Team.
Resumidamente, são os critérios que vão dizer se a história está preparada para entrar no
backlog sprint.
A responsabilidade para que a escrita das User Story possua DoR é do time e provocado
pelo Scrum master na ausência dele. O benefício do DoR é facilitar o entendimento do time para
que a US tenha menor quantidade possível de incertezas e falta de informação tanto de negócio
quanto técnica.
Vale ressaltar que não se deve tornar o DoR um impedimento em seu projeto. Ou seja, a
Definition of Ready não precisa estar 100% detalhada, mas precisa ter um detalhamento
suficiente para que o time de desenvolvimento se sinta confortável com a história e ela esteja
preparada para entrar em uma sprint.
18
4.5. Critérios de aceite
Os critérios de aceite são parte fundamental de uma User Story. Isso significa que, para
uma US estar completa, ela precisa ter critérios de aceite bem definidos e listados. Normalmente,
os critérios de aceite são representados em forma de lista de regras de negócio que apresentam
os resultados esperados para validar as funcionalidades implementadas.
Chama-se assim pois, por meio dessa lista é possível descobrir se a US, quando entregue,
atende ou não às expectativas do PO, do ponto de vista do negócio. Geralmente os critérios de
aceite estão em conformidade com as regras de negócio que o PO identificou, mas são muito
usados para a criação de cenários de testes e por tanto o Dev Team também pode ajudar a
refinar esses critérios.
19
4.6. Definition of Done (DoD)
Assim como a Definição de Preparado (DoR), a Definição de Pronto (DoD) também é

definida pelo time. O DoD é um conjunto de critérios, que vão detalhar o que uma US precisa ter
ou cumprir para que possa ser considerada pronta ou entregue (Done). Como cada projeto e
cada time tem suas particularidades, não existe uma forma padrão que servirá para todos.
Se você trabalha ou trabalhou com desenvolvimento de software, já deve ter escutado em

seu projeto frases como:
• Está pronto, só falta testar;

• Está pronto e funciona localmente;
• Está pronto, só falta deploy em ambiente produtivo.
A verdade é que, justamente para evitar esse tipo de dúvida em saber quando realmente
uma história está pronta, é preciso combinar o DoD. Dessa forma não haverá confusão nem
dúvidas de quando a história está pronta.
20
5. As cerimônias
Finalmente é hora de falar sobre as cerimônias Scrum. As cerimônias previstas no

framework são: Daily, Planning, Review e Retrospectiva. Na continuação, serão abordadas todas
elas junto com o refinamento de negócio e o refinamento técnico que são considerados como
boas práticas. Inicialmente será apresentado um diagrama com as informações mais importantes
de cada cerimônia e no final será apresentado um diagrama de fluxo com o passo a passo de
cada uma delas. Use os gráficos como um guia para aplicar na condução das suas cerimônias.
5.1. Daily
A Daily é uma reunião rápida diária. O Scrum Guide estabelece um Timebox de 15 minutos
onde todo o time Dev fala da evolução da sprint. Esta é uma oportunidade de inspecionar e
adaptar o trabalho. Para a realização desta cerimônia é esperada a participação do Dev Team e
do SM. Já o PO não é obrigatório, mas ele pode entrar para saber o estado atual do
desenvolvimento e para ajudar a tirar dúvidas.
Em um contexto de agilidade existe a realidade da teoria e da prática. Cada Squad é única
e, portanto, a Daily também tem de ser! Isso significa que pode-se fazer da cerimônia o que bem
entender? Também não, existem algumas boas práticas que serão orientadas a seguir.
Primeiramente a Daily é uma reunião rápida, se deixar estender demais perde-se o foco e
o objetivo da reunião. O objetivo principal da cerimônia é permitir que todo o time esteja na
mesma página ao longo da sprint, que ele consiga levantar impedimentos e identificar possíveis
atrasos que podem vir a acontecer.
Em algumas alocações o SM chama um desenvolvedor de cada vez para ele passar um
panorama geral de como está a evolução de suas tarefas e se existe algum impedimento. Em
21
outros projetos o SM comenta sobre uma história e quem estiver trabalhando nela informa se
existe algum bloqueio ou impedimento e como está o decorrer do desenvolvimento.
A verificação por história ajuda a entender o trabalho de vários Devs atuando em paralelo,
por exemplo: ao mesmo tempo que um desenvolvedor está trabalhando no back-end outro pode
trabalhar no front-end e ao mesmo tempo um QA pode estar gerando massas de teste.
O Scrum Guide não estabelece a presença do PO como obrigatória. Pela experiência, é
recomendada a participação dele nas Dailies desde que seja produtiva. O papel do SM durante
a cerimônia é de intervir e certificar-se de que qualquer impedimento ou problema será tratado
em um fórum separado com a presença dos interessados (cuidado com a forma de falar).
Finalmente, orienta-se que em times menos experientes, o SM provoque o time Dev para
apresentar a situação real do andamento da sprint. Percebe-se que em algumas ocasiões existe
uma resistência em apresentar impedimentos e pedir ajuda. O Scrum Master deve fazer com que
o time entenda que a Daily é um ambiente seguro, colaborativo, para gerenciamento de risco e
alinhamentos, de suma importância para o sucesso da uma Sprint.
A continuação apresenta-se, de maneira resumida, a sequência de trabalho para a
condução de uma Daily.
Use o workflow como um guia para aplicar na condução das suas cerimônias, mas não
como uma regra, visto que, cada time pode possuir formas ou necessidades diferentes de como
executar os eventos.
22
5.2. Refinamento de negócio
O refinamento do Backlog, é um processo contínuo onde o Product Owner, de forma

colaborativa com o time, vai aperfeiçoando as histórias para que elas estejam prontas para entrar
no Backlog da sprint. Como no dia a dia acaba que as partes interessadas não refinam como
deveriam o Backlog, devido a correria do trabalho e outras prioridades, recomenda-se fortemente
deixar um ou dois encontros por semana para refinamento de negócio.
Orienta-se que nessa cerimônia participem o PO, UX, Especialistas, Arquitetos, QA e SM.
Vale lembrar que o objetivo deste encontro é refinar as histórias do backlog do produto que se
espera que entrem nas próximas Sprints, de acordo com a prioridade do negócio.
Para a condução de um refinamento técnico são levadas em consideração as seguintes
perguntas (elas deverão ser facilitadas pelo SM):
• Realizar o entendimento das histórias do backlog;

• Por que vamos desenvolver essa história?
• O que precisa que seja desenvolvido?
• É possível criar os Cenários de Testes baseados nas regras de negócio?
• Quais serão os critérios de aceite para a história? (Eu sei como mostrar o término
deste trabalho?);
• É viável o desenvolvimento? (Apenas sim ou não. Não se deve discutir como será
desenvolvido nesse momento. Isso será feito no Refinamento Técnico);
• Qual o DoD da história?
• 1º Dia: Entendimento das histórias (Negócio) e identificação dos possíveis
cenários de testes baseados nas regras de negócio;
• 2º Dia: Validação da linha de pensamento dos cenários de testes baseados nas

regras de negócio e detalhamento dos entendimentos que forem necessários.
É indicado fazer o refinamento em dois dias pois entende-se que, pelas experiências em
alocações, o formato mais eficaz é alternar um refinamento de negócio com um refinamento
técnico, para que no segundo encontro de cada, sejam solucionadas pendências de negócios e
técnicas dos encontros anteriores.
23
5.3. Refinamento técnico
Da mesma forma que é indicado ter um refinamento de negócio, é de extrema importância

fazer um refinamento técnico, para ter a certeza de que na próxima Planning as Histórias que
serão estimadas tenham a menor quantidade possível de incertezas. Dessa forma, em algumas
alocações é possível aumentar significativamente a assertividade de estimativa das histórias,
conseguindo minimizar os riscos durante uma Sprint, tendo assim menor quantidade de
impedimentos e dúvidas ao decorrer do desenvolvimento.
É sugerido que nessa cerimônia participem Especialistas, Arquitetos, QA, UX e SM. Vale
lembrar que o objetivo desse encontro é refinar tecnicamente as histórias do backlog do produto
que se espera entrem nas próximas Sprints de acordo com a prioridade do negócio.
Para a condução de um refinamento técnico são levadas em consideração as seguintes
perguntas (elas deverão ser facilitadas pelo SM):
• Existe alguma dependência técnica ou de outra equipe para realização das
histórias?
• Todos os acessos necessários estão liberados para que a história seja
desenvolvida?
• Falta alguma informação importante para desenvolver a história?
• A história cabe dentro de uma sprint? Ou é necessário quebrá-la?
• Se a história for quebrada ela será rediscutida no 2° encontro do refinamento de
negócio.
• O DoD da história está claro para todos? É de conhecimento de todos quando a
história pode ser considerada como concluída?
• 1º Dia: Levantamentos técnicos necessários para desenvolvimento e possíveis
impedimentos/dependências;
• 2º Dia: Validação da linha de pensamento e verificação se os pontos levantados
no 1°dia foram sanados até esse segundo encontro.
Uma sugestão de datas para o refinamento de negócio e para o refinamento técnico a

seguir: terça-feira: refinamento de negócio - duração 1 hora, quarta-feira: refinamento técnico
duração - 30 minutos e quinta feira refinamento de negócio seguido do refinamento técnico:
duração - 1 hora e 30 minutos respectivamente.
Vale lembrar que datas, tempo de duração e papéis sugeridos para participação desses
eventos são somente sugestões que dependem do tamanho dos times, realidade do projeto e
disponibilidade dos interessados. Não use esse guia como um passo a passo de trabalho.
Pense de maneira ágil e utilize este guia para insights, pois cada time e cada projeto são
únicos, dessa forma, a condução tem que ser única.
24
5.4. Planning
A Sprint Planning é a reunião na qual é feito o planejamento do trabalho dentro de uma

Sprint. É nela que o time estima as histórias que irão entrar no Sprint Backlog e que todo o time
Scrum se alinha quanto as expectativas e meta da sprint.
Se seguiu a dica e dedicou um tempo prévio para fazer reuniões de refinamento do Product
Backlog junto ao PO, com certeza vai perceber que a Planning será mais produtiva e as
estimativas serão muito mais assertivas e próximas da realidade.
Embora a Sprint Planning pareça simples de se realizar, ela pode gerar bastantes
discussões e será necessário seguir uma estrutura definida para facilitar sua condução. Primeiro
o PO apresenta para o time as histórias que gostaria que entrassem para o backlog da sprint, já
previamente refinadas. Se a dica de refinamento de negócio e técnico foi seguida, a essa altura
bastante gente da equipe já está familiarizado com a US. Dessa forma, a maioria das dúvidas
que possam surgir pelo time de Dev, provavelmente já foram sanadas durante os encontros de
refinamento, se ainda tem dúvidas não tem problema de discutir e resolver todos juntos.
Após o PO apresentar a história, o SM pode puxar uma votação para estimar o esforço da
história. É comum utilizar a sequência de Fibonacci e a técnica do poker planning para chegar
em um consenso. O Poker planning ajuda a que a votação de um integrante não seja vista por
outro integrante até o final da votação. Isso é importante para os desenvolvedores não serem
influenciados por outros mais experientes mantendo a lisura do processo. Veja o capítulo 7 para
entender melhor o processo de estimativas.
Após a votação ser encerrada, caso haja alguma discrepância entre os membros do time,
quem votou divergente apresenta seus argumentos e outras pessoas podem apresentar um
contra-argumento também para defender seu ponto de vista. Em seguida o SM solicita uma nova
votação para saber se as pessoas chegaram a um ponto em comum.
25
É indicado que participem da votação todo o time de desenvolvimento, back-end, front-

end, arquitetos, Lider Técnico, Arquitetos E2E, QA, enfim, todos que estarão envolvidos de
alguma forma no desenvolvimento das histórias do ponto de vista técnico. Não há necessidade
do Product Owner, Scrum Master ou gerência participarem da votação de esforço do trabalho já
que não vão fazer parte do desenvolvimento e na maioria das vezes não possuem o
conhecimento ou a informação técnica.
Após finalizar a estimativa de esforço para cada história candidata a entrar no backlog da
sprint, é a vez de selecionar, de acordo com o Capacity do time, as histórias que serão
desenvolvidas na Sprint por prioridade de negócio definida pelo Product Owner.
Uma boa prática indicada é fazer um alinhamento na própria Planning sobre qual é a
história de maior valor para o PO, dessa forma o time pode focar naquela história e tentar
entregar com maior prioridade ou comunicar o quanto antes para o cliente caso ela tenha
impedimentos ou possíveis atrasos. Isto fará com que o cliente não seja pego de surpresa em
uma review e garante que os esforços sejam alinhados às expectativas do cliente.
A continuação apresenta-se de maneira resumida a sequência de trabalho para a
condução de uma planning. Considere que o time todo vai discutir uma história de cada vez até
fechar o sprint backlog de acordo com o seu Capacity.
26
5.5. Review
Já teve dificuldades em cumprir objetivos da sua empresa? Isso é muito mais comum do
que se imagina, mesmo tendo as metas bem definidas, às vezes acontece de “deixar para trás”
os objetivos. Nesse sentido, revisar o desenvolvimento e as entregas periodicamente é de suma
importância para manter o foco no resultado.
A Sprint Review surge com o intuito de verificar a cada sprint o incremento entregue pelo
time e verificar se o que está sendo feito ajuda a cumprir os objetivos tanto da sprint quanto do
negócio. A review é uma cerimônia prevista no Framework Scrum para revisar e validar as
entregas ao final de cada Sprint. Para esta cerimônia é indicada a participação do time Scrum
como um todo.
Como é a dinâmica dessa reunião? Parte-se da ideia de que a apresentação da entrega
tem que ser do software funcionando, e não a apresentação apenas de prints ou um power
points. Apresenta-se a entrega funcionando no ambiente combinado, de acordo com os critérios
de aceite e DoD definidos pelo time. É indicado que o Dev Team, de preferência alguém de testes
(QA), apresente o incremento funcional para o PO e stakeholders, já que a última etapa de um
desenvolvimento normalmente é o teste do desenvolvimento.
A dinâmica é a seguinte: alguém da equipe de QA (caso não tenha um time de QA, será
algum dev que trabalhou e testou a história) apresenta as histórias funcionando no sistema, com
os incrementos solicitados pelo PO na Sprint em questão. Ele demonstra que o desenvolvimento
atende os critérios de aceite e a DoD junto às definições de UX e o PO junto com as partes
interessadas validam ou não a US. Caso a validação não seja explícita, o Scrum Master pode
questionar para ter transparência no entendimento.
Se a história for validada, apresenta-se a próxima história e segue a mesma dinâmica.
Caso a história não for validada, o Scrum Master precisa verificar com o Product Owner o que
faltou, quais critérios de aceite ou qual ponto do DoD não foi atendido. A continuação com a
27
facilitação do SM, o time negocia a entrega e validação posterior dessa US ou de uma nova US
para terminar o trabalho ou da realização de alguma melhoria que será priorizada ou não pelo
PO nas próximas sprints. Tente evitar ao máximo este cenário, caso isso aconteça é necessário
avaliar se a descrição da User Story não estava clara ou se faltou atenção/qualidade durante o
desenvolvimento ou testes do incremento.
Uma outra dica é, sempre que tiver validação de histórias, solicite a formalização na
ferramenta de trabalho para o Product Owner ou aprovador. Caso o projeto não possua uma
ferramenta oficial, o Scrum Master pode pedir uma formalização por e-mail, para formalizar um
registro de entregas que será levado na próxima review ou em uma futura apresentação de valor
agregado ao projeto.
condução de uma review.
28
5.6. Retrospectiva
Chega-se, finalmente, a última cerimônia do Scrum dentro de uma Sprint: a retrospectiva.

Esta é a peça fundamental que fará o time evoluir, melhorar os resultados e aumentar a sua
maturidade. Nada do framework faria sentido sem avaliarmos o que o time errou ao longo da
sprint, o que o time acertou e sugerir planos de ação de melhoria. O Framework Scrum é um
método empírico e evolutivo.
A retrospectiva da sprint é conduzida pelo Scrum Master e participa todo o time de
desenvolvimento e o Product Owner (sendo que ele não é obrigatório). Durante esta cerimônia
pode-se perceber a aplicação dos 3 pilares do Scrum: transparência, inspeção e adaptação.
Transparência visto que, sendo transparente sobre dificuldades e acertos da sprint (saber
fazer essa análise, inspeção) vai direcionar o time para montar um plano de ação de melhoria
para as próximas sprints e dessa forma evoluir (adaptação).
Para o Scrum Master a retrospectiva começa com a criação do template que vai ser
utilizado durante a cerimônia e com a escolha de algum “quebra gelo” ou “energizer” para o time
se sentir mais à vontade. É indicado utilizar dinâmicas que induzam abertura da câmera caso
aconteça de forma remota, de tal modo a estimular uma participação maior e foco na reunião.
Após essa dinâmica para deixar o time mais à vontade, o Scrum Master apresenta o board
da retrospectiva e disponibiliza um tempo para cada etapa de captação de informações
relevantes.
O Scrum Master deve buscar falar o menos possível. A retrospectiva é para o Dev Team
inspecionar a Sprint e adaptar o seu trabalho na próxima dentro de um processo empírico de
evolução continua, o aconselhado é que cada pessoa coloque um card anonimamente no board
e quem se sentir à vontade para comentar algum que fique à vontade. O desafio do Scrum Master
é exatamente achar técnicas que façam o time ser participativo e colaborativo, para isso busque
ter empatia, utilize sempre uma comunicação não violenta e Rapport (todos tópicos do capítulo
29
9). Uma sugestão é fazer o time entender que eles são os protagonistas do sucesso do time.
Então, todas as melhorias resultarão em melhorias diretas no dia a dia de trabalho de cada um
na Squad, na forma de experimentos pequenos.
Para montar um plano de ação, o Scrum Master deve ressaltar a importância de colocarem
ações concretas que, possivelmente, resolvam algum problema levantado pela equipe do que
não foi bem durante a Sprint. Caso surjam muitas propostas, deixa aberto para a discussão,
priorizem de forma colaborativa e escolham o que for possível implementar já na próxima sprint.
Soluções de médio e longo prazo, não devem ser descartadas, mas é necessária uma análise
do impacto delas nas tarefas do dia a dia.
condução de uma retrospectiva.
30
Por fim, segue abaixo alguns exemplos de boards de retrospectivas que foram aplicadas
em alguns projetos do Studio Agilidade Centers.
31
32
5.7. Fluxo de trabalho
A seguir, mostra-se o fluxo de trabalho durante uma sprint. Ressalta-se que, antes de
começar uma sprint é necessário fazer refinamentos para preparar as histórias que serão levadas
na planning. Além disso é importante que, no decorrer de uma sprint sejam feitos refinamentos
para preparar as histórias suficientes de uma ou de duas sprints na frente. Dessa forma garante-
se que o fluxo de trabalho do time não seja interrompido por falta de histórias.
No refinamento verifica-se a definição DoR junto com os critérios de aceite e DoD. Na
planning também verifica-se os critérios anteriores e são discutidos ou adicionados novos
critérios que não tenham sido identificados nos refinamentos. Se a história tem ainda muitas
incertezas para definir os critérios, ela voltará para um outro refinamento e não será considerada
para a sprint. Nas dailies, verifica-se diariamente como está o andamento das histórias que foram
planejadas e adapta-se o trabalho removendo qualquer bloqueio ou impedimento para que o time
consiga continuar o trabalho.
Na review verifica-se se as histórias foram concluídas usando a DoD. Caso uma história
não atenda essa definição, volta-se ao backlog para que seja terminada na próxima sprint com
a prioridade que o PO considere. Por fim, na retrospectiva, verifica-se o que deu certo e não tão
certo para criar planos de melhoria na forma de fazer experimentos que serão considerados na
próxima sprint dentro da planning ou inclusive nos refinamentos, caso eles sejam atingidos pelas
melhorias.
33
5.8 Timebox
O conceito de Timebox é uma caixa de tempo, previamente estabelecido e que não deveria
ser ultrapassado. O Timebox ajuda a manter qualquer tipo de reunião objetiva evitando tratar
outros assuntos que não agregam. Com esse objetivo todos os eventos ou cerimônias Scrum
tem um timebox estabelecido pelo Scrum guide. Uma daily por exemplo, tem um timebox de 15
minutos de duração. Embora seja importante manter esse timebox, é recomendado ter
flexibilidade é não ser “by the book” e muito menos “Xiitas” sempre que a situação o permita.
Utilize técnicas e boas práticas ou realize um trabalho prévio para manter o timebox.
As expressões acima, trazem o conceito de não seguir cegamente o livro. Não se deve
“levar tudo ao pé da letra”. É importante ser flexíveis e adaptar às necessidades do dia a dia.
Sabe-se que em algumas situações o time não vai ficar exatamente 15 minutos em uma Daily.
Esta, muitas vezes, dura 20 ou até 30 minutos. Mais do que isso já sai fora do objetivo da reunião.
Uma técnica para manter o timebox dentro de uma daily é o Parking Lot, sugerida por Mary
Provinciatto e Paulo Caroli, em seu livro Sprint a Sprint. O parking lot é um espaço (dentro da
ferramenta de gestão utilizada ou da ferramenta de colaboração como o Miro) onde são
registradas todas as dúvidas ou assuntos que são importantes, mas que no momento saem do
objetivo da cerimônia. Após o término da reunião pode se puxar uma outra sala para tratar esses
assuntos específicos, de acordo com a necessidade e sem timebox definido.
Uma boa prática para manter o timebox durante uma Sprint Planning pode-se realizar
refinamento de histórias tanto no que diz respeito à visão de negócio quanto em relação à visão
técnica. Essa prática é fundamental para uma Planning mais produtiva e assertiva, tanto quanto
as estimativas. Nesse último caso, os líderes já estarão familiarizados com as histórias e no
entendimento do que precisa fazer para realizar uma entrega de valor o que facilitará as
discussões durante o processo de estimar cada história. Dessa forma na Planning faz-se um
alinhamento com o time, estima-se as histórias/tarefas a serem feitas na Sprint, e emprega-se
mais esforços na mitigação dos riscos com todos ficando na mesma página.
Outra boa prática, aplicada a qualquer reunião com timebox definido, é realizar um “Pré
Work” para organização. Desta forma a pauta da reunião já estará preparada com anterioridade,
e poderá ser evitado qualquer outro assunto fora do objetivo da reunião. Com isso ganha-se
tempo e mantem-se o timebox.
E quem deve estar presente nesse “Pré Work”? O que é feito? Por se tratar de
organização, é importante a presença de pessoas estratégicas apenas quando necessário tais
como, o PO, o SM atuando como facilitador e dando dinamismo à reunião, os DEVs que são os
líderes, “os mais experientes” dentro de suas respectivas tecnologias, por exemplo: o QA “mais
experiente”, que está à frente, o Back-End, Dev de Front, e assim por diante.
A seguir mostra-se um calendário para uma sprint de 15 dias, o calendário mostra quais
cerimônias os dias e os timebox esperados para cada uma.
34
5.9. Calendário eventos Scrum
Dentro de algumas operações no Studio Agilidade Centers, usa-se o modelo de calendário

para os eventos Scrum mostrado na imagem abaixo. Considere-o como um guia e não como um
padrão, pois os dias, horários e timebox das cerimônias devem ser combinados em conjunto com
o time. Por exemplo, pode ser que no seu caso uma sprint tenha uma duração de uma semana.
Dessa forma, o timebox da planning, review e retro será reduzida pela metade. Outro exemplo
que pode acontecer é que o início da sprint seja toda quarta-feira, nesse caso o calendário
precisa ser adaptado.
Você pode perceber que no calendário acima aparece apenas uma reunião de refinamento
semanal. Existem times mais maduros ou times cuja realidade não permite fazer refinamentos
em dois dias. Nesses casos faz-se apenas um refinamento juntando negócio e técnico. Caso
exista a necessidade de fazer um refinamento de negócio e um refinamento técnico, use as dicas
mencionadas na seção 5.3.
Dicas: tente reduzir a duração da sua planning para não ficar tão pesada para o time,
ainda mais se for um time remoto. Use os refinamentos para tentar reduzir esse tempo tirando
qualquer incerteza e dependência. Tente deixar um espaço de tempo de pelo menos 10-15 min
entre a Review e a Retro para que o time consiga descansar. A Daily pode se estender além dos
15 minutos, sempre que for para cumprir os objetivos da cerimônia. Em times maiores, às vezes,
15 minutos é pouco tempo.
35
6. Histórias de Usuário
As histórias de usuário nasceram como uma representação dos itens do product backlog (PB)
do ponto de vista de um usuário. Como o PO é o responsável pelo PB, ele costuma escrever
as histórias de usuário, porém, qualquer pessoa do time pode escrevê-las sempre que façam
sentido para o negócio, sejam validadas e priorizadas pelo PO.
Escrever uma boa História de Usuário (US) não é uma tarefa tão simples quanto parece.
No dia a dia, percebe-se que em muitas alocações é necessário apoiar o PO para melhorar a
sua escrita. Existem vários métodos e boas práticas para auxiliar na escrita de uma boa história,
uma delas é o critério INVEST.
O primeiro ponto a ser levado em consideração é que a US precisa ser independente.

Talvez esse ponto, no cotidiano seja o mais difícil de cumprir. Se na hora da criação de histórias,
uma depende de uma outra, ela precisará ser analisada para tirar qualquer dependência ou
poderá ser unificada sempre que o esforço para sua construção couber dentro de uma sprint.
Segundo ponto, uma US precisa ser negociável, isto é, precisa ter um ponto de partida
de escopo variável. Isso vai permitir que ela não seja engessada, permitindo de tal forma que se
possa conversar e separar, caso necessário, a prioridade de cada funcionalidade dentro de uma
mesma User Story.
Terceiro, a US precisa ser valiosa. Todo framework se baseia em agregar valor ao cliente
final. Isso não é diferente com cada história. É necessário lembrar que valor de negócio nem
sempre corresponde ao valor de usuário, então, precisa alinhar bem com o PO qual o valor de
negócio que a história está agregando ao final da entrega.
Em toda metodologia ágil é imprescindível que, ao final de uma sprint, uma história resulte
em uma funcionalidade ou solução concreta. Para isso, é preciso que a história seja estimável,
ou seja, que o Dev Team consiga compreender o que está sendo colocado e que consiga estimar
o esforço necessário para completar aquela história.
Quando se fala sob medida, nada mais é do que ter o tamanho suficientemente grande
para que agregue valor e pequena o suficiente para que caiba em uma sprint. Para que isto
aconteça, a US deve ter o mínimo possível de incertezas, tanto de negócio quanto técnica.
36
Por fim, testável. Não tem como considerar uma história entregue se ela não tiver cenários
de testes. É necessário que toda história ofereça possibilidades de ser testada para poder
garantir a qualidade e que a funcionalidade entregue atenda as expectativas do cliente.
Explicados todos os pontos do critério INVEST sobre escrita de histórias, ressalta-se que
esse é um critério ideal para uma história de usuário adequada e pronta para ser desenvolvida.
Porém, no dia a dia, muitas vezes acontece de a US não conseguir atender todos esses pontos
por vários motivos. Isso não significa que a funcionalidade deixará de ser desenvolvida.
Nesse cenário, é preciso analisar com todo o time e com o PO se a história ainda assim
faz sentido o desenvolvimento e se ela irá agregar algum tipo de valor. Caso a resposta seja sim,
a US será desenvolvida. Caso a resposta seja não, o ideal é que a história seja refinada
novamente para entrar nas próximas sprints.
6.1. Modelo ARO
Como comentado, as histórias de usuário são uma forma de representar itens do PB.
Existe uma outra forma de fazer essa representação que inclusive pode auxiliar em uma eventual
escrita de histórias de usuário no modelo tradicional (que será mostrado a seguir).
O Modelo ARO é uma representação da ação de um usuário com o produto.
MODELO ARO
AÇÃO
RESULTADO
OBJETO
A escrita começa com a ação que deverá ser um verbo, na sequência está o resultado e
em seguida o objeto. Por exemplo: efetuar a compra de um livro, está no modelo ARO. Efetuar
é a Ação, a compra é o Resultado e o livro é o Objeto.
6.2. Modelo 3W
O modelo 3W é o modelo mais popular ou comum para representar um item de backlog

como uma história de usuário. O modelo responde a três questões (em inglês Who, What, Why).
Quem (perfil do usuário/persona), O quê (ação a ser realizada/funcionalidade do produto) e Por
quê (valor para o negócio ou usuário).
37
MODELO 3 W
AS A (WHO?)
I WANT (WHAT?)
BECAUSE (WHY?)
Para facilitar a escrita o modelo 3W utiliza-se o template mostrado acima, que em

português fica da seguinte forma:
Eu como (Quem) usuário do app
Necessito (O quê) efetuar um cadastro de usuário
Para (Por quê) minha identificação
6.3. Habilitadores
Além de histórias de usuário, cujo objetivo é representar os requisitos ou funcionalidades

que um usuário precisa, existem outros tipos de itens no backlog identificados como
Habilitadores.
Os habilitadores auxiliam quando não é possível escrever uma história de forma completa
ou refiná-la pois ainda existem algumas dúvidas. Provavelmente a história precisará de um
estudo prévio ou de um detalhamento técnico que permita sua construção.
No primeiro caso, trata-se de um habilitador exploratório ou Spike. Ele é necessário antes
de conseguir escrever completamente uma história de usuário. Este tipo de habilitador realiza
uma pesquisa, esclarecimentos ou uma escolha entre várias opções previamente para que o
trabalho em uma história futura já identificada seja possível.
No segundo caso, trata-se de um habilitador técnico. Exemplos são refatorações,
melhorias no pipeline ou nos testes. Este tipo de atividades requer muito esforço e costuma-se
registrar no backlog como um habilitador técnico. Geralmente, uma ou várias histórias
dependerão deste tipo de habilitador. Portanto, sempre deverá ser indicado qual ou quais
histórias serão afetadas por ele.
Por fim, cabe mencionar que a representação deste tipo de itens no backlog costuma ser
por meio do modelo ARO pois não há necessidade de escrever no formato 3W. Por exemplo:
“Realizar automação de testes”.
38
7. Estimativas
O processo de estimar, principalmente em projetos de software, é a forma de prever, por

meio de alguma variável, a quantidade de esforço necessário para desenvolver ou realizar
alguma atividade baseada na informação que o time tem à disposição naquele momento.
A forma tradicional de estimar o esforço é por meio do tempo em horas ou dias. Esta forma
de estimar é chamada de estimativa absoluta porque dá-se um valor específico e finito. Os
seres humanos não são bons em estimar. Estimativas absolutas são influenciadas pela
experiência da pessoa, a incerteza e a pressão do tempo para entregar entre outras coisas.
Nesses casos, a tendência é ser otimista ou pessimista demais e muito raramente realista,
especialmente em projetos ágeis, onde existem inúmeras incógnitas, mudanças, falta de
informações e dependências o tempo todo.
Diante dessas dificuldades para estimar de forma realista, por que não fazer diferente?
Em projetos ágeis usa-se o processo de estimar de forma relativa. Estimar relativamente
consiste em comparar ou agrupar histórias em termos do esforço olhando para características
como complexidade, risco e incerteza.
Para entender melhor os conceitos sobre estimativas, olhe para a imagem abaixo e
estime qual desses edifícios é o mais alto, 1, 2 ou 3?
Fácil, não é? Comparando as alturas dos edifícios da imagem em relação ao solo, o

edifício mais alto é o número 1. E se agora precisar estimar a altura desses edifícios? Aí já não
é tão fácil. Uma forma de estimar seria supor a altura de um andar e depois contar a quantidade
de andares, isto por cada edifício. Essa estimativa poderá ser muito imprecisa e levará muito
39
tempo para ser feita. O primeiro caso foi um exemplo de estimativa relativa e o segundo de
estimativa absoluta.
Aplicando os conceitos no dia a dia de um SM, a estimativa relativa vai permitir que as
pessoas dos times consigam estimar em conjunto o esforço das histórias de usuário e chegar
em um consenso olhando para 3 características principais:
• Risco (risco de não acontecer de acordo ao planejado)

• Incerteza (o que não se sabe naquele momento?)
• Complexidade
Uma boa prática quando o time está começando com estimativas relativas é encontrar
uma linha base de esforço para estimar. Sempre inicia-se selecionando uma história de usuário
como referência e a partir dela, estima-se as outras comparando o seu esforço.
Existem várias técnicas para estimar uma história usando os conceitos de estimativas
relativas, aqui serão apresentados dois dos mais populares, tamanho de camisetas ou t-shirt
sizes e pontos de história baseados na sequência de Fibonacci.
7.1 T-Shirt
Tamanho de camisetas é uma técnica que ajuda a estimar uma história atribuindo um
tamanho de camiseta (do PP ao XXG) que representa seu esforço relativo. Ver imagem.
Usar esses tamanhos ajuda ao time a abstrair o esforço fugindo dos números que são
muito associados ao tempo.
Um bom exercício para iniciar com estimativas é usar tamanho de camisetas junto com
exemplos fora da área de TI. Considere que o time precisa estimar o tamanho relativo das frutas
da tabela abaixo. Como primeiro exercício eles deverão estimar o tamanho relativo de cada fruta
e depois a dificuldade para cortar.
40
Neste caso, o time pode começar pela fruta com maior tamanho ou menor tamanho e
estimar as demais usando essa primeira como referência. Embora não tenha um certo ou errado
nas estimativas, sempre devemos considerar o bom senso na hora de comparar e manter uma
consistência dentro do time.
7.2 Fibonacci
A sequência de Fibonacci é outra técnica muito utilizada para estimar usando pontos de
história ou Story points. Os pontos de história são números que representam uma escala para
comparar o esforço de uma história.
A sequência de Fibonacci é muito útil para estimar porque os dois últimos números na
sequência são adicionados para criar o próximo número (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144...).
Isto faz com que a distância entre os números aumente conforme a escala aumenta. Usando
essa escala fica mais fácil realizar a comparação e chegar em um consenso.
Com o tempo, os times vão começar a perceber um padrão nas estimativas à medida
que várias pessoas trabalham com itens com os mesmos valores de pontuação. Por exemplo, 1
Story Point significa que o esforço pode ser entregue rapidamente, em um dia ou menos. Por
outro lado, um item com 13 pontos de história significa que é muito complexo e pode levar várias
até uma semana para ser concluído.
7.3 Exemplo usando Planning Poker
Para auxiliar os times no conceito de estimativas, dentro do Studio Agilidade Centers

usa-se um modelo usando a sequência de Fibonacci e o conceito de tamanho de camiseta. Se
as histórias de usuário não estão suficientemente refinadas tanto na parte de negócio quanto na
parte técnica, tentamos resolver na hora e caso não conseguir sanar as dúvidas, volta-se essas
histórias para refinamento antes de conseguir estimá-las.
Quando a história está preparada para a sprint, verifica-se as incertezas técnicas e
pontua-se com 13 ou 21 pontos de história conforme os critérios da imagem abaixo.
Por fim, quando a história não tem incertezas pontua-se com 1, 2, 5, 8 pontos de história.
Para estimar sempre inicia-se selecionando uma história de baseline. Esta é estimada e depois
usada como referência para as demais.
É importante sempre considerar todas as etapas que têm uma história para ser
considerada como completa de acordo com o DoR, critérios de aceite e DoD, pois deve-se
considerar tanto a etapa de desenvolvimento quanto a etapa de testes e deploy dentro da
estimativa.
41
A forma mais popular para realizar o processo de estimativa dentro de um time é o planning
poker. O planning poker é uma estratégia facilitada pelo SM que busca chegar em uma estimativa
via o consenso do time. A continuação segue o passo a passo de uma sessão de estimativas
usando planning poker, vale ressaltar que este é um processo feito uma história de usuário de
cada vez:
1. Cada membro do time recebe um conjunto de cartas com os valores de uma sequência
(geralmente a sequência de Fibonacci). Cada número dessa sequência corresponde a
uma carta que por sua vez corresponde com um valor da estimativa.
2. Cada membro do time de desenvolvimento seleciona uma carta sem mostrar seu valor
para os demais membros do time.
3. Quando todos estiverem prontos, ou seja, cada um escolheu uma carta, agora é a hora
de mostrar para todos.
4. Caso todos selecionem a mesma carta ou concordem com algum valor, será considerado
esse valor para estimar a história.
5. Se as cartas forem diferentes, os membros discutem e expõem seu ponto de vista do
porquê da escolha. Nesse ponto é importante que o SM proteja as opiniões de todos e
evite que algumas pessoas sejam obrigadas a mudar de carta. Após essa discussão é
feita mais uma rodada (volta-se ao passo 2).
Existem ferramentas virtuais para facilitar uma sessão de planning poker onde cada participante
irá escolher uma carta mostrada na tela do computador. No final de cada rodada o host revela
os valores das cartas para todos ao mesmo tempo. Uma dessas ferramentas gratuitas é o Scrum
Poker Online - Free Tool for Planning Poker (scrumpoker-online.org)
42
43
8. As métricas que podemos usar no Scrum
O objetivo das métricas é acompanhar o progresso do time durante as sprints e refletir

sobre como sua eficiência e eficácia podem ser melhoradas. O intuito das métricas é provocar
reflexão.
“Se você não pode medí-lo, você não pode melhorá-lo”.
Sem métricas, o time tende a atuar de forma reativa diante os problemas. Com as métricas,
as equipes param de reagir e passam a agir com antecedência. Dessa forma, as falhas são
antecipadas e os ajustes podem ser feitos ao longo do caminho.
8.1. Burndown / Burnup
Os gráficos de Burn Up/Down apresentam de forma rápida o trabalho estimado e o

progresso do seu desenvolvimento ao longo de um período, normalmente uma sprint. O
Burndown mostra redução do total de trabalho enquanto o Burnup parte do zero e cresce em
direção ao total de trabalho.
No gráfico de Burn Up/Down, existem dois eixos: o eixo horizontal X, que representa o
tempo de uma sprint em dias, e o eixo Y, que representa o trabalho estimado a ser completado,
geralmente medido em pontos de história (SP). Além disso, o gráfico apresenta duas linhas: uma
é o desenvolvimento planejado ou ideal durante uma sprint, ou seja, qual deveria ser idealmente
o progresso do time considerando o número de SP totais e o número de dias de trabalho. A outra
linha representa o trabalho real do time que deverá ser acompanhado dia a dia.
Como no gráfico usa-se SP, a confiabilidade dele vai depender muito de boas estimativas.
Por isso as estimativas feitas pelo time devem melhorar com o tempo para atingir bons
resultados. A linha de desenvolvimento real sempre deve acompanhar de perto a linha ideal, se
44
ela se desviar muito indica que algo está acontecendo no time. Por exemplo, pode ajudar a
detectar lentidão no processo de desenvolvimento possibilita que o time atue antes de virar um
problema maior.
Segue abaixo vários exemplos de como analisar gráficos de Burndown.
45
Vale ressaltar que os exemplos acima foram reutilizados do treinamento “Scrum na

prática”, treinamento ministrado para os interessados em agilidade dentro de Centers. Caso
tenham interesse, todo mês tem uma nova turma.
46
8.2. Velocity
É a métrica mais básica dentro do Scrum. O objetivo da velocidade é conhecer o ritmo de

entrega do time a cada sprint para identificar, fazer ajustes e melhorar os resultados quando há
variação.
Geralmente são usados Story Points como unidade de medida, mas não existe uma
unidade certa. A velocidade poderá ser medida usando a quantidade de histórias entregues a
cada iteração por exemplo.
Ter uma boa métrica de velocidade vai ajudar a verificar tendências que podem resultar
na previsibilidade do trabalho do time. Você poderá realizar uma estimativa aproximada do tempo
que precisa para o time para entregar um roadmap de produto ou determinada a quantidade de
histórias. Lembre-se que essa estimativa deve ser usada apenas como uma diretriz e não uma
medida exata, por isso não se comprometa nem comprometa o time com datas especificas.
Cuidado com usar a velocidade como métrica de desempenho ou para realizar
comparações entre dois ou mais times. A velocidade de um time sempre é medida para
compará-la com ele mesmo. Ela é reflexo de todo um contexto que envolve unicamente o time.
Para calcular a velocidade de um time simplesmente registre as entregas realizadas em
cada sprint e calcule a média. Tome cuidado com esse cálculo quando o time está sendo
formado, pois as estimativas podem não ser as melhores e isso vai afetar o valor de velocidade.
Como uma boa prática, é recomendado começar a calcular a velocidade de um time novo a partir
da quarta iteração, pois as entregas tendem a se estabilizar.
Velocidade
50
40
30
SP
20
10
0
1 2 3 4 5 6
Sprint
Planejado Realizado Média
Sprint Planejado (SP) Realizado (SP) Média %
1 31 25,00 36,55 81%

2 30 29,06 36,55 97%
3 47 45,00 36,55 96%
4 38 35,00 36,55 92%
5 47 47,00 36,55 100%
6 41 38,26 36,55 93%
Média 39 36,55
47
8.3. Capacity
Capacity é a capacidade do time, desenvolver uma determinada quantidade de tarefas,

em um espaço de tempo.
Um ponto importante é, analisar a maturidade do time: se o time é novo, se está em
constante substituição de colaboradores, sofrendo com o “turnover”. Analise antes de começar
a extrair as informações.
Dê tempo ao seu time para experimentar. Enquanto isso, cocrie dentro do time, atos de
liderança. Comente durante os ritos e reuniões a importância de criar um ritmo sustentável do
time, com intuito de conhecer a capacidade do seu time para realizar as entregas e ter melhor
previsibilidade diante de um projeto.
Nunca use as métricas para cobrar o time, mas sim para extrair informações importantes
que sirvam de suporte para tomada de decisão, bem como melhorar o processo.
Na sprint, é onde temos a oportunidade de inspecionar, adaptar, aprender e fazer
novamente. Com isso, a cada sprint, é fundamental extrair esses dados, e apresentar para o
time. A sua decisão não será mais no “chute”, mas baseada em dados, em estatísticas daquilo
que o time produziu.
Mas qual o prazo para começar a colher as informações do time?
Pode-se dizer que desde a primeira sprint. Porém, para começar a conflitar as informações na
nossa experiência, dentro dos times, é indicado a partir da 3ª sprint, quando o time já está mais
engajado, se conhecem melhor, e está mais integrado ao projeto e conhecendo mais sobre ele.
Você pode usar várias técnicas e variáveis para extrair essas informações.
Veja alguns exemplos:
• Story points (que advém das Story User);

• Horas;
• Tamanho de Camisa (P, M, G),
• Poker planning;
Seja qual for a unidade que o time definiu, você terá que verificar o planejado x realizado,
e conflitar as informações.
No Studio de agilidade, existem vários Agilistas que já trabalharam com técnicas diversas,
mas o Story points é a técnica mais usada.
Veja o exemplo abaixo, quando é utilizado o gráfico de Burnup, para projetar os Story
points daquilo que foi planejado x realizado.
48
Dados:
Dados estes extraídos do time, durante a sprint 01:
Total em Story
Sprint 1 Planejado Realizado Projeção
Points
04/10/2021 157,00 0,0 0,0 0,0
05/10/2021 157,00 2,0 6,5 6,5
06/10/2021 157,00 28,0 26,8 26,8
07/10/2021 157,00 44,0 27,2 27,2
08/10/2021 157,00 70,0 57,7 57,7
11/10/2021 157,00 78,0 61,3 61,3
13/10/2021 157,00 94,0 63,4 63,4
14/10/2021 157,00 107,0 68,0 68,0
15/10/2021 157,00 157,0 71,7 71,7
O Gráfico abaixo, é a plotagem da tabela acima:
Os dados acima usados para plotar o gráfico, pertencia a um time novo, que estava
iniciando suas atividades na primeira sprint. Aqui já é possível realizar algumas análises:
• O time é novo e não conhece ainda sua real capacidade;

• O time levou muito mais pontos para a sprint do que de fato poderia entregar;
• O refinamento não foi legal;
• A sprint foi mal planejada.
A partir dos insights, buscamos conversar com o time, corrigir a rota e tomar a melhor
decisão, sempre buscando a melhoria contínua dos processos.
49
8.4. Scope Change
Mudança de escopo refere-se aos itens do backlog adicionados ou removidos durante uma
sprint. Idealmente, isto não deveria acontecer e o time deveria fazer um bom planejamento para
a sprint com todas as histórias refinadas e priorizadas. Porém, em um contexto real pode
acontecer adição ou remoção de escopo.
As principais razões pelas quais termos mudança de escopo são:
• O backlog não está bem refinado e algumas histórias prioritárias ficam preparadas
após o início da sprint.
• PO entende que uma história não é mais necessária para aquela sprint.
• Aparece uma história com maior prioridade para o negócio e que está alinhada com
objetivo da sprint.
Segue um exemplo desta métrica. Aqui analisa-se a quantidade de SP adicionados ou

removidos em cada sprint e compara-se esse valor com a quantidade total de SP. Dessa forma
calcula-se a porcentagem de mudança de escopo para cima ou para baixo.
Scope Change
Adicionado Removido
60% 50%
40% 33%
20%
0% 0% 0% 0% 0% 0% 0% 0%
0%
1 2 3 4 5 6
-20% -11%
-40% -28%
Planejado Adicionado Variância Removido Variância

Sprint SP SP A SP R
1 29 0,00 0% 8 -28%
2 34 0,00 0% 0 0%
3 16 8,00 50% 0 0%
4 30 10,00 33% 0 0%
5 45 0,00 0% 5 -11%
6 40 0,00 0% 0 0%
50
8.5. Backlog Health
Um backlog que não está preparado pode afetar qualquer time ágil. Uma métrica que você
pode usar para rastrear a saúde do seu backlog é comparar a quantidade de itens preparados
para a próxima sprint com a média de entregas do time.
É uma boa prática ter preparadas histórias o suficiente para desenvolver 2 sprints de
acordo com a velocidade do time. Você pode usar tanto SP quanto a quantidade de histórias
entregues para calcular a saúde do backlog. Por exemplo, a velocidade do time geralmente é de
5,6 histórias por sprint. Após a última reunião de refinamento, a quantidade de histórias
preparadas no backlog é de 8.
Quantidade total de histórias preparadas/Velocidade = 8/5,6 = 1,4 = 1 sprint.
O resultado anterior mostra que no backlog tem histórias preparadas para 1 sprint.
Como mencionado anteriormente, esse cálculo pode ser feito usando pontos de história. Nesse
caso, é preciso estimar as histórias antes da Planning, nos refinamentos.
A métrica pode ser mostrada de forma chamativa, para ter transparência e ser de fácil
consulta. Segue um exemplo abaixo. No caso pode ser colocada uma seta apontando para a
saúde atual do backlog.
51
8.6. Lead Time e Cycle time
Lead Time Cycle Time
Tempo que o item de trabalho leva Tempo que o item fica em uma
do momento em que ele "entra" até determinada etapa do processo
o momento que "sai" do quadro
Kanban
O Lead time e Cycle time não são métricas de avaliação de performance e sim de
avaliação de “processo”, ou seja, deve ser utilizado para melhorar o fluxo. A melhora de
performance é consequência.
O Cycle Time também pode ser analisado com relação a data que ele começa a ser
executado de fato até o tempo de conclusão.
Para contextualizar:
Um exemplo muito prático é, quando fazemos uma solicitação no ifood ou qualquer outra
plataforma. No momento em que a atendente diz que ficará pronto em x tempo, gera uma
expectativa que daqui a x tempo vou receber meu pedido. Este exato momento que a atendente
se compromete comigo até a entrega, é chamado Lead time.
Outra forma lúdica de explicar é o momento que o chapeiro pega os ingredientes, passa
todos eles na chapa e informa para quem vai montar o lanche que já estão prontos para
montagem. Esse ciclo é chamado Cycle Time. É tempo que o produto demora numa determinada
etapa do meu processo, do meu fluxo. E aqui podemos pegar outro processo, a montagem do
lanche e assim por diante.
52
Lead Time
18 16
15
16
14 12
11
12
10
7 7
8 6 66
6
3 3
4 2 2 2 2 22
1 1
2
0
CONFIANÇA LEAD & CYCLE TIME
A confiança serve para descobrir a "probabilidade" de o time entregar uma demanda em

um determinado tempo. O time deve buscar uma confiabilidade de 85% nas suas entregas.
COMO CALCULAR?
• No gráfico de dispersão, acha-se a demanda com maior lead time e trace uma
linha no lead time inferior
• Divida a quantidade de demandas abaixo da linha pela quantidade de demandas
total.
Lead Time
18
16
14
12
10
8
6 Total de demandas: 08
4
Demandas abaixo da linha:
2 05
0
Confiança: 62,5%
53
54
9. Comunicação
Nesse capítulo serão abordados os temas: comunicação não violenta, empatia e rapport.
Existe uma grande diferença entre falar com as pessoas, se comunicar e ser compreendido da
maneira correta. É exatamente esse ponto que será apresentado aqui.
9.1. Comunicação não violenta
Quanto à comunicação não violenta, visto que não somos psicólogos para abordar tão a
fundo o tema, o conteúdo desse capítulo é baseado na abordagem de Marshall Rosenberg,
psicólogo que desenvolveu a técnica apresentada abaixo em seu livro “Comunicação não-
violenta”.
No livro destacam-se inicialmente quatro componentes usados como método de
comunicação e para mediação. Lembrando que esse método foi elaborado nos anos 60, para
intermediar a comunicação em uma época de segregação racial e luta por direitos civis nos
Estados Unidos.
1. Observação
Primeiramente, o psicólogo orienta realmente observar a situação com um olhar
crítico livre de julgamentos. Só após observar toda a situação ou fala, extrair e
compreender o que achou bom e o que não achou bom.
2. Sentimento
Em seguida, é necessário extrair o sentimento que a situação ou fala despertou
em você, como por exemplo, mágoa, raiva, felicidade, entre outros. Após
identificado o sentimento, Rosenberg destaca saber diferenciar o que se sente do
que se pensa ou interpreta.
3. Necessidades
A partir do sentimento que foi despertado, é necessário identificar quais
necessidades estão ligadas a ele. Quando manifestamos nossas necessidades
para terceiros, de forma objetiva, vinculada ao sentimento e fato observado,
Rosenberg destaca que a chance de se ter a necessidade atendida aumenta.
55
4. Pedido
Por fim, através de uma solicitação clara e objetiva, ligada a ações concretas, é
possível fazer um pedido para outra pessoa. Nesse caso, o orientado pelo
psicólogo é utilizar uma linguagem positiva afirmativa, evitando frases ambíguas
ou abstratas para um sucesso maior no pedido.
Exemplo de Comunicação Não-Violenta
Product Owner, quando você grita com a equipe (observação), a equipe pode se sentir
acuada e diminuída (sentimento). O pessoal precisa sentir que está em um ambiente seguro
onde possam expressar todas as suas dores sem ressentimentos (necessidades). Você poderia
tentar evitar gritar com a equipe e manter um tom de voz mais amigável? (pedido).
Para conseguir utilizar essa técnica de comunicação é necessário saber ouvir atentamente
o que os outros expressam, saber analisar a situação, extrair o que tem de bom e o que tem de
ruim, escolher atentamente as palavras que serão usadas, ter empatia na hora de se expressar,
entre outros pontos que podem ser mencionados.
Portanto, pratique a escuta ativa, pratique se colocar no lugar do outro e sobretudo
pratique os quatro componentes elencados acima. A partir disso, com certeza vai perceber uma
evolução grande na hora de se comunicar com o time e vai ter melhor relacionamento com todos,
resolvendo um dos principais pontos de uma equipe, a comunicação.
56
9.2. Rapport
Rapport é uma técnica utilizada para criar uma ligação de sintonia e empatia com outra
pessoa. Este método é muito utilizado na área comercial e é um conceito do ramo da psicologia.
O Rapport ocorre quando existe uma sensação de sincronização entre duas ou mais
pessoas, porque elas se relacionam de forma agradável. Na teoria, três componentes
comportamentais constituem o Rapport: atenção mútua, positividade mútua e coordenação.
É muito importante destacar que pessoas às vezes tentam “forçar” situações para que
ocorra o Rapport, dessa forma tendo um resultado negativo e caricato. Nesse contexto é
necessário reforçar que para se obter o resultado esperado é necessário realmente querer uma
ligação genuína com as outras pessoas.
O Rapport é, fundamentalmente, uma das bases da PNL (Programação Neurolinguística),
ciência que estuda a mente humana e tem por objetivo reprogramar comportamentos
indesejados.
Partindo de toda essa introdução serão evidenciadas algumas técnicas. A mais famosa e
muito utilizada na área de vendas é chamada de espelhamento. Esta técnica consiste em uma
pessoa imitar elementos corporais da outra (postura, gestos, expressões faciais etc.). Um
cuidado grande que deve se levar em consideração ao utilizar essa técnica é que esse “jogo de
imitação” tem que ser gradual e aparentar natural, para não ser confundido com deboche de
características comportamentais do outro.
A reciprocidade é outra forma de criar Rapport, de uma forma simples. Consiste em dar
presentes ou realizar favores sem esperar nada em troca do outro. E por fim, para estabelecer
um senso de pertencimento, camaradagem e confiança, outra forma de criar Rapport é encontrar
interesses em comum que não necessariamente precisam estar relacionados ao ambiente de
trabalho, muito pelo contrário, na maioria das vezes os melhores elos que se criam são com
interesses externos.
57
9.3. Empatia
Empatia é a capacidade de sentir o que outra pessoa sentiria caso estivesse na mesma
situação vivenciada por ela. Em uma linguagem mais comum, “se colocar no lugar do outro”.
Essa capacidade para algumas pessoas já vem inata, mas para outras, é mais difícil e
nesse caso é preciso praticar. Essa habilidade vai te ajudar a criar conexões e vínculos com
outras pessoas, do trabalho até a vida particular. Essa característica está diretamente ligada ao
altruísmo, amor e interesse pelo próximo e desenvolve a capacidade de ajudar os outros.
Um exemplo de empatia seria o caso de uma pessoa da sua equipe mencionar que está
sobrecarregada de atividades. Você pode ter empatia e tentar se colocar no lugar dela para saber
de verdade o sentimento dela. Mesmo que você também esteja sobrecarregado, tente evitar
comparações do tipo: “se você está sobrecarregado, precisa ver eu!”.
Isso pode ser interpretado pela outra pessoa como indiferença pelos sentimentos dela.
Busque utilizar frases positivas, pergunte o que pode ser feito para ajudar, enfim, se coloque no
lugar do próximo e imagine o que você gostaria de ouvir.
Um exemplo de resposta para esse caso seria: “imagino como se sente, também me sinto
assim às vezes. Tem algo que eu possa fazer para te ajudar dentro do que está em meu
alcance/alçada?”
Para finalizar, pode-se dizer que o importante, quando se trata de relacionamento com
outras pessoas, não é muito o que você fala e sim saber ouvir da maneira correta e responder
com frases positivas e principalmente escolhendo as palavras com sabedoria. E para isso
sempre imagine o que você gostaria de ouvir caso os papéis se invertessem e claro, sendo
honesto sempre na resposta.
58
9.4. Gestão de equipes/pessoas
As pessoas dentro do ambiente de trabalho, na maioria das vezes, são diferentes umas
das outras, e nós como Agilistas ou SM temos que conhecer o time, os liderados, a equipe que
trabalha, enfim, conheça as pessoas.
O manifesto ágil diz que devemos cuidar das interações com as pessoas. Fazendo isso e
tornando as pessoas motivadas, o Delivery será potencializado. Como conhecer as pessoas?
Saiba quem são, como são, do que gostam, onde moram, saiba sobre os seus problemas e
motivadores.
Seja um líder servidor! Em um case de sucesso de uma equipe que os agilistas da NTT
Data atuaram, em toda reunião marcada com o time às 13:00 horas, um dos participantes não
podia atender essa agenda. Normalmente o horário do almoço era das 12:00 às 13:00, então os
agilistas não entendiam o porquê das ausências.
Foi então que a pessoa foi chamada para uma conversa, um bate papo informal.
Conversando com ele, foi dito que a esposa trabalhava em outro estado, e ele quem fazia comida
para seu filho de 5 anos, o levava para escola todos os dias, e devido a isso, ele tinha uma
necessidade diferente aos demais enquanto a seu horário de almoço.
Foi analisado junto com ele suas horas semanais, ele disse que entrava uma hora antes
todos os dias, para suprir sua necessidade na hora do almoço, e quando precisávamos dele,
após o horário, ele ficava até mais tarde.
O profissional em questão, era um profissional estratégico no time, conhecedor da área
de negócio, alguém cuja presença nas reuniões era importante. A causa foi abraçada e ajustada
pelo time com apoio dos agilistas. Isso mostra a importância de conhecer as pessoas que formam
o time e fazer ajustes para não impactar o processo. Como bom gestor, é importante acompanhar
o time de perto, oferecer ajuda e conquistar a confiança deles.
Se prontifique, e tenha tudo documentado: solicitação de “Day Off”, férias planejadas
antecipadamente, planeje a compensação de horas extras do time. Faça acordos com o seu
time, mantenha comunicação, em qualquer afastamento/ausência, mantenha o alinhamento,
estreite essa conexão. Considere sempre uma boa comunicação e momentos de feedback, tanto
dos liderados para com o líder, quanto do líder para os liderados. Quando for se ausentar, como
líder, alinhe com o time, crie transparência, comunique.
Seja transparente e fale sempre abertamente com o time, caso necessário, chame em
particular, faça o “face to face” ou “1-1”. Alinhe as expectativas, ofereça ajuda, exerça sua
liderança servidora.
59
9.5. Como redigir um bom e-mail
Ao longo de um projeto, você será a principal fonte de comunicação para o time Scrum e
para stakeholders. Como Scrum master, você irá se comunicar constantemente por meio de e-
mails, mensagens, reuniões ou calls, software de gestão e alguns outros documentos. Em cada
comunicação, você precisa fornecer clareza, acionáveis, verificar progressos, reforçar
informações importantes e dar atualizações de forma efetiva, inclusive múltiplas vezes e de
várias formas.
Um dos meios de comunicação mais usados ainda é mensagens por e-mail. Você vai
precisar se comunicar muito usando esse meio. Seguem aqui algumas dicas que vão ajudá-lo a
redigir um bom e-mail.
Diga claramente o que você quer
Antes de começar a redigir o e-mail, pense no que você quer, quando você precisa disso
e qual é a melhor forma de obter isso que você quer. Algumas dicas podem ser:
• Incluir no assunto do e-mail o que vai ser solicitado.

• Escrever o que vai ser solicitado ou do que se trata o e-mail nas primeiras duas linhas e
indicar especificamente a ação que você quer obter do seu leitor. Por exemplo: uma
resposta a uma pergunta, uma revisão, uma decisão, uma confirmação de agenda etc.
• Escrever frases claras e concisas quando entrar nos detalhes nos parágrafos seguintes.
• Evitar usar muitas siglas ou termos que poderiam não ser claros para algumas pessoas.
Se tiver que colocar alguns, forneça informações adicionais para evitar mal-entendidos.
Mantenha o conteúdo conciso
Resuma o conteúdo e tire qualquer frase que não ajude a definir ou esclarecer aquilo que
você está escrevendo. O leitor deverá ter todas as informações necessárias para não ter
perguntas adicionais sobre aquilo que você quer. Sempre considere seu público, por exemplo,
executivos são pessoas muito ocupadas e não vão querer ler e-mails com muito texto ou clicar
em alguns links externos para ter mais contexto.
60
Estruture sua redação
Isto tem a ver com a estrutura visual do e-mail. O leitor deve ser capaz de encontrar
informação importante com facilidade. Para isso pode usar:
• Marcadores ou bullet points para destacar e quebrar os pontos mais importantes.

• Também pode usar rótulos pois ajudam o leitor a achar facilmente informações
importantes.
• Links com informações complementares direcionadas as pessoas interessadas. Por
exemplo um link que só vai ajudar a um grupo de pessoas a ter mais clareza, mais que
pode ser ignorado para um outro grupo.
Verifique a gramática, pontuação e ortografia
Antes de enviar o e-mail sempre verifique a gramática, a pontuação e a ortografia. Revise

o e-mail várias vezes se necessário para achar e corrigir quaisquer erros.
Em resumo, o e-mail é ainda um padrão para as comunicações dentro das empresas, por
isso é importante simplificar a quantidade de e-mails que você envia. Verifique cuidadosamente
para quem você está enviando um e-mail e, deixe claro o motivo pelo qual você o está enviando.
Certifique-se que o campo de assunto indique claramente do que se trata o e-mail e o que
você precisa. Por exemplo, se for urgente ou precisar de uma resposta, adicione isso no assunto
como um rótulo e reforce isso nas primeiras linhas do e-mail. Se houver uma ação específica
que você precisa do destinatário, escreva claramente para que ele entenda o que se espera dele
e quando.
61
9.6. Gestão do relacionamento com o Cliente
O Cliente é a pessoa mais importante para um consultor. A consultoria existe em função

das necessidades dos clientes, a dor que precisa ser resolvida. Trate bem o cliente e lembre-se,
procure sempre adaptar à realidade, ou à necessidade dele.
Diante de vários cases de sucesso, cita-se um case que chamou atenção. Atuando como
Agilista em um cliente, este pediu ajustar um report. Ele solicitou que a visão do report fosse
alterada de uma unidade "XPTO" para uma visão em "YWPX".
Imediatamente o caso foi levado para o líder direto na consultoria, discutido e após
validação, foi apresentado novamente. Isso teve um peso enorme na companhia, o cliente ficou
muito contente. Esse caso tomou notoriedade dentro do cliente, e a área ganhou destaque dentro
da organização. Uma outra consultoria que estava prestando serviço ao mesmo cliente, havia
negado fazer aquela alteração, por que “ela considerou não ser uma boa prática”.
Resultado, por não se adaptar a necessidade do cliente, a outra consultoria não teve seu
contrato renovado.
Procure sempre ter o melhor relacionamento com o cliente, porém cuide melhor ainda dos
interesses da sua empresa. Se você tem alguma dúvida, dificuldade, percebe que algo está
gerando prejuízo ou desperdício, de alguma forma, comunique imediatamente ao seu líder direto.
Com certeza ele vai te orientar, direcionar qual é a melhor decisão a ser tomada. E se o caso
necessitar de maior atenção, será escalado, e o problema será resolvido, mas o relacionamento
com o cliente, continuará sendo o melhor.
Jamais discuta com o seu cliente. Pratique a escuta ativa, valorize cada fala do seu
cliente. Se ele te ofender, não o desrespeite, procure imediatamente seu líder direto, e
comunique sobre o ocorrido. Já aconteceram casos de pessoas da gestão, por parte do cliente,
serem tiradas da operação, por faltar com respeito a membros da equipe da consultoria.
No final lembre-se, tudo será resolvido. Mantenha sempre a calma, a cautela e a postura
diante do cliente. Dito isso, ressalta-se um dos pilares para o sucesso na gestão do
relacionamento com o cliente: “SEJA FLEXÍVEL E EMPÁTICO”.
62
10. As Boas práticas do Scrum dentro dos times
10.1. Apoio ao P.O.
O apoio ao Product Owner é uma tarefa muito importante no dia a dia do Agilista. É
possível reparar dessa forma se o PO sabe seu papel e responsabilidades ou se ele só está
ocupando o papel para representar o cliente sem saber as responsabilidades do papel, muito
menos como executá-las.
Na maioria das vezes, o PO é simplesmente um porta voz do cliente, o que requer uma
cautela ainda maior por parte do Agilista, o qual deverá entender se a pessoa está disposta a
aprender o papel e suas atribuições ou se está ali somente para “cobrar” o time sem dar abertura
a melhoria.
Em se tratando de cliente, é importante ser colaborativo. Se prontifique, coloque-se à
disposição. Muitas vezes o PO não tem familiaridade com a ferramenta de gestão, ajude o PO,
ensine-o a usar a ferramenta de gestão.
Uma das técnicas de gestão de backlog que pode ser ensinada aos POs é a
Fatiar/Descartar/Priorizar, conhecida como “F.D.P.”.
• Fatiar – Quebre os itens grandes do backlog em itens menores, de tal forma, que
caibam em uma sprint;
• Descartar – Visite e revisite sempre o backlog. As histórias que não fazem mais
sentido, podem ser descartadas. Como o backlog “é vivo”, emergente, dinâmico,
as histórias podem deixar de fazer sentido.
• Priorizar – Ordene seu backlog, crie rotinas de visita ao backlog, e priorize os
itens do backlog, à medida que forem emergindo.
É muito importante, durante o desenvolvimento do produto, a presença do PO e a prática

de suas atribuições. Fazendo uma analogia, o produto é um barco e o PO é o comandante que
deve navegar até o porto seguro para alcançar o objetivo final. O PO deve estar dedicado, focado
e compromissado em fazer esse barco chegar aonde precisa. O papel do Agilista, nesta analogia,
é apoiar e facilitar, trazer o PO para perto do time, fazendo com que o time chegue ao objetivo
comum de forma colaborativa.
Um case que ocorreu em uma operação, mostra claramente o inverso do que se entende
por uma boa prática. O PO foi desalocado do projeto e realocado em outro. Em função disso, o
Lider técnico precisou assumir a função de PO sem ter o conhecimento de negócio adequado do
que geraria mais valor para o cliente final, acarretando assim descontinuação da metodologia
ágil no projeto e a volta do modelo “cascata”.
63
Destaca-se, neste caso, a importância de um bom mapeamento de riscos e documentação

desses pontos. A responsabilidade do "fracasso" do projeto só não afetou o contrato entre
as partes devido a esse mapeamento.
Em contrapartida, será apresentado agora, um case de sucesso que aconteceu em outra
operação. Ao ser identificado a necessidade de maior entendimento de negócio por parte do PO,
no projeto, foi sugerida como boa prática, um PO suplente. Foram designados dois POs que
entendiam profundamente do negócio. Isso acarretou um aumento de performance, pois o
entendimento do negócio por parte do time foi ampliado.
As homologações e validações passaram a acontecer, sempre nas datas agendadas.
Portanto, essa boa prática é indicada e sugerida, para casos parecidos. Ajude o PO a se
organizar, faça sugestões a ele. Isso facilita e muito a criação de uma rotina e melhora o
entendimento de suas responsabilidades.
64
10.2. Agilidade: Seja flexível (Não ser "by the book") “pense ágil”
Agilidade não é mais um contexto apenas de TI. Já faz um tempo que passou a fazer parte
do dia a dia das empresas entrando em diferentes áreas e até na forma de trabalhar como um
todo para melhorar processos e entregar valor com frequência para os clientes, sejam eles
internos ou externos.
Hoje em dia fala-se de um ágil mais leve e adaptado ao mundo atual cheio de incertezas,
mudanças e ambiguidades. Para conseguir mostrar o valor da agilidade para os clientes deve-
se “pensar ágil” e ser flexível sempre que puder. Dentro da agilidade existem muitos frameworks,
métodos, boas práticas e ferramentas que ajudam muito, mas que podem tornar os processos
burocráticos e pesados. É importante saber identificar e analisar as necessidades dos clientes
para chegar a uma forma de trabalho que satisfaça todas as partes. Por isso é importante que,
ao invés de seguir as práticas “by the book” ser flexível adaptando o trabalho e buscando sempre
o melhor relacionamento e satisfação das partes envolvidas.
Quando se fala em pensar ágil, é usar os valores e princípios da agilidade e aplicá-los no
dia a dia. Não é só implementar alguma metodologia ou prática. É internalizar uma cultura de
agilidade nas ações e propostas levadas para os clientes. No primeiro capítulo deste guia foram
mostrados os valores e princípios da agilidade criados em 2001 pensando em um contexto de
software. Existe uma aproximação mais moderna desses valores que pode ajudar a orientar as
ações em outros contextos.
• Torne as pessoas o foco. Para que um produto ou empresa seja bem-sucedido deve-se
fazer com que as pessoas consigam alcançar resultados e atacar aquilo que está
segurando-as. Todas as pessoas devem ser envolvidas, quem compra o produto, quem
usa o produto, quem desenvolve, quem vende, quem financia, quem planeja. Isto não é
mais que promover a colaboração.
• Vise sempre a segurança das pessoas. Você deve gerar um ambiente seguro para todos
e proteger o tempo, a informação enviada e recebida, e a participação das pessoas. Isto
ajuda a promover interações entre todos os envolvidos.
• Experimente e aprenda rápido. Crie pequenos experimentos que sejam seguros. Caso
falharem, que permitam aprender rapidamente. Não espere muito tempo para aprender
com seus experimentos e sempre melhore. Adapte-se às necessidades respondendo às
mudanças e identifique soluções para o cliente.
• Entregue valor a todo instante. O que não é entregue não gera valor. Faça com que as
entregas sejam frequentes e de qualidade quebrando as entregas de valor em pequenas
quantidades. Lembre-se, delivery bem-feito gera oportunidades.
65
Exemplo
Dentro das operações, em alguns clientes, ocorreram vários momentos em que foi
necessário aplicar os valores citados anteriormente e com flexibilidade. Por exemplo, em um
cliente a pessoa que fazia o papel de PO não estava presente nas cerimônias Scrum e nem
acompanhava direito o trabalho do time. Ele só aparecia nas reviews. Neste caso, não podemos
levantar a mão e falar que sem a presença do PO não podemos continuar rodando Scrum ou
algo do tipo. Precisamos verificar alternativas para trazer o PO mais no dia a dia da squad. Por
exemplo, fazer o experimento de criar alguma agenda curta com ele para explicar quais são as
responsabilidades de um PO dentro da squad, o que se espera dele e fazer planos de ação de
acordo com a sua realidade. Assim conseguimos fazer melhorias incrementais pequenas até que
o PO comece a ser mais participativo e se aproxime mais do time inclusive se ele não entra nas
cerimônias, enquanto essa evolução acontece, você precisará trabalhar e se adaptar nesse
cenário fazendo com que a squad continue rodando reduzindo os prejuízos da ausência do PO
enquanto a situação é contornada.
66
10.3. Gestão de riscos
Adaptabilidade é uma skill importante no dia a dia de um projeto, ainda mais quando
falamos de projetos ágeis. Durante todo o processo de planejamento e execução de cada entrega
é importante identificar e ter um plano para os possíveis riscos que possam impactar o projeto
de forma que consigamos adaptar o nosso trabalho.
Um risco é um evento que pode acontecer e afetar um projeto de maneira positiva
(oportunidade) ou negativa (problema). Quando um risco acontece com resultados negativos,
falamos que não é mais um risco e sim um problema e se isso é real e está afetando o projeto
precisa ser resolvido.
A gestão de riscos é o processo de identificar e avaliar os riscos criando planos de ação
para mitigar os impactos antes que eles aconteçam. É um processo recorrente durante qualquer
projeto. Em projetos tradicionais, a gestão de riscos envolve 5 atividades ou etapas principais:
• Identificação do risco: geralmente feito em reuniões voltadas a criar um plano de riscos

para o projeto.
• Análise do risco: Aqui é analisada a probabilidade de o risco acontecer e o impacto que
poderia ter no projeto. Geralmente, estas análises são feitas de forma quantitativa e
qualitativa.
• Avaliação do risco: Uma vez que os riscos são analisados eles precisam ser avaliados
para ter uma lista priorizada.
• Tratamento do risco: nessa etapa são criados planos de tratativa ou resposta aos riscos
priorizados.
• Monitoramento e controle do risco: por fim, os riscos são monitorados e acompanhados
durante todo o projeto.
Dentro do guia Scrum não é mencionada uma prática para a gestão de riscos. Porém, os
riscos devem ser abordados por todas as pessoas envolvidas e a todo momento. Identificar,
analisar, responder ou tratar e monitorar continuamente os riscos devem ser atividades a realizar
nas Dailys, Plannings, refinamentos, reviews e retrospectivas. Estas atividades de gestão de
risco podem ser realizadas de forma orgânica, ou seja, podem surgir naturalmente durante as
discussões em cada cerimônia, ou então podem ser realizadas formalizando uma pauta.
Identificação do risco
Para projetos ágeis, a identificação dos riscos pode ser feita pelo time durante qualquer
cerimônia ou reunião, principalmente durante os refinamentos, a Planning e/ou as Dailys.
67
Análise e avaliação do risco
Devido aos períodos curtos de cada iteração, ter análises qualitativas dos riscos faz mais
sentido e é mais efetivo do que ter análises quantitativas, muito usadas em projetos com
metodologias tradicionais. O objetivo da análise é priorizar os riscos identificados. Isso é feito
durante qualquer cerimônia, inicialmente durante os refinamentos e a Planning.
Tratamento do risco
Em um time ágil, a tratativa dos riscos é realizada pelo próprio time. Eles podem
desenvolver alternativas e ações para mitigar ou conter os possíveis impactos de cada risco.
Existem várias formas em que o time pode tratar um risco:
• Evitar o risco, é a ação de eliminar a causa dele inviabilizando a sua ocorrência. Por
exemplo, uma pessoa sênior vai sair de férias. Vamos chamar uma outra pessoa do
mesmo nível para ajudar o time enquanto a pessoa voltar.
• Aceitar o risco, é a ação de aceitar o impacto do risco pois não temos o que fazer ou
sua probabilidade de ocorrência é muito baixa. Por exemplo, poderemos atrasar a entrega
de uma tarefa, mas o atraso será apenas de um dia e não afeta muito a entrega planejada
para a sprint.
• Controlar ou conter o risco, é a ação planejar atividades para controlar o risco. Por
exemplo, tem uma pessoa que frequentemente entrega com algum atraso, mas ela tem
uma qualidade muito boa. O plano de ação será acompanhar aquela pessoa ajudando a
remover qualquer impedimento para que ela não entregue atrasado.
• Transferir o risco, é a ação de passar o risco para uma outra pessoa, time ou empresa
para que o risco fique com ela. Por exemplo, fazer um outsourcing de um componente pois
o não temos pessoas disponíveis na empresa para entregar a tempo.
Monitoramento e controle do risco
Durante cada cerimônia os riscos deverão ser revisitados pelo time para monitorar seu
status. É importante que essa atividade seja realizada diariamente na Daily fazendo uma
reavaliação de todos os riscos.
68
Quadro de gestão de riscos
Uma boa prática para fazer todas as atividades envolvidas na gestão de riscos é a criação
de um quadro de riscos parecido com um quadro de tarefas ou histórias no Scrum. Dessa forma
todos os riscos são identificados e priorizados recorrentemente e permanecem visíveis para
todos.
A seguir temos um exemplo onde os riscos são classificados nas categorias Mitigar, Evitar
e Aceitar, porém, esse quadro pode ter várias categorias de acordo com os combinados do time.
Por exemplo, podemos ter mais uma categoria transferir como mencionado anteriormente nas
formas de tratar os riscos.
À medida que os riscos vão sendo identificados e priorizados, eles vão sendo adicionados
ao quadro na ordem certa. Para as colunas de Mitigar e Aceitar podemos ter um elemento para
cada risco e ter um subelemento detalhando o plano de mitigação ou de contingência caso o
risco ocorrer. Por exemplo, na figura temos um Plano de mitigação para o Risco 1 e um plano de
contingência para o risco 4.
É importante que tanto o risco quanto os planos de mitigação ou contingência tenham um
responsável e que seja explicito qual que seria o impacto caso o risco aconteça.
Se você gosta de usar post-its pode usar o modelo abaixo. Pode colocar os riscos em post
its vermelhos com a informação relevante e os planos em uma outra cor, por exemplo amarela.
69
70
11. Ferramentas
Neste capítulo serão apresentadas algumas das ferramentas digitais que ajudam a realizar
o gerenciamento do trabalho, a colaborar de forma remota e a comunicar aspectos importantes
em um projeto ágil. As ferramentas abordadas aqui têm sido utilizadas em vários clientes, porém
pode acontecer que um cliente use alguma outra ferramenta. Nesse caso é muito importante se
familiarizar com as ferramentas que o cliente utiliza o mais rápido possível porque você irá usá-
las no seu dia a dia.
11.1. Azure DevOps
O Azure DevOps é utilizado especialmente para realizar a gestão do trabalho,

acompanhamento do Backlog do produto, Backlog da Sprint, bugs/issues e alguns gráficos de
métricas ágeis como Burndown/up, Velocity, entre outros.
A ferramenta permite um acompanhamento de projeto ágil de maneira simples e interativa, com

uma hierarquia de construção bem definida desde criação de um épico, feature até PBIs
(Histórias de usuário ou bugs) e tasks, em forma de cards com possibilidade de configurar
impedimentos e associar com um item específico seja PBI ou tasks.
Dentro do Azure é possível configurar quadros Kanban separados, por exemplo um para
acompanhar o Product Backlog e outro para acompanhar o sprint backlog junto com as tarefas
associadas a cada item, podendo configurar o fluxo de trabalho (colunas) da forma que
considerar melhor para o dia a dia da sua squad.
Os cards que são criados dentro das colunas podem ser arrastados entre elas e configurar
itens de tarefa com pontuações de esforço ou % de realização, dessa forma a ferramenta permite
um acompanhamento mais próximo do que está ocorrendo ao longo do projeto. Para conseguir
acompanhar a evolução do time no dia a dia é recomendado criar a cultura de atualizar board
todos os dias. Caso contrário as métricas geradas pela ferramenta não serão realistas. A
continuação mostra-se um exemplo de board para um sprint backlog com algumas tarefas
71
associadas. Na parte esquerda mostram-se os itens do backlog e depois o quadro kanban com
o fluxo de trabalho para as tasks ou tarefas a serem desenvolvidas.
A ferramenta permite também marcar o tipo de trabalho que cada card representa e o
status do card, desde novo até encerrado, de tal maneira que é possível manter uma
rastreabilidade e filtragem mais simples de cada item do projeto.
72
Outro ponto positivo dessa ferramenta é a criação de dashboards com vários tipos de
gráfico de acompanhamento como por exemplo gráfico Burndown e dados de Velocity da equipe.
Como foi mencionado a precisão dos gráficos vai depender de uma correta configuração dos
cards, das estimativas de trabalho e da atualização do trabalho diariamente por parte do time.
73
11.2. Jira
O Jira é uma ferramenta que permite o monitoramento de tarefas e acompanhamento de

projetos ágeis garantindo o gerenciamento de todas as suas atividades em único lugar. O Jira é
a ferramenta mais popular na hora de realizar projetos ágeis desenvolvida pela empresa
Australiana Atlassian.
O papel do Scrum Master ou do agilista é dar manutenção à ferramenta, ele pode criar um
board, caso não existir, e zelar pelo abastecimento deste com informações, mantendo o board
atualizado diariamente junto com o time.
A ferramenta Jira é bem intuitiva, de fácil compreensão. Se você quiser mexer com ela
para se familiarizar melhor, pode criar uma conta free através do link:
https://www.atlassian.com/software/jira.
A ferramenta ainda possibilita a maioria dos seus recursos em um prazo de 30 dias
conforme mostrado abaixo. Criando a conta free você pode acompanhar os passos que serão
apresentados a continuação.
Cabe ressaltar que o uso da conta free deverá ser pessoal. A NTTDATA não permite o
uso de licenças free para produtos pagos nas operações. Se o seu cliente tiver uma licença do
Jira para o seu projeto por favor solicite o acesso a ferramenta com eles diretamente. Em caso
de dúvidas procure sempre seu mentor ou líder mais próximo.
Como criar um projeto no Jira? Quando você acessa o Jira, pela guia projetos, o software
apresenta a tela abaixo.
74
1º Passo: Criar projeto.

2º Passo: Ao clicar em criar projeto, você deverá escolher qual template deseja utilizar,
Kanban, Scrum ou controle de Bugs.
3º Passo: Após escolher o template, você deverá confirmar, no caso clique em Kanban e
depois usar template.
75
4º Passo: Aqui você pode escolher um tipo de projeto, gerenciado pela empresa (caso a
empresa tenha um administrador centralizado) ou pela equipe, neste exemplo optou-se por um
projeto gerenciado pela equipe.
5º Passo: Nesta etapa, adicione o nome do projeto ou altere o template do projeto caso
você tenha errado nos passos anteriores ou queira alterar antes da criação do projeto. Para o
exemplo o nome do projeto será Projeto Jira 2022
6º Passo: Ainda na tela acima, o Jira mostra uma opção muito importante, a de conectar
a um repositório e outros documentos, por exemplo conexão com confluence.
76
7º Passo: Após clicar em criar projeto no passo anterior, a ferramenta Jira permite a
conexão com uma outra ferramenta, para este exemplo pode-se pular essa etapa.
8º Passo: O projeto é criado conforme o nome Projeto Jira 2022. Para facilitar a
visualização, Jira cria uma sigla para o projeto criado, neste caso PJ2 = Projeto Jira 2022.
Uma vez que o projeto é criado pode-se navegar e verificar as configurações que a
ferramenta possibilita. Por exemplo, no menu de Pessoas aparece a opção de criar uma equipe
ou convidar um membro da equipe para ter acesso ao quadro Kanban, conforme imagem abaixo.
77
Usando o botão “+ Criar item”, podem-se criar Épicos, Histórias ou Tarefas.

Inicialmente pode criar um Épico, lembre-se que um épico é um item muito grande a partir do
qual podem ser identificadas várias histórias de usuário menores.
Rolando com o mouse dentro do card, podem-se configurar mais informações para esse
épico. Atribuir responsável, colocar o time responsável, data limite de entrega, data início, a cor
que vai ter o rótulo do épico (Nesse caso é roxo). Aqui também pode-se anexar documentação
ou algum outro arquivo de importância e até pode ser associado um block, caso exista, conforme
abaixo. Após realizar as configurações, consolida-se usando o botão azul “Create”.
78
Da mesma forma podem-se criar histórias trocando o tipo de item a ser criado, Cada
história pode ter informações como estimativa em pontos, atribuir responsáveis e dentro de uma
sprint planning, pode-se atribuir a uma sprint (Cabe mencionar que uma sprint deve ser criada
com antecedência).
Por fim, da mesma forma pode ser criada uma tarefa, lembre-se que uma história de
usuário poderá ter várias tarefas atreladas. Desta forma, você pode criar várias tarefas e depois
associá-las a uma história.
79
Rolando com o mouse dentro do card, pode-se configurar a tarefa, atribuindo responsável,
nomeando o time responsável e categoria. Aqui também pode ser vinculada uma história a cada
tarefa.
Usando a opção painel do menu lateral, pode-se verificar o fluxo de trabalho. Faça uma
análise do seu fluxo e defina quais colunas do quadro se adequam a ele. Depois tire ou adicionei
novas colunas para representar o fluxo desejado.
Para adicionar uma coluna, basta clicar no Botão “+” em destaque na cor verde e adicionar
quantas colunas você precisar para descrever o seu fluxo.
A opção Backlog (em destaque na cor amarela) do menu lateral permite a criação de uma
sprint, assim como dar início a mesma após uma sprint planning. Uma outra opção em destaque
(cor rosa) ajuda na atribuição de uma história criada a um épico, o qual a história pertence.
Uma outra opção do menu lateral é a criação de relatórios. Esta opção automatiza a
criação de tudo o que tem a ver com gráficos e métricas dentro do projeto. A ferramenta Jira é
capaz de gerar gráficos como Burnup/burndown, Velocidade, CFD (muito útil para olhar a
performance do fluxo de trabalho), Cycle time e frequência de implementação. Conforme nos
mostra a imagem abaixo.
80
Uma das opções mais importantes é a pesquisa avançada de itens, que fica na aba Filtros,
conforme destacado em azul na imagem abaixo.
Na pesquisa avançada por itens, consegue-se buscar informações de forma rápida o que
traz uma economia de tempo considerável. Ao clicar em pesquisa avançada de itens, o Jira, irá
apresentar a tela abaixo.
O filtro “Projeto”, destacado em laranja acima, possibilita a seleção do projeto no qual você
deseja fazer a pesquisa.
O filtro “Tipo”, conforme destacado abaixo em amarelo, permite filtrar o tipo do item, se é
uma história, uma tarefa, um épico, um bug, subtarefa e assim por diante.
81
O filtro “Status”, conforme destacado em verde na imagem abaixo, permite filtrar qual o
estado do item que você está buscando, ou seja, em qual parte do fluxo se encontra.
O filtro “Responsável”, permite saber quais atividades estão atribuídas a um determinado

membro do time, conforme imagem abaixo destacada em rosa:
Existem mais tipos de filtro que você pode explorar para auxiliar na sua busca, nesse caso
use a opção “+Mais” destacada abaixo em azul.
82
Embora você possa estranhar e até achar o Jira uma ferramenta complexa no primeiro
contato, ela é bem intuitiva. Não tenha medo de mexer nela e em caso de dúvidas procure
alguém que posso direcionar. Mais do que a ferramenta em si, o maior desafio como Agilista
será manter os times abastecendo e atualizando a ferramenta todos os dias com informações e
movimentando os cards que são de suas responsabilidades. Sem um compromisso por parte de
todos os envolvidos a ferramenta não será usada com eficácia e eficiência e se tornará complexo
acompanhar o trabalho do time.
E aqui encerra-se a jornada pelo Jira. Procure mais informações no próprio site da
Atlassian e verifique com seu cliente quais são as práticas que eles utilizam na hora de usar a
ferramenta.
83
11.3. Miro
Com a consolidação do trabalho remoto, é necessário conhecer várias ferramentas que
permitem a colaboração de forma digital. Um dos tipos de ferramentas mais usadas são as
chamadas lousas interativas ou quadros infinitos. Embora existam várias opções, as mais
populares são Miro e Mural.
Miro é uma ferramenta digital que nos permite executar diversas tarefas no
desenvolvimento de projetos. Por exemplo, a formulação de mapas mentais e diagramas de
fluxo, planejamento de projetos, pesquisas, criação de esboços e wireframes, workshops e aulas
interativas.
A ferramenta conta com um canvas/quadro infinito e a disponibilização de templates, o
que deixa o trabalho ainda mais prático. Os diversos templates disponíveis podem ser
encontrados no site e podem ser utilizados gratuitamente.
Miro conta com uma opção gratuita limitada em funcionalidades e número de quadros.
Lembre-se que por política da NTTDATA, não podemos usar esse tipo de licenças dentro da
empresa ou com nossos clientes, mas podemos usar de forma pessoal. Caso precisemos usar
a ferramenta verifique a licença com seu gestor ou com o cliente caso ele já use.
Como usar Miro?

Aqui serão mostradas as principais funções da ferramenta de forma resumida. Se quiser
aprofundar seus conhecimentos e ver a maioria das opções que a ferramenta oferece,
recomenta-se acessar o link abaixo:
Tutorial Ferramenta Miro em português pt-br | Quadro Branco Virtual - YouTube
Área de trabalho
Quando você acessa ao Miro, irá interagir o tempo todo com a área de trabalho.
O primeiro passo para começar é se acostumar com os tipos de cursor disponíveis. No

miro existem dois tipos: o cursor de movimentação (mão) e o cursor de seleção (seta preta).
Toda vez que precisar se movimentar pelo quadro, use a mão e toda vez que precisar selecionar
84
e mover um objeto dentro do quadro use a seta. Veja a imagem para entender como trocar de
cursor.
Na área de trabalho existem 4 ferramentas principais: a ferramenta de texto, ferramenta

de post-it, a ferramenta de formas geométricas e a ferramenta de tabelas. Para usar qualquer
ferramenta, só precisa selecionar no menu do lado esquerdo e clicar dentro da área de trabalho
para adicionar o elemento.
Você poderá editar qualquer elemento clicando nele com o cursor de seleção. O Miro vai
mostrar um menu de edição que varia conforme o elemento e vai lhe permitir trocar a cor, o
tamanho da fonte, a formatação da fonte, entre outras opções (Ver imagem do começo desta
seção).
Dentro da área de trabalho também temos a opção configurar um timer que permite
mostrar uma contagem regressiva, especialmente útil quando usamos o Miro como ferramenta
de facilitação.
Templates
Dentro da área de trabalho, você pode selecionar um modelo de template para começar a
trabalhar dependendo das necessidades. Existem mais de 50 templates com objetivos
específicos, por exemplo, existem templates de Kanban, templates para brainstorming, templates
para fazer workshops, diagramas, design etc.
Para adicionar um template na sua área de trabalho basta clicar na opção de templates
no menu esquerdo como mostrado na imagem abaixo.
85
Compartilhamento
Uma outra opção muito importante para usar dentro do Miro é o compartilhamento dos
seus quadros com outras pessoas. No final, você vai usar essa ferramenta para trabalhar
colaborativamente, não é? Para compartilhar basta clicar na opção do canto superior direito
“Share”. Aqui existem 3 opções: compartilhar com um e-mail em específico, compartilhar com
um grupo de usuários e compartilhar com quaisquer pessoas com acesso ao link. Após decidir
qual das 3 opções selecionar, você deverá escolher o nível de permissão que gostaria de dar
para as pessoas, ou seja, se as pessoas poderão apenas ver ou comentar o conteúdo, editar
qualquer parte do conteúdo ou não ter acesso.
86
11.4. A importância de um Powerpoint bem-feito
87
11.5. Conteúdo essencial do Excel
88
12. Gestão da rotina
Estimule o seu time a criar uma rotina, definir uma agenda para foca diária/semanal ou
criar um quadro com as atividades, isso faz toda diferença. Criar uma rotina ajuda a gerir o seu
tempo, maximizar seu dia e sua produtividade. As agendas são importantes, ajudam a ter melhor
controle do seu tempo e consequentemente a melhorar o seu desempenho, sua produtividade
além de promover a disciplina.
Da mesma forma que gerencia-se o trabalho do time, gerencie o seu próprio trabalho. Criar
um quadro para gerenciar suas atividades ajuda a visualizar as atividades pendentes, em
andamento, finalizadas e as atividades futuras.
A gestão da rotina passa por todos desde você até o time em que você atua. Um case de
sucesso em uma operação foi que o time não atualizava suas atividades na ferramenta Jira. Foi
sugerido criar uma rotina, todos os dias pela manhã, primeira coisa a fazer será atualizar a
ferramenta e quem quiser pode até marcar um evento na sua agenda para não esquecer. Da
mesma forma, o Agilista ou SM tem que gerenciar sua agenda semanal e criar eventos para
gerenciar sua rotina.
Cuide da sua rotina pessoal, organize e tenha tempo para você, cuide de você, cuide da
sua saúde. Quando é reservado espaço na agenda para nós, desenvolvemos a criatividade. Ter
um período para meditar, pensar, conversar sozinhos é um gatilho para criatividade. Reserve um
tempo de “Foco”. A técnica de pomodoro auxilia na manutenção desse foco. A técnica consiste
em ter períodos de trabalho e de pausa, por exemplo a cada 25 minutos trabalhados, tenha
intervalos curtos de 4 a 5 minutos para realizar uma pausa. Após 4 períodos de 25 minutos, faça
uma pausa maior de 10 a 30 minutos. A partir deste ponto começa um novo período retornando
ao primeiro passo.
Outra forma de gerenciar sua rotina é criando metas pessoais e metas referentes ao seu
trabalho. De tempos em tempos, verifique se está conseguindo seguir na direção certa, caso não
estiver, corrija a rota, e replaneje em direção a sua meta.
Existem algumas técnicas que ajudam a gerenciar sua rotina na realização de tarefas, um
exemplo disso é a criação de um quadro digital em ferramentas como Miro ou Mural. Para o
modelo presencial, use a velha e boa parede para criar um quadro simples com post-its e separe
seu fluxo de trabalho no mínimo em três etapas: a fazer, fazendo e concluído. Após criar o
quadro, priorize suas atividades usando técnicas de priorização como por exemplo a Matriz
Eisenhower ou matriz GUT.
Finalmente, planeje seu próximo dia de trabalho baseado no seu quadro de atividades.
Não faça múltiplas tarefas ao mesmo tempo, tente terminar uma atividade antes de passar para
a próxima. A priorização ajuda a evitar a vontade de começar outra tarefa e atuar em várias ao
mesmo tempo. Estabeleça prazos para suas atividades e fique atento com as atividades
inesperadas, diga não a uma nova atividade nova quando necessário, sempre mantendo o bom
senso e com argumentos valiosos.
89
13. Leituras recomendadas

13.1. Sprint a Sprint 13.2. Funretrospective
Aprenda com os erros e acertos de um time O principal objetivo desta obra é oferecer as
ágil, acompanhe tudo o que aconteceu atividades e ferramentas necessárias para
Sprint a Sprint e encontre o caminho para a deixar todos à vontade, alinhados e prontos
melhoria contínua! para fazer parte da melhor experiência
possível. Neste livro, os autores reuniram
Ao procurar a junção de uma narrativa
anos de experiência para fornecer
envolvente com muitos materiais teóricos,
atividades simples, diretas, eficazes e
você encontra esse livro. Essa obra vai lhe
envolventes para ter um time alinhado,
mostrar cada passo do caminho que você e
comprometido e colaborativo.
a sua equipe vão percorrer em busca do
sucesso do seu produto!
90
13.3. Lean Inception 13.4. Product Backlog Building (PBB)
Não importa o tamanho ou a área da Times ágeis constantemente encontram-se

empresa, todas se deparam com dúvidas e frente a frente com algumas perguntas
obstáculos na hora de lançar um novo cruciais na hora de desenvolver um produto:
produto: Por onde começar? Onde e por como chegar ao backlog do produto? Como
quem o produto será usado? O que é construir algo que tenha valor? Como
realmente útil para o usuário? Quais dessas encontrar a real necessidade do cliente?
funções são possíveis? Como definir o que é prioridade no primeiro
momento? Como refinar os itens do
Existe uma resposta para todas as dúvidas backlog?
de modo rápido e extremamente eficaz: a
Lean Inception! Movido pelo objetivo de clarificar esse
caminho muitas vezes complexo, Fábio
Após mais de uma década trabalhando com Aguiar desenvolveu o método Product
inceptions, Paulo desenvolveu o método Backlog Building, o PBB. Junto de Paulo
que vai auxiliar você e sua equipe a colocar Caroli, criador do método Lean Inception,
as ideias em ação! eles apresentam um guia prático para quem
deseja construir um produto de sucesso,
criando e refinando o backlog.
91
13.5. Kanban – David Anderson 13.6. Scrum - A arte de fazer o dobro do

trabalho na metade do tempo
Kanban está se tornando uma maneira

popular de visualizar e limitar trabalho-em- Para aqueles que acreditam que deve haver
progresso em desenvolvimento de software uma maneira mais eficiente de se fazer as
e no trabalho em tecnologia da informação. coisas, este é um livro instigante sobre um
Equipes ao redor do mundo estão incluindo processo de gestão que está mudando a
kanban em torno dos seus processos maneira como vivemos. Desde o advento do
existentes para catalisar uma mudança método, já foram registrados ganhos de
cultural e promover melhor agilidade no produtividade de até 1.200%. Jeff
negócio. Este livro responde algumas Sutherland, empreendedor que
perguntas: o que é kanban? porque eu desenvolveu a primeira equipe Scrum, há
gostaria de usar kanban? como identifico mais de vinte anos, apresenta seu método
oportunidades de melhoria e o que devo de maneira brilhante e lúcida.
fazer em relação a eles?
92
13.7. Treinamento de equipes ágeis 13.8. Como fazer amigos e influenciar

pessoas
Com uma frequência cada vez maior, os Ao longo de oito décadas, este livro se
Scrum Masters e os gerentes de projeto tornou a referência quando o assunto é o
estão sendo solicitados a treinar as equipes. desenvolvimento das relações humanas,
Isso exige novas habilidades ― bem como das habilidades sociais e da comunicação
o sutil entendimento de quando avançar ou eficiente.
recuar. Deixar de lado a síndrome de Partindo do princípio de que é preciso se
centralização e controle em prol do interessar genuinamente por aqueles com
treinamento ágil requer um novo mindset. quem interagimos, ele mudou a vida de
Em Treinamento de Equipes Ágeis, você milhões de pessoas, fazendo-as se sentirem
explorará a fundo o papel de agile coach, mais seguras, abertas e confiantes em seus
descobrirá o que funciona e o que não encontros sociais e profissionais.
funciona e aprenderá a adaptar as Com saborosas histórias, exemplos práticos
habilidades poderosas de muitas disciplinas e ótimos conselhos, esta é uma leitura
aliadas, incluindo as áreas de atuação prazerosa e fundamental para quem deseja
profissional de coaching e mentoria. criar bons vínculos, se tornar mais
persuasivo, deixar uma marca positiva e
inspirar os outros com energia e gentileza.
93
13.9. Métricas Ágeis – Raphael Albino

13.10. Comunicação não violenta
Em um meio onde queremos entregar

melhores produtos de software para os Marshall Rosenberg explica de maneira
clientes e usuários, torna-se muito relevante revolucionária os valores e princípios da
incluir em nosso repertório formas de comunicação não violenta, que se baseia
monitorar a eficiência do processo de em habilidades de linguagem e
construção de software. Mas, afinal, por que comunicação que fortalecem nossa
você deve aprender sobre métricas e capacidade de manter a humanidade,
visualizações do processo de mesmo em condições adversas.
desenvolvimento software?
Grande parte dos problemas entre casais,
Em um ambiente ágil, métricas podem pais e filhos, empregados e empregadores,
ajudar a analisar a saúde do seu processo vizinhos, políticos e governantes pode ser
de construção, fornecendo dados históricos amenizada e frequentemente evitada
reais a partir dos quais é possível projetar apenas com... palavras. Porém, saber ouvir
cenários para as entregas, tendo um olhar o que de fato está sendo dito pelo outro e
mais concreto sobre o desenvolvimento e o expressar o que de fato queremos dizer,
atendimento de demandas. embora pareça tarefa simples, é das mais
difíceis.
94

Manual Do Scrum Master

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual Do Scrum Master

Enviado por

Direitos autorais:

Formatos disponíveis

Centers Studio Agile Brasil

Manual do Scrum Master

1. O que é agilidade ___________________________________________ 4

6. Histórias de Usuário _______________________________________ 36

7.3 Exemplos usando Planning Poker _____________________________________ 41

8. As métricas que podemos usar no Scrum _____________________ 44

10. As Boas práticas do Scrum dentro dos times __________________ 63

11. Ferramentas ______________________________________________ 71

12. Gestão da rotina __________________________________________ 89

Essa é uma versão em construção do manual,

As práticas ágeis nos últimos anos tiveram um grande crescimento de popularidade,

1. Product Owner (PO)

3.1. Product Owner

As principais responsabilidades desse papel são:

• Determinar os requisitos iniciais e gerais do projeto;

3.2. Scrum Master

Este papel é o responsável por transmitir os pilares e valores do Framework Scrum. É um

• Ajudar o time e a organização a entender a teoria e prática do Scrum;

3.3. Dev Team

O Dev Team ou Time de Desenvolvimento, é o terceiro papel que compõe o Framework

4.1. Objetivo do produto

4.2. Criação de backlog do produto

Definido o objetivo do produto e identificadas as funcionalidades que precisamos

4.2.1.PBB (Product Backlog Building)

6. PBI: PRODUCT BACKLOG ITEMS

HISTÓRIA DE USUÁRIO – USER STORY

Como mencionado acima, quando se quebra um épico em várias partes menores

Exemplo de US 2: Eu, enquanto usuário do aplicativo, desejo reservar a quadra mais

A partir das histórias de usuário, finalmente chega-se às Tasks, itens técnicos

4.3. Objetivo da Sprint

4.4. Definition of Ready (DoR)

4.5. Critérios de aceite

4.6. Definition of Done (DoD)

Assim como a Definição de Preparado (DoR), a Definição de Pronto (DoD) também é

Se você trabalha ou trabalhou com desenvolvimento de software, já deve ter escutado em

• Está pronto, só falta testar;

Finalmente é hora de falar sobre as cerimônias Scrum. As cerimônias previstas no

5.2. Refinamento de negócio

O refinamento do Backlog, é um processo contínuo onde o Product Owner, de forma

• Realizar o entendimento das histórias do backlog;

• 2º Dia: Validação da linha de pensamento dos cenários de testes baseados nas

5.3. Refinamento técnico

Da mesma forma que é indicado ter um refinamento de negócio, é de extrema importância

Uma sugestão de datas para o refinamento de negócio e para o refinamento técnico a

A Sprint Planning é a reunião na qual é feito o planejamento do trabalho dentro de uma

É indicado que participem da votação todo o time de desenvolvimento, back-end, front-

Chega-se, finalmente, a última cerimônia do Scrum dentro de uma Sprint: a retrospectiva.

5.7. Fluxo de trabalho

5.9. Calendário eventos Scrum

Dentro de algumas operações no Studio Agilidade Centers, usa-se o modelo de calendário

O primeiro ponto a ser levado em consideração é que a US precisa ser independente.

6.1. Modelo ARO

O modelo 3W é o modelo mais popular ou comum para representar um item de backlog

Para facilitar a escrita o modelo 3W utiliza-se o template mostrado acima, que em

Necessito (O quê) efetuar um cadastro de usuário

Para (Por quê) minha identificação

Além de histórias de usuário, cujo objetivo é representar os requisitos ou funcionalidades

O processo de estimar, principalmente em projetos de software, é a forma de prever, por

Fácil, não é? Comparando as alturas dos edifícios da imagem em relação ao solo, o

• Risco (risco de não acontecer de acordo ao planejado)

7.3 Exemplo usando Planning Poker

Para auxiliar os times no conceito de estimativas, dentro do Studio Agilidade Centers

Poker Online - Free Tool for Planning Poker (scrumpoker-online.org)

8. As métricas que podemos usar no Scrum