Treinamento Agile Scrum Foundation - Trainning-Vfinal

1
Agile Scrum Foundation

ASF
PRÉ-REQUISITO
Não há pré-requisito para realizar o

curso e a prova de certificação.
Entretanto, para melhor aproveitamento

do curso, é importante que o(a)
participante tenha conhecimento básico
de TI, gestão de projetos e/ou
desenvolvimento de produtos em área de
negócio (Marketing, Vendas etc.).
2
PÚBLICO-ALVO
▪ Pessoas que desejam estar atualizadas;
▪ Gerente de projetos;
▪ Gerente de Produtos;
▪ Profissionais de TI;
▪ Desenvolvedores de Software;
▪ Gerente de Serviços de TI;
▪ Gerente de Negócio
▪ Analista de Negócios
▪ Analista de Processos
3
OBJETIVOS DO CURSO
TEORIA e MINDSET
Apresentar os conceitos básicos de abordagens ágeis e fixá-los com dinâmicas
PRATICA E FERRAMENTAS
Apresentar os conceitos de agilidade, alinhando a técnica com a sua aplicação
prática.
SUBINDO O NIVEL
Introduzir a prática de gestão global ágil com múltiplas equipes e gestores com
a visão de programa e portfólio.
4
OBJETIVOS DO CURSO
Subindo o Nivel
Práticas e
Ferramentas
Teoria e
MindSet
5
DIÁLOGO
O que colaborou para que os projetos em que vocês participaram

tenham sido bem sucedidos?
O que colaborou para que os projetos em que vocês participaram

tenham sido mal sucedidos?
6
ALGUNS NÚMEROS
- Apenas 26% dos projetos de software tradicionais têm sido bem

sucedidos nos últimos 23 anos, segundo o Standish Group;
- 8% dos projetos ÁGEIS tem falhado nos últimos anos.
- Investimento em TI atingiu US$ 3,7 trilhões em 2018, segundo Gartner
7
CHAOS REPORT
Standish Group 2018
8
CHAOS REPORT
Standish Group 2018
9
DIÁLOGO: “BALA DE PRATA”
Por que, mesmo com a adoção de abordagens ágeis, ainda há projetos que falham?
10
DIÁLOGO: “POR QUE PROJETOS ÁGEIS FALHAM?”
Fonte: VersionOne, Agile Annual Report, 2019
11
DIÁLOGO: ANTES DE PROSSEGUIR...
Você diria que o “AGILE” é uma a metodologia?
“O termo “ágil” data de uma reunião de 2001, na qual eu e 16
...
outros líderes de desenvolvimento de software escrevemos o que
se tornou conhecido como “Manifesto Ágil”. Nele declaramos
os seguintes valores:
- pessoas e interações mais que processos e ferramentas
- produtos que realmente funcionem mais que documentação
abrangente;
- Colaborar com os clientes mais do que negociar contratos;
- responder às mudanças mais do que seguir um plano.
Scrum é a estrutura (framework) que eu construí para colocar

esses valores em prática. Não existe uma metodologia.”
Jeff Sutherland, cocriador do SCRUM, no seu Livro Scrum - a arte de fazer
o dobro do trabalho na metade do tempo, pg.15
12
METODOLOGIA vs FRAMEWORK
Metodologia: é um conjunto de métodos, padrões e regras

que devem ser seguidos.
“Framework”: é uma estrutura, um conjunto de conceitos e

técnicas, totalmente adaptável. O “como fazer” depende do
contexto.
13
METODOLOGIA vs FRAMEWORK
Então, um Framework pode fazer parte de uma metodologia ou

de um método?
Sim! As abordagens ágeis são mais um hábito do que um processo.

Logo, adaptável e flexível em qualquer metodologia ou método.
14
15
MÓDULO 1
Tradicional x Ágil
O escopo do produto, no método tradicional, No Ágil, o escopo do produto é realizado

é realizado no começo já determinando o que por partes, em entregas incrementais
será desenvolvido do inicio ao fim onde permite o cliente a participar de
todo o processo possibilitando pequenas
entregas do produto.
16
ESTABELECENDO A CULTURA ÁGIL
❑Alinhamento entre envolvidos;
❑Linguagem comum;
Transparência ❑Clareza nas execuções e aceitação;
❑Definição de Pronto comum entre executores e demandantes
Inspeção ❑Inspecionar artefatos produzidos;

❑Certificar que as produção estão em conformidade com o solicitado;
❑Validar o conceito de pronto em todos os itens terminados;
Adaptação ❑Analisar o grau de impacto de possíveis desvios dentro do plano;

❑Implementar ações de contramedidas com foco em manter a entrega de valor real ao demandante;
17
ISSO MELHORARIA SE O CLIENTE...
1. Recebesse entregas periódicas agregando valor ao negócio
2. Pudesse flexibilizar os requisitos de acordo com a necessidade do produto
12 Princípios Ágeis
3. Verificasse o software funcionando em poucas semanas
4. Tivesse pessoas de negócio e desenvolvedores trabalhando em conjunto
5. Construísse projetos em torno de indivíduos motivados
6. Considerasse comunicação verbal o meio de comunicação mais eficiente
7. Medisse o progresso do produto com o Software funcionando
8. Tivesse um time comprometido e não só envolvido com o sucesso
9. Não abrisse mão da excelência técnica e bom design dentro do tempo produto
10. Mantivesse a simplicidade como “pedra fundamental”
11. Tivesse equipes auto-gerenciaveis
12. Trabalhasse em conjunto com o time para melhoria continua
18
MANIFESTO ÁGIL
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos
e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas

Produto em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda."
http://agilemanifesto.org
19
Frameworks e Abordagens Ágeis
▪ Scrum
▪ Método Kanban
▪ XP (Extreme Programming)
▪ DSDM
▪ Crystal
▪ FDD
▪ Outros
20
Frameworks e Abordagens Ágeis
Source: VersionOne Annual State of Agil Report, 2019

carlosaugusto.padilha@gmail.com
https://www.linkedin.com/in/carlospadilha
O QUE É SCRUM ?
É uma estrutura, um arcabouço que define papéis, eventos, artefatos e regras para o
desenvolvimento de produtos complexos e adaptativos, valorizando a entrega frequente
e incremental de valor para o cliente;
Scrum trata de comportamento, de atitude, e não de um processo, de adotar nova

forma de trabalho.
22
O QUE É SCRUM ?
A inspiração do Scrum veio de resultados positivos de empresas como: 3M, XEROX,
HONDA, HP
Instabilidade Embutida
Sobreposição nas fases de Desenvolvimento
Auto-organização nas equipes
Aprendizado Múltiplo
Controle sutil pela alta gerência

Transferência organizacional de aprendizado
23
PARA QUE É USADO ?
• Video games
• Software comercial
• Sistemas para suporte à vida
• Desenvolvimento interno
• Sistemas para controle de satélites
• Desenvolvimento contratado (terceirização)
• Websites
• Projetos de preço fixo
• Software para handhelds
• Aplicações Financeiras
• Telefones celulares
• Aplicações certificadas pela iso 9001
• Aplicações para redes
• Sistemas embarcados
• Aplicações de ISV (Independent Software
• Sistemas disponíveis 24x7
Vendors)
• Pesquisa de inovação
• Algumas das maiores aplicações em
produção
24
25
MÓDULO 2
SCRUM – PILARES E VALORES
Transparência Inspeção Adaptação
EMPIRISMO
Abertura Coragem Respeito Foco Comprometimento
carlosaugusto.padilha@gmail.com
https://www.linkedin.com/in/carlospadilha
10
OS PAPEIS NO SCRUM
27
28
OS PAPEIS NO SCRUM
• Product Owner (PO)
Responsável por garantir o ROI (Retorno de Investimento);
Responsável por conhecer as necessidades do(s) cliente(s);
Responsável pelo gerenciamento do Backlog do Produto.
• Scrum Master
Responsável por orientar e garantir o uso de Scrum
Responsável por remover os impedimentos do time;
Protege/blinda o time de interferências externas.
• Time de Desenvolvimento
Definir e comprometer-se com metas das iterações (Meta da Sprint, Sprint Goal);
Autogerenciamento;
Entregar produto de formar frequente e incremental, com qualidade e valor para o
cliente, segundo critérios definidos pelo PO.
ESTRUTURA DO SCRUM
Product Owner Scrum Master Time
29
ESTRUTURA DO SCRUM
• O Product Owner (PO) define a Visão do Produto. Esta Visão é o que
representa sua necessidade, é o que deve ser satisfeito ao fim do
desenvolvimento;
• Para definir esta Visão, o PO colhe informações com os stakeholders
(partes interessadas), como clientes, usuários final, time, gerentes,
stakeholders, executivos, etc.;
30
ESTRUTURA DO SCRUM
• O PO cria uma lista inicial de necessidades que precisam ser produzidas

para que a Visão do produto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog.
31
ESTRUTURA DO SCRUM
• O PO cria uma lista inicial de requisitos que precisam ser desenvolvidos
para que a entrega da Visão do Produto seja percebida como algo de
valor para o cliente;
• Esta lista de requisitos é chamada de Product Backlog;
• O Scrum Master deve auxiliar o PO na elaboração desta lista, em
especial no detalhamento, priorização e refinamento no momento
adequado.
32
ESTRUTURA DO SCRUM
• No início de cada iteração (Sprint) o time deve se reunir para realizar a

Planning Meeting;
• Nesta reunião o timeScrum realizará o planejamento do que será
entregue ao final do ciclo da Sprint.
33
ESTRUTURA DO SCRUM
• Na primeira parte da Planning Meeting o PO deverá: apresentar para o
time a meta desejada da Sprint e os Itens mais prioritários do Product
Backlog – O que Fazer;
• Na segunda parte da reunião, o time de desenvolvimento deve estimar
a complexidade dos Itens apresentados e selecionar o que acredita que
possa ser feito durante a Sprint. Essa lista selecionada chama-se Sprint
Backlog – Como Fazer;
• O facilitador desta reunião é o Scrum Master, e outras partes
interessadas podem participar, como Especialistas técnicos, Analistas de
Negócios, gerentes funcionais etc.
34
ESTRUTURA DO SCRUM
• Na segunda parte da Planning Meeting o time deverá colher mais
detalhes dos Itens e decompô-los em tarefas, gerando assim o Sprint
Backlog, considerando a Definição de Preparado (DoR – Definition of
Ready);
• Para isso pode ser necessária a ajuda de Especialistas de Domínio;
• Após a decomposição, cada membro do time deve selecionar as tarefas
que deseja executar durante a Sprint (sempre negociando com o time) e
estimá-las em horas;
• O facilitador desta reunião é o Scrum Master.
35
ESTRUTURA DO SCRUM
• Durante a execução da Sprint, valem quaisquer boas práticas (de
engenharia de software ou outras) definidas para o produto;
• O Scrum Master, através da sua capacidade de liderança e colaboração,
facilita o trabalho do time removendo os impedimentos encontrados e
garantindo a boa aplicação do Scrum;
• Durante a Sprint, o time pode sentir necessidade de consultar
Especialistas de Domínio, ou mesmo o Product Owner (PO);.
36
ESTRUTURA DO SCRUM
• Diariamente o time realiza uma reunião de até 15 minutos (Daily
Meeting) na qual cada membro deve responder:
• O que fiz desde a última reunião para atingir a Meta da Sprint?
• O que pretendo fazer até amanhã para atingir a Meta da Sprint?
• Tive (estou tendo) algum impedimento?
• Através desta reunião o time ganha visibilidade de como está o caminho
para a meta e planeja o dia seguinte de trabalho;
• O Scrum Master novamente é o facilitador, e deve lembrar que a
reunião é para o time de desenvolvimento e não para ele ou outra
pessoa, independente do cargo ou hierarquia.
37
ESTRUTURA DO SCRUM
• Ao final da execução da Sprint deve ser realizada a Review Meeting,
reunião que tem como propósito apresentar o que foi feito e receber
feedback, do Product Owner (PO) e outras partes interessadas;
• O time é quem realiza a apresentação, que deve ser feita com o objetivo
de mostrar o incremento de produto. Não é reunião de status, e não é o
momento de apresentar justificativas do que não foi entregue;
• Product Owner (PO) avalia se a Meta da Sprint foi alcançada: DoD;
• Product Owner (PO) faz anotações que poderão se tranformar em novos
Itens para o Product Backlog.
38
ESTRUTURA DO SCRUM
• O último evento formal de uma Sprint é a Retrospectiva;
• Reunião de lições aprendidas, facilitada pelo Scrum Master, na qual o
time deve avaliar: o que foi bom na última Sprint? O que deve ser
melhorado em termos de processos, relacionamento? Quem está no
controle?
• Esta reunião representa o espírito de Inspeção-Adaptação dentro do
Scrum;
• É uma reunião do time Scrum, ou seja, todos os membros, incluindo o
PO, devem participar.
?
39
ESTRUTURA DO SCRUM
• Sessões de Refinamento (Refinement): reuniões de trabalho conduzidas
pelo PO, com a participação de membros do time de desenvolvimento,
para refinar itens do Backlog do Produto que deverão entrar na próxima
sprint;
• Reuniões podem ser facilitadam pelo Scrum Master;
• O total de sessões não deve ultrapassar 5~10% do tempo total da
iteração (sprnt);
• Não é um evento formal previsto no Scrum Guide, é uma boa prática.
40
O PAPEL DO SCRUM MASTER
Em abordagens tradicionais, projetos complexos de software (soluções modulares, monolíticas, como ERPs, CRMs,
Supply Chain) são sequenciados em fases, com entregas que podem varia de 6 a 18 meses.
O SCRUM altera essa dinâmica, propondo entregas frequentes e incrementais, valorizando seus 3 pilares:
Transparência, Inspeção e Adaptação.
Isto permite ao time e à organização, maior visibilidade, expondo impedimentos e limitações, ou seja, expondo o que está
por trás da “janela suja”.
O trabalho do Scrum Master é identificar e priorizar resolver estes impedimentos, ajudar a organização a superá-los,
gerenciando investimentos e garantindo o seu retorno.
41
UM SCRUM MASTER DEVE...
➢ Remover a barreira entre desenvolvimento e cliente

➢ Ensinar o cliente a maximizar o ROI e atingir seus
objetivos com o uso correto do Scrum
➢ Melhorar o dia-a-dia dos membros do time facilitando
a criatividade e fortalecimento do grupo
➢Priorizar os impedimentos e combatê-los
➢Auxiliar o Product Owner (PO) com o Product Backlog
➢Garantir o uso do Scrum
➢Facilitar reuniões
42
A VIDA DE UM SCRUM MASTER
➢ Assegure-se que todo mundo está fazendo o que se comprometeu a fazer
➢ Determine onde o Scrum está, comparado com onde poderia estar e atualize
seu próprio Product Backlog
➢ Trabalhe no Product Backlog com o Product Owner (PO)
➢Zelar pelo bom funcionamento ágil em toda sua essência
43
Autoridade do Scrum Master
O Scrum Master por meio de treinamentos, coaching, removendo impedimentos e
solucionando problemas poderá fazer que o Scrum seja bem entendido e
aplicado.
Não é um gerente do time Scrum. Mas é papel do Scrum Master orientar e motivar
o time a seguir o Scrum, sem obrigar a time a realizar ações, pois em projetos
ágeis os times são multidisciplinares e auto-organizáveis.
O Scrum Master tem como característica ser um líder servidor, sem impor nada ao
time.
44
Atributos de um bom Scrum Master
Responsabilidades:
▪ Humildade;
▪ Colaboração;
▪ Comprometimento;
▪ Influência;
▪ Conhecimento.
45
Motivando e Desafiando a Time
É necessário que o Scrum Master entenda a dificuldade das

atividades que o Product Owner (PO) repassa para time em
diferentes momentos do desenvolvimento do produto;
Esse repasse deverá ser realizado fazendo uso de CNV

(comunicação não violenta), sem tom de ameaça ou de punição. O
Product Owner (PO) tem o dever de explicar a importância das
atividades e a importância de cada membro para a conclusão das
mesmas.
46
Abordagens Tradicionais e Scrum
Em cenários em que convivem abordagens tradicionais e o Scrum, é inevitável
que haja problemas. Nesses casos, é importante saber quais são as atitudes
adequadas que um Scrum Master deve tomar, ou saber como amenizar o
tamanho dos impedimentos.
Realizar análise em detalhes;

Não permitir que haja conflito nos modelos de gestão;
Descobrir qual é o modelo de gestão que mais se encaixa;
Criar pequenos processos em vez de encurtar um grande processo;
Estabelecer uma forma do Scrum apoiar o método tradicional;
Adequar da melhor maneira as práticas ágeis, qualquer que seja o processo.
Exemplos de boas práticas de desenvolvimento de software:
▪ Integração contínua
▪ Testes automatizados
▪ Refatoração
▪ Programação em pares
▪ Desenvolvimento paralelo
47
Coaching e Treinamento
Treinar e formar para o conhecimento mais aprofundado do Scrum.
Informando a todos que o Scrum é diferente da metodologia tradicional.
▪ Determinar metas para todos os Scrum Masters de capacitação;

▪ Determinar praticas do Scrum para os membros do Time Scrum;
▪ Informar sobre o conceito e filosofia ágil, não só para a área de TI, mas para a
organização como um todo, incluindo os clientes
48
PMO – Escritório de Projetos
O Escritório de Projetos pode ser um grande aliado para a mudança do Scrum, pois
também defendem uma metodologia, assim cooperando para implementação do ágil em
toda a organização.
Uma das grandes razões para resistência de transição de uma empresa que utiliza PMO
para o Scrum, é que o Scrum vai contra o Método Cascata;
49
Programa de Treinamento
O Scrum Master deve ser o influenciador sobre os envolvidos na transição para o ágil.
É importante a empresa identificar um coach que tenha habilidades e com preparo adequado para assumir
essa posição, ou ser um orientador para outros membros escolhidos para esta função por meio de
treinamentos e qualificações.
Realizar um programa de treinamento;

Cuidar da preparação do programa de treinamento, se será realizado por um terceiro (externo) ou por ele
mesmo;
Viabilizar coaching para pequenos grupos.
50
Coaching e Treinamento Interno
Oportunidade para uma time que tem o pleno entendimento da metodologia ágil
passar o conhecimento para outras que ainda necessitam de apoio, através de uma
pessoa que tenha essa expertise sendo designada como coaching.
Vantagens de adotar coaching e treinamento interno:
▪ Equipes com conhecimento não precisa ser separada;

▪ Coaches escolhidos com critério;
▪ Movimentação livre dos coaches entre as equipes.
51
Aprendizagem
Mesmo após a time ter estar com pleno entendimento do Scrum, comprometida com os resultados e
diminuir a dependência dos especialistas é importante os membros procurarem novas formas de
aprender e de compartilhar os conhecimentos proativamente.
Algumas aprendizagens ocorre naturalmente outras procuram intencionalmente, se preocupando com o

agora.
Cabe ao Scrum Master incentivar a time a procurar esse conhecimento através de:
▪ A mentalidade do time estar pensando sempre em aprender;

▪ Os membros tem que ter a possibilidade de compartilhar o conhecimento;
▪ Liderança cooperando mostrando a time a importância do aprendizado constante;
▪ Ter desafios que motivem a time a sempre procurar por aprendizagem.
▪ Ambiente favorável para aprender.
52
UM PRODUCT OWNER DEVE...
➢ Definir a visão do produto (product vision);

➢ Gerenciar o retorno de investimento (ROI);
➢ Apresentar ao time os requisitos necessários para a entrega do produto;
➢ Priorizar cada requisito de acordo com seu valor para o negócio/cliente;
➢ Gerenciar a entrada de novos requisitos e suas priorizações;
➢ Planejar entregas (releases);
➢ Atuar como facilitador quando mais de um cliente estiver envolvido no produto;
➢ Garantir que Especialistas estejam disponíveis para o time;
➢ 50% do tempo de um product owner deve ser gasto para entender o negócio do
cliente enquanto os outros 50% devem ser gastos passando esse conhecimento para
o restante do time.
53
MÓDULO 3
ARTEFATOS DO SCRUM: 3
1) Backlog do Produto, 2) Backlog da Sprint e 3)Incremento de produto potencialmente entregável
Método Tradicional Time Scrum
▪ Não dedica muito tempo na fase de

▪ Inicialmente é realizado a coleta de
levantamento para requisitos não
todo os requisitos do produto;
prioritários;
▪ Aguarda até que toda a especificação
▪ Inicialmente levanta os requisitos em
do produto seja feita;
alto nível, e sucessivamente, vai
especificando-os;
▪ Considera que todos os aspectos que
ainda estão sem definição seja
▪ Tudo que é coletado é documentado
encontrado.
no artefato Backlog do Produto;
▪ Backlog do Produto é a lista dos

requisitos priorizados
55
Backlog Do Produto
▪ Dinâmico, pois é permitido adicionar e remover itens, repriorizar conforme a

necessidade do cliente;
▪ A mudança constante que ocorre no Backlog do Produto faz dele um artefato

vivo, com as evoluções no produto que acontece a cada Sprint;
▪ O Backlog do Produto nunca será algo completo;
▪ O Product Owner (PO) é o responsável ;
▪ Importante que pode ocorrer cenários onde existam mais de um Time Scrum
atuando em um mesmo produto, no entanto deverá existir apenas um Backlog do
Produto.
56
Características do Backlog
Não é exigido que o Backlog do Produto seja descrito com Histórias de usuário de Usuário, no
entanto essa prática é comum e muito incentivada.
É ordenado pelas histórias de usuário de maior valor no topo da lista, e as de menor valor por
último.
Aconselha-se não gastar muito tempo com as histórias de usuário de menor valor, pois é
possível que não sejam feitas no futuro.
Uma boa prática utilizada no Backlog é a técnica INVEST, acrônimo: Independent

(Independente); Negotiable (Negociável); Valuable (aquele que gera Valor); Estimable
(Estimável); Small (Pequeno); Testable (Testável).
57
Características do Backlog
A estimativa dos itens do Backlog do Produto é de responsabilidade do Time de

Desenvolvimento.
As outras atividades fica na responsabilidade do Product Owner (PO) que são:
▪ Dono do Backlog do Produto;

▪ Elaborar os itens;
▪ Priorizar os itens que geram valor;
▪ Assegurar que os itens que compõe o Backlog estejam claros e objetivos para o time;
58
NIVEL CERTO DE PRIORIZAÇÃO
59
PRODUCT BACKLOG BUILDING - PBB
60
61
IDENTIFICAÇÃO
Comece batizando o produto a ser desenvolvido.
PROBLEMAS
Formule uma dinâmica que auxile as partes interessadas a expor os
principais problemas existentes que elas esperam que sejam
solucionados com o produto. Descreva-os cada um em post-its ou de
outra forma
q
que valorize a gestão visual.
EXPECTATIVAS
Alinhe as expectativas das partes interessadas. Importante que cada
problema se relacione com uma expectativa.
PARTES INTERESSADAS
Crie Personas, comece a personificar os usuários, com papéis e
responsáveis envolvidos no negócio. Dê um nome/apelidos, defina
suas principais atividades e/ou objetivos no contexto do negócio que o
produto pretende atuar, alinhando as expectativas da Persona com as
do passo anterior.
62
AREAS DE NEGÓCIO
Agrupe as personas conforme a área de negócio que atuam. Isso
auxilia o PO a ter uma visão de impacto no negócio e, por
consequência, a começar a priorizar.
ATIVIDADES DE NEGÓCIO
Descreva as atividades de negócio necessárias para cada área listada
anteriormente, associando a parte interessada já identificada.
Detecte cada atividade por sua sequência cronológica, mapeando da

esquerda para a direita, com uma breve descrição, alinhando os
problemas (pontos de melhorias) e as expectativas (pontos que se
espera chegar)
FUNCIONALIDADES
Comece a estratificar as atividades de negócio, gerando as funcionalidades.
63
A ENGENHARIA DO PRODUCT BACKLOG
64
STORY-WRITING WORKSHOP
65
• Story-Writing Workshops são reuniões que
Incluem colaboradores, usuários, cliente e product owner;
• Durante este workshop os participantes escrevem a quantidade de

histórias de usuário que
conseguirem;
• Prioridades não são associadas;
• Bons workshops combinam os melhores elementos de brainstorming

e prototipação de desenho;
66
NEM TUDO É User Story...
User Story
User Story User Story
EPICO
TEMA
TEMA
User Story User Story User Story
User Story User Story User Story User Story
67
HISTÓRIAS DE USUÁRIO (User Stories)
Independente
Negociável
Valiosa para usuários e cliente
INVEST
Estimável
Small (pequena)
Testável
68
Quem?
Como um <PERFIL> eu posso/gostaria/devo
<FUNCTION> para <VALOR AO NEGÓCIO>
O que?
Como um INSTRUTOR eu devo APONTAR A LISTA
DE PRESENÇA DOS ALUNOS para MANTER AS
INFORMAÇÕES DO TREINAMENTO ATUALIZADAS
Por que?
69
STORY-WRITING WORKSHOP (Exemplo)
Sua empresa é uma fabrica especializada em construção de aeronaves. Seu cliente, a força aérea, por intermédio de
um representante, entrou em contato e solicitou propostas para um novo produto de aeronave.
A aeronave deve possuir 12 janelas, cabine, o logotipo da empresa de fabricação, recursos para passageiros e
tripulação.
70
Como um piloto eu posso realizar check-up on-line da Como um passageiro eu posso ter acesso à um tablet para
aeronave para acelerar os procedimentos de decolagem. visualizar as informações que necessito
Como um empresário da aviação eu gostaria de uma aeronave Como um membro da tripulação eu devo ter facilidade de
com maior autonomia de voo para que o tempo em solo fosse locomoção dentro da aeronave para melhor servir aos
menor passageiros
71
CRITÉRIOS DE ACEITE
Todo produto nasce com um grupo de objetivos.
Sendo assim é importante elaborar critérios para o atendimento desses objetivos.
No Scrum, isso é realizado de forma colaborativa entre o Product Owner (PO) e o Time de Desenvolvimento, que
devem encontrar formas para garantir a entrega de valor ao cliente, através do Product Owner (PO) (Proxy).
Para isso, fatores comuns nas critérios de aceite possui:
▪ Escopo (ou Roadmap de produto);

▪ Plano de Projeto (Project Planning);
▪ Orçamento;
▪ Qualidade.
Terá situações que todos os fatores acima não será atendido. Nesses casos as condições são alteradas.
Por esse motivo que o Planejamento de Liberação e as condições são interativos.
A condição de satisfação é definido como um teste de aceitação de alto nível que se tornará concreta após a
história de usuário do usuário estiver completa.
72
OBSERVAÇÕES (User Stories)
• Uma característica marcante de projetos/serviços baseados em “Histórias de

usuário” é que clientes e usuários estão comprometidos no produto em toda sua
duração;
• “Histórias de usuário” devem ser compreensíveis por todos: usuários, cliente e

time de desenvolvimento;
• “Histórias de usuário” evitam “interpretações” de documentação
73
TESTES DE ACEITAÇÃO
Uma das melhores formas de se expressar em uma história de usuário alguns dos detalhes
discutidos entre cliente (Product Owner (PO), Especialista de Domínio, ...) é a escrita de
Testes de Aceitação;
• Voo da aeronave entre duas

principais rotas, analisando
Como um empresário da aviação eu combustível gasto x restante deve
gostaria de uma aeronave com ter consumo abaixo de 50%;
maior autonomia de voo para que o
tempo em solo fosse menor • Tempo de recarga (combustível e
mantimentos) da aeronave em solo
deve ser entre 15-20 minutos;
74
TESTES DE ACEITAÇÃO (REGRAS)
• Escrever Testes de Aceitação antes de
Iniciar o trabalho ;
• O cliente é quem deve especificar Testes de

Aceitação;
• Teste DEVEM fazer parte do processo;
• Automatização de Testes de Aceitação

• Ex.: Script de Testes
• Alguns tipos de testes

• Teste de Unidade;
• Teste de Usabilidade;
• Teste de Performance;
• Teste de Stress;
75
Estimando a Complexidade
O esforço estimado para os itens do Product Backlog deve ser negociado entre o time
de Desenvolvimento e o Product Owner (PO), sempre praticando o bom senso;
Existem algumas técnicas de estimativas que podem ser utilizadas com Scrum. A técnica
de Planning Poker é uma das mais populares, quando, através de cartas com
numeração seguindo a sequência de Fibonacci, os membros do time “sugerem” um
tamanho (size) para os requisitos do Product Backlog.
76
PLANNING POKER
Baseado nas explicações do Product Owner (PO) sobre o

requisito, os participantes esclarecem suas dúvidas e fazem
a estimativa de acordo com que consideram em seu
entendimento que é alinhado até chegar a um consenso.
77
PLANNING POKER FUNCIONA PORQUE...
... apresenta múltiplas opiniões de especialistas quanto à estimativa

de um requisito;
... estimula o dialogo durante as reuniões, e cada membro do time tem

a oportunidade de explicar para todos os outros membros o porque
estimou o requisito com aquele tamanho. Todo este processo gera
compartilhamento de conhecimento;
...estudos mostram que estimas feitas em grupo vem sendo mais bem
sucedidas que estimativas individuais;
78
ESTIMATIVAS ERRADAS
Quanto mais o time vai desenvolvendo as histórias de usuário, mais velocidade eles
ganham.
Em determinadas estimativas o esforço calculado antes não é o que será realmente gasto.
Por isso as estimativas em Pontos por História é a maneira mais correta e simples para
corrigir, pois são auto corrigíveis pela aplicação da velocidade.
Em estimativas com Pontos de História é apartado as estimativas de esforço com as

estimativas de duração.
79
VALOR PARA O NEGÓCIO
Custos de Os itens que contemplam o Backlog do
Benefícios de
Desenvolvimento e Produto tem valor ao negócio, que
Negócio Manutenção
pode ter um cálculo voltado para
termos financeiros ou simples por meio
do método MoSCoW ou outros
A Estratégia da Organização que irá indicar quais serão os
benefícios de Negócio métodos
▪ ROI (Return On Investiment);

▪ Taxa Interna de Retorno (IRR - Internal Rate of Return);
▪ Payback Simples e Descontado;
▪ VPL: Valor Presente Líquido (NVP - Net Present Value);
▪ Retorno sobre o Investimento (ROI - Return on Investment);
▪ Custo Total de Propriedade (TCO - Total Cost of Ownership).
80
EVENTOS SCRUM
Os Eventos Scrum servem para ter uma rotina e para diminuir a necessidade de reuniões fora da
metodologia Scrum.
É importante inserir todos os eventos Scrum para manter a transparência e adaptação nos processos.
Por este motivo cada evento do Scrum ocorre dentro de uma time-box, ou seja, com um tempo pré-
determinado para que aconteça.
O Time-Box não pode ter seu tempo modificado após o inicio de uma Sprint
81
EVENTOS SCRUM:
Time Box
82
CONCEITO DE SPRINT
A Sprint é um time-box de 2 a 4 semanas no qual o time do produto irá produzir

uma parte do produto definida pelo cliente
O conceito de Sprint nos remete à necessidade de estarmos frequentemente

entregando algo de valor para o cliente.
Uma Sprint deve ser empreendida por um time multi-disciplinar com não
mais que 9 membros
Cada Sprint deve ter uma meta específica que represente o desejo do cliente
para aquele time-box específico
83
DEFINITION OF DONE (DoD)
Definição de Pronto. É o contrato

entre o time de desenvolvimento e o
cliente (P.O.) para cada Sprint,
baseado nisso é determinado se os
objetivos da Sprint foram alcançados
ou não
84
INCREMENTO DO PRODUTO
S1 S2 S3 S4
S1, S2, S3 e S4 são produtos potencialmente entregáveis

Ao final de cada Sprint, o time deve ter produzido um incremento
potencialmente entregável do produto com alta qualidade, testado,
completo e pronto
Potencialmente entregável  entregável
R1
R1 é um entregável!
85
SPRINT SMART
Specific – Específico
Measurable – Mensurável
Achivable – Atingível
Realistic – Realista
Timed – Datado
86
REGRAS DE OURO DA SPRINT
• Sempre entregar valor para o cliente ao final de cada Sprint
• Nunca esquecer: o deadline é sagrado, as funcionalidades é o que podem

“variar”
• Se houver necessidade de incluir tarefas técnicas, arquiteturais, estudos, ou

qualquer tipo de tarefa que não forneça valor visível para o cliente: fazer
balanceamento entre estas tarefas e as com alto ROI
87
SEMPRE ENTREGAR VALOR
Itens técnicos, arquitetura...
Itens com ROI visível

S1 S2 S3 S4 S5 S6
88
TAMANHO DA SPRINT
“O tamanho ideal de uma Sprint é o tamanho que o time e o cliente considerarem ideal,
levando em conta principalmente o risco ao se desenvolver um produto complexo.”
Pontos de atenção para mensurar: quanto maior o risco, menor deve ser a duração da
iteração (sprint)
• Mudança constante no topo do Product Backlog: ideal trabalhar com Sprints curtos
• Dificuldade de entregar valor para o cliente ao fim das Sprints: ideal trabalhar com Sprints
curtos
• Time e/ou cliente exaustos com loops tão curtos: ideal trabalhar com Sprints longos
89
SEM MUDANÇAS DURANTE A SPRINT
O que o time se comprometeu a entregar – e o que foi acordado com o Product Owner (PO)
– é o que deve ser entregue
Quando mudar o conteúdo da Sprint se torna regra...
• Deixa de haver a necessidade de fazer um planejamento de qualidade, bem como de estar

atento a uma boa composição e priorização do Product Backlog; afinal, se pode mudar a
qualquer momento, para que se preocupar com isso?
• O Time ignora a meta, afinal “com certeza” ela mudará
• O Time perde foco e motivação
• Stress impera
90
QUANDO PARAR A SPRINT?
Uma Sprint pode ser terminada antes da sua finalização nas seguintes situações:
• O Time sente que não conseguirá atingir a meta
• O Product Owner (PO) percebe que mudanças em fatores externos

influenciarão diretamente no valor da meta da Sprint
Caso uma Sprint seja cancelada deve se iniciar imediatamente o planejamento da próxima
Sprint
91
BACKLOG DA SPRINT
Backlog da Sprint é
formado do conjunto de
itens selecionados para a
Sprint
Projeção para o Time de Desenvolvimento de quais itens serão desenvolvidos no próximo

incremento e para o time se planejar em como realizar esse incremento.
Planejamento em detalhes para que seja possível o entendimento claro de todos,

principalmente nas Reuniões Diárias.
92
MÓDULO 4
REUNIÃO DE PLANEJAMENTO
A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra
em cena no início de cada Sprint.
Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser

convidados a participar em determinados momentos da reunião, desde que agreguem valor
à mesma e tenham seu convite aprovado pelo Product Owner (PO).
Pela prática, percebemos que a duração desta reunião segue a seguinte tabela:
94
PLANEJAMENTO POR COMPRIMISSO
Se compromete; ainda pode fazer mais
Se compromete; mas não

consegue incluir mais nada
Selecionar um requisito do
Ajuste de prioridades Backlog
Pergunte se time se
Finaliza Sprint Planning
compromete
Quebra requisito em histórias

de usuário Não se
compromete
Identificar a meta da Sprint
Estimar histórias de usuário

Remove o requisito
95
VELOCIDADE
• Velocidade é uma medida da produtividade do Time;
• Representa a taxa de trabalho que o Time conseguiu

completar durante um Sprint;
• Serve de guia para o planejamento de Sprints.
• Serve de guia para o planejamento de Releases e progresso do produto.
96
PLANEJAMENTO POR VELOCIDADE
Reunião I Reunião II
Ajuste de prioridades
Selecionar requisitos do Quebra requisitos em histórias

Identificar a meta da Sprint
Backlog de usuário
Determinar velocidade
Estimar histórias de usuário
97
PLANEJAMENTO DA RELEASE
Trata-se de uma reunião de planejamento de alto nível que abrange a

iteração dos Sprints futuros.
Nessa reunião temos visão a longo prazo do que será feito, quais recursos
serão implementados e quando serão concluídas.
Planejamos as entregas que vão ocorrer ao longo do produto e

monitoramos o progresso do mesmo (onde estamos e para onde vamos).
98
PLANEJAMENTO DA RELEASE
Continua planejanda Releases até que a Visão do produto seja alcançada
Selecionar um tamanho de
Sprint
Determinar os critérios de Estimar velocidade

Estimar os Itens do Backlog Selecionar Itens e data da
aceite
Release
Priorizar Histórias de usuário
99
TAMANHO DA RELEASE
O Product Owner (PO) é quem possui a visão de qual é o momento ideal para liberar uma
nova versão do produto
Observe que não adianta entregar produto rápido, não permitindo ou tornando inviável o
acompanhamento de atualização pelo cliente
• Um Release deve ser algo integrado e de grande valor para o cliente
100
PLANEJAMENTO EM CAMADAS (ONION PLANNING)
101
PLANEJAMENTO EM CAMADAS - LIBERAÇÃO
❑ Tem a visão da liberação (release) do produto;
❑ Tempo médio de 3 a 9 meses;
❑ Atividades estimadas em pontos de história de usuário ou dias ideais;
❑ É composto de informações mais gerais.
102
PLANEJAMENTO EM CAMADAS - PRODUTO
Planejamento do Produto
▪ O Product Owner (PO) terá que ter uma visão geral do produto maior que a
liberação (release).
103
PLANEJAMENTO EM CAMADAS - PORTIFÓLIO
Planejamento de Portfólio e Estratégico
▪ Incluí uma apuração dos produtos que mais apresentem uma visão da
implementação que foi imposta por meio do planejamento estratégico da
empresa.
104
VALOR DO DINHEIRO NO TEMPO
O cálculo do ROI é os valores iguais do investimento no tempo de um ano e o investimento ganho

depois de cinco anos.
VLP (Valor Presente

Valor Presente Líquido): Investimento do
Valor Presente
TIR (Taxa Interna de
Retorno): métrica da
velocidade do
Desconto: Conduz os aumento do
valores futuros para É utilizado para se ter a métrica de investimento do
retornar ao valor quanto dinheiro investido no produto produto terá,
presente hoje terá retorno no futuro, em valor representado em
presente atual porcentagem.
105
CALCULANDO O RETORNO FINANCEIRO
▪ Período de Payback Simples;

▪ Período de Payback Descontado;
▪ VPL (Valor Presente Líquido) – NVP;
▪ TIR (Taxa Interna de Retorno) – IRR;
▪ TCO (Total Cost of Ownership).
106
▪ Período de Payback é o tempo que um investimento leva para pagar o

seu investimento inicial.
PAYBACK SIMPLES:
É o número de períodos (ano, meses, semanas) para se recuperar o
investimento inicial.
Calculo: soma dos valores dos fluxos de caixa, período a período, até que o
valor se iguale ao investimento inicia.
107
PAYBACK DESCONTADO:
É o número de períodos (ano, meses, semanas) para se recuperar o
investimento inicial, usando uma TAXA DE DESCONTO antes de proceder
com a soma dos fluxos de caixa.
Calculo: soma dos valores dos fluxos de caixa, período a período, até que o
valor se iguale ao investimento inicial. Entretanto, todos os fluxo DEVERÃO
ser descontados pela taxa em relação ao período ao qual o fluxo está
atrelado.
108
VPL (Valor Presente Líquido) – NVP
É usado para analisar a viabilidade de projetos, com ele é possível fazer os

ajustes necessários, descontando as taxas de juros para obter a verdadeira
noção do valor do dinheiro no futuro. Leva em consideração a valorização
do capital ao longo do tempo.
Onde:
VPL = Valor Presente Líquido
FC = fluxo de caixa
t = momento em que o fluxo de caixa ocorreu
i = taxa de desconto (ou taxa mínima de atratividade)
n = período de tempo
109
Ex.:
Vamos imaginar uma empresa que esteja pensando em investir em cota de fundo imobiliário que
paga 0,7% ao mês por 2 anos. O valor dessa cota é de R$ 15.000,00.
#01 – Como primeiro passo, definimos o fluxo de caixa:
Onde:
FC = fluxo de caixa
110
Ex.:
#02 – Feito isso, vamos definir a taxa de desconto, ou taxa mínima de atratividade. Como fundos imobiliários oferecem mais risco
quando comparados aos títulos de governo, utilizaremos uma taxa de 12,1% ao ano.:
#03 – Em seguida, calcularemos o valor presente de cada um dos fluxos:
Onde:
FC = fluxo de caixa
111

Ex.:
#04 – Por fim, conforme a fórmula apresentada, somaremos os valores. No nosso exemplo, teremos que:
112
TIR (Taxa Interna de Retorno) – IRR
É uma medida relativa – expressa em percentual – que demonstra o quanto rende um produto,
considerando a mesma periodicidade dos fluxos de caixa do produto, ou seja, calculando a
viabilidade econômica.
113
TCO (Total Cost of Ownership) – Custo total de propriedade

É uma métrica de análise que tem como objetivo calcular os custos de vida e de aquisição de um produto, ativo ou
sistema. Por esta razão o TCO é às vezes chamado análise de custo do ciclo de vida.
Também usado para o cálculo de aquisições em projetos.
114
ROI (RETURN OF INVESTMENT)
Retorno do Investimento Inicial Investimento Inicial
O objetivo de se realizar o cálculo ROI é para saber em percentuais o retorno do produto.
115
MÓDULO 5
PROGRESSO DO PROJETO
Raramente, ao realizar um acompanhamento do andamento do produto, o resultado será

como o previsto. Devido a alterações de requisitos, a métrica do progresso não será o que
se é esperado, pois falhas podem ocorrer na maneira de como é realizada a medição da
nossa posição.
Estar preparado para a qualquer momento verificar onde o produto está e o que resta para
termina-lo.
Caso necessite de alterações no produto, é importante considerar o trabalho já realizado e

quais serão as alterações realizadas no escopo.
117
MONITORANDO O ANDAMENTO
Em qualquer momento do produto, pode ser somado o tempo restante do trabalho para alcançar o objetivo.
118
MONITORANDO A VELOCIDADE
Os pontos são
Problemas em contabilizar
contabilizados na trabalhos não terminados:
velocidade somente
com histórias de
usuário concluídas ▪ Dificuldade em contabilizar um
Time Scrum
no final da Sprint trabalho ainda inacabado;
▪ Histórias de usuário
incompletas diminuem a
Faz o
Quantidade de
confiança do Time de
acompanhamento Desenvolvimento e cliente;
Pontos de
do progresso
Estória
trabalho medindo
através da
realizados por ▪ Atividades inacabadas ficam
Sprints.
velocidade acumuladas.
119
GRÁFICO DE BURNDOWN
A linha direita representa o atual trabalho

realizado.
A linha esquerda é a velocidade que

representa a taxa estimada de trabalho.
No eixo vertical é apresentado a

quantidade de trabalho a ser completado.
No eixo horizontal é apresentado as datas

ou dias de execução.
120
QUADRO SCRUM
O Scrum Board é um dos elementos

Radiadores de Informação, o o ponto de
controle da Sprint do produto, que mostra
como as histórias de usuário (user stories)
são segmentadas e disponibilizadas para
serem tratadas pelos membros do time de
desenvolvimento.do time conforme
evolução.
121
QUADRO SCRUM - UTILIZAÇÃO
O KANBAN. Pode ser utilizado de

diversas formas, a mais fácil e
intuitiva para seu time é o que
deve ser usado.
122
QUADRO DE TAREFAS
123
ALOCANDO O TRATAMENTO DE BUGS
Um grande desafio para as times ágeis é como lidar com os erros. O Quadro de Tarefas é
um grande auxiliar nesses casos para iniciar as correções.
Se o time determina que é necessário consertar o erro, por sua prioridade ser alta, o Time
de Desenvolvimento estima o trabalho, logo depois, retirem a mesma quantidade da
estimativa de atividades na coluna "Para Fazer" do quadro de Tarefas.
Para poder corrigir os erros levantados pelo Product Owner (PO), o time escolhe a
quantidade de iteração deve ser orientado para correção de erros em vez de um novo
recurso; Depois faz uma triagem de quais erros podem entrar em um período de tempo.
124
ACOMPANHANDO O ESFORÇO DO TIME
▪ Realizar a coleta de dados e estimativas sem pressão;

▪ Entender que estimativas variam;
▪ Não é aconselhável realizar a métrica de velocidade por individuo. A premissa sempre é
de trabalho em time;
▪ Impossível de calcular individualmente, pois as atividades são direcionadas para serem
trabalhadas por mais de uma pessoa.
125
COMUNICAÇÃO ENTRE AS PARTES
Além da importância da comunicação, deve-se focar na forma como realizamos e

passamos as estimativas e os planos, sendo de maneira frequente, transparente e
recíproca.
No decorrer do produto os planos são atualizados, e essas alterações necessitam que

sejam comunicadas, não ignorando os feedbacks que é uma excelente forma de obter
melhoria continua do produto.
Em comunicados que são realizados com uma demora de tempo é importante que as
partes interessadas tenham um panorama do andamento do produto em relação ás
revisões do plano de liberação.
126
COMUNICANDO OS PLANOS
Os Planos tem que ter uma divulgação transparente e clara a todos os envolvidos no
produto.
Assegurar que todos aceitem a estimativa real.
Número de Pontos de Estória que serão entregues
Dividindo por uma estimativa de velocidade

Cronograma
127
CONTROLANDO UM PROJETO
Reuniões Diárias: evento que todos podem participar para ter de forma rápida uma visão do produto.
Reunião de Revisão da Sprint: evento que informa mensalmente se o produto está progredindo de
acordo com os objetivos.
Backlog do Produto e Relatórios de Final de Sprint: informações de forma impressa e de alcance de

todos que desejam obter as informações.
Reuniões Diárias (Daily Scrum): reunião somente com o Time de Desenvolvimento, outras pessoas
podem participar, no entanto deverá estar somente como ouvinte.
Scrums dos Scrums: utilizado em projetos de grande porte, reunião para informar os desenvolvedores
dentro dos times.
128
REUNIÃO DIÁRIA (DAILY STAND-UP
Reuniões rápidas e objetivas, com 15 minutos de duração.
Time de desenvolvimento se reúne para verificar se o progresso da Sprint está sendo

direcionado para Meta da Sprint e como o esforço está tendendo para conclusão.
▪ O que foi feito?

▪ O que será feito?
▪ Tem algum obstáculo?
Esta reunião não serve para resoluções de problemas e conflitos.
129
REVISÃO DA SPRINT (SPRINT REVIEW)
Realizada ao final da Sprint com a participação do Product Owner (PO), Partes Interessadas internas
e externas, Time Scrum e outros, com o foco de verificarem o que foi entregue na Sprint e analisarem
a necessidade de alguma alteração no produto.
Reunião informal. É realizada para obter feedback do time e dos envolvidos.
Tempo de 4 horas para uma Sprint de um mês.
▪ Time relata o que aconteceu durante a Sprint;

▪ Entrega o incremento do produto;
▪ Aprendendo com a experiência da Sprint;
▪ Proibido apresentação com PowerPoint.
Resultado esperado é o Backlog revisado para a próxima Sprint.
130
REUNIÃO DE REVISÃO
A transparência: pois todo o trabalho desenvolvido até então,
é apresentado. Não espera-se o final do produto para mostrar
o que foi feito.
É o momento formal do Scrum para comunicação e interação entre Dono do Produto e

Stakeholders com o time de desenvolvimento. É uma reunião que promove:
A inspeção: é possível acompanhar a evolução dos trabalhos,

pois é possível avaliar o que já foi feito e o que ainda falta fazer.
A adaptação: é possível fazer ajustes nos itens que faltam,

mudar sua prioridade e solicitar melhorias no que já foi pedido.
131
PÓS-REUNIÃO DE REVISÃO
❑ Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las
❑ Remover do Product Backlog funcionalidades que foram finalizadas antecipadamente
❑ Repriorização do Product Backlog

❑ Solicitar o fechamento de um Release com as funcionalidades demonstradas, sozinhas ou
com o incremento de Sprints anteriores
❑ Escolher não avançar mais com o produto e não autorizar outra Sprint
❑ Solicitar que o progresso do produto seja acelerado autorizando a inclusão de times

adicionais para trabalhar no Product Backlog
132
RETROSPECTIVA DA SPRINT
Última evento realizada na Sprint para o Time Scrum analisar todas as lições
aprendidas (boas ou ruins) que ocorreram durante a Sprint.
Scrum Master é o responsável por esta reunião e auxilia o Time de Desenvolvimento a

melhorar dentro da metodologia Scrum o processo e as práticas de desenvolvimento.
Evento para planejamento de melhorias para o produto.
Tempo de 3 horas para uma Sprint de um mês.
133
REUNIÃO DE RETROSPECTIVA
❑ Melhoria de processos no final de cada Sprint
❑ Falicitada pelo Scrum Master
❑ O que foi bom? O que deve ser melhorado?
❑ O Scrum Master prioriza os itens citados de acordo com a direção do time
❑ O time propõe soluções para a maioria dos problemas que a atrapalham/irritam
❑ Retrospectivas são a essência do conceito de inspeção e adaptação
134
QUADRO DA RETROSPECTIVA
O que foi bom? O que deve melhorar?
135
ORGANIZANDO A ANÁLISE
Time Empresa Time Empresa
Impedimentos Backlog
136
MÓDULO 6
ESCALANDO PROJETOS ÁGEIS
Em projetos grandes é difícil gerenciá-lo como um produto pequeno, pois eles são mais
críticos para organização, de extrema urgência, pode ocorrer conflitos, seu tempo é maior.
Quando isso ocorre, é necessário distribuir em pequenos times em vez de um único de 5 a 9

pessoas podendo utilizar quantos times forem necessários, não há um limite.
O Product Owner (PO) também pode ser escalado, pois pode ocorrer atrasos, gerenciamento
das dependências do time, em coordenar das atividades entre as equipes.
138
ESCALANDO O PRODUCT OWNER
É aconselhável ter um Product Owner (PO) para cada time.
Caso isso não seja possível, não deixar mais do que 2 times por Product Owner (PO). Pois com
um número maior, a chance de ter um mal gerenciamento é muito maior.
Em outros casos, quando possuem vários Product Owner (PO)s no mesmo time, é
aconselhável deixar um responsável, ter uma visão panorâmica de todo o produto para atuar
estrategicamente com os demais.
139
DIVERSOS BACKLOGS DO PRODUTO
Backlog do Produto será um para cada produto.

Terá um tamanho razoável de itens.
Em casos de mais uma time, o ideal é ter apenas um Backlog do Produto mas que contempla as
diversas visões dos outros Product Owner (PO)s.
Caso um time tenha uma visão igual do Backlog do Produto, que possuir itens do interesse de outro
time, assim os itens podem ser mostrados para ambos os times.
140
GERENCIAR DEPENDÊNCIAS DE EQUIPES
▪ Planejar com antecedência: fazer com que cada time tenha na Sprint, um momento para se
planejar para o que será feito nas próximas Sprints;
▪ Kick off das Liberações: Para manter todo o time na mesma linha de objetivo, se reunir para
explicar o que é esperado;
▪ Compartilhar os membros dos times entre os times: O mesmo membro trabalhando em duas
equipes ao mesmo tempo;
▪ Time de integração: trabalha entre as equipes para preencher os espaços que existe.
141
SCRUM OF SCRUMS
Cada time possuí o embaixador que através de reuniões periódicas se reúnem para relatar o que
cada um dos times pretendem realizar e os possíveis impedimentos que podem interferir nas
atividades.
Os embaixadores podem ser:
▪ Desenvolvedores;
▪ Scrum Masters;
▪ Gerentes de cada time.
Cada time possuí seu próprio backlog para otimizar a organização entre as equipes.
142
SAFE – SCALED AGILE FRAMEWORK
SAFe criado pela Scaled Agile serve para organizações de grande porte.
É uma base de conhecimento para a implementação da metodologia ágil em uma organização.
Com uma interface de usuário principal apresentada por um desenho, ou um Big Picture, que
detalha os papéis, times, tarefas, e artefatos que é preciso para implementar o ágil em grande
escala.
143
SAFE – 8 VANTAGENS
1. Visão Global
Elaborado para expandir o Agile em toda a empresa, e não somente na time de desenvolvimento. Portanto, a
gerência, os analistas de negócio, analistas de sistemas e gestores também passam a fazer parte deste
FRAMEWORK, utilizando ferramentas e seguindo práticas que antes eram só desempenhadas por
desenvolvedores, projetistas e analistas de testes.
Toda a organização fica integrada em uma única estrutura.
144
2. Big Picture – Tudo em uma mesma página
Na página oficial do SAFe [https://www.scaledagileframework.com/] , há um diagrama definido como The Big

Picture, que aborda todos os fluxos, papéis e atividades, facilitando um entendimento “macro” do framework.
Ao visualizar a The Big Picture pela primeira vez, por exemplo, já é possível observar que se propõe três níveis na
escala organizacional:
1. Portfolio (gerencial),
2. Program (estratégico)
3. Team (operacional)
Cada nível é responsável por um conjunto de funções e tarefas necessárias para a condução das funcionalidades
a serem desenvolvidas em cada ciclo.
145
3. Gratuito
Pela sofisticação, alguém pode pensar que o SAFe exige uma “licença” para ser utilizado. Errado!
Qualquer empresa pode estudar e implantar a metodologia sem custo algum. Todo o material de apoio (muito bem
detalhado!) está disponível no site. A The Big Picture, assim como outros gráficos, também podem ser baixados
gratuitamente.
146
4. Conheça e use
A The Big Picture é totalmente interativa. Cada figura representa um link que leva à uma página com definições
mais detalhadas sobre o conceito. Sendo assim, em 1 semana (ou até bem menos), é possível acessar todos os
links e compreender plenamente o funcionamento do framework.
147
5. Incorpora métodos ágeis já consolidados no mercado]
O SAFe unifica os conceitos das metodologias Scrum e XP e cria um termo literalmente definido como ScrumXP.
Este “novo” termo engloba tanto os procedimentos do Scrum para gerenciamento de equipes, como as práticas
do XP para a qualidade de código.
XP = Extreme Programming (Programação Extrema)
148
6. Novos papéis, equipes e definições no contexto ágil
Release Planning: Onde todas os Agile Teams (equipes ágeis) se unem para discutir as funcionalidades que serão
desenvolvidas no próximo PI (Program Increment)
RTE (Release Train Engineer):Papel responsável por conduzir as equipes de desenvolvimento durante
um ART (Agile Release Train) e ministrar eventos como o I&A (Inspect & Adapt)
System Team: Time alocada para homologar as user stories concluídas no ciclo DBT (Define/Build/Test) e
apresentá-las no evento System Demo
Estes e outros conceitos foram elaborados ou customizados para viabilizar o Desenvolvimento Ágil em escala.
149
7. Quebra de Paradigmas
No Scrum, sabemos que as user stories são desenvolvidas em uma Sprint e, ao seu término, um novo incremento
do software é disponibilizado para o cliente.
No SAFe, este ciclo acontece de uma forma um pouco diferenciada: o incremento final do programa é entregue a
cada 75 dias! Mas, calma, isso não significa que tudo é feito em uma única “super” Sprint. Na realidade, são 5
Sprints de 15 dias que, no SAFe, representam um “trem”, ou um Agile Release Train.
Esse time-box foi introduzido para facilitar a integração de vários times ágeis e permitir que o produto, com todas
as implementações do ciclo, seja testado por uma time específica antes de ser disponibilizado para o cliente.
Mas o ciclo, por exemplo, pode ser estendido para 90 dias (3 meses) ou reduzido para 60 dias (2 meses). Vale citar
também que a última Sprint de cada “trem”, chamada de Innovation and Planning, é exclusivamente utilizada para
treinamentos, inovações e capacitações dos colaboradores como forma de melhoria contínua.
150
8. Permite a sustentabilidade da arquitetura
Na The Big Picture, pode-se notar que alguns itens dos backlogs estão em vermelho.
Estes são chamados de itens arquiteturais, criados para refinar a arquitetura do produto (através de refatorações,
por exemplo), ou prepará-la para receber futuras funcionalidades de negócio.
Por meio destes itens, é possível manter a sustentabilidade do produto, evitando o código legado, módulos
obsoletos e restrições técnicas.
151
Fonte: https://www.scaledagileframework.com/#
152
MÓDULO 7
153
INSERINDO O ÁGIL PARA DIFERENTES TIPOS DE PROJETOS
Uma organização pode ter vários motivos que a leva a ter restrições para a
implementação ágil por toda a empresa, principalmente quando há um Método
em Cascada sendo utilizado ao mesmo tempo.
Para isso é necessário ter a seguinte visão:
▪ Logo no inicio do produto se adequar a realidade da organização;

▪ Scrum e o Cascata se encontram na fase final do produto, nos testes;
▪ Que podem existir duas equipes utilizando métodos diferentes para entregar o
mesmo produto.
154
ZONAS DE CONFLITO
Processo de Desenvolvimento: Modos diferentes de processos para desenvolvimento entre o

Scrum e o Cascata.
Processos de Negócio: Se a organização está habituada com os processos em Cascata será

difícil habituar ao processo Scrum.
Pessoas: Conflito entre os diferentes papéis que existem entre as duas formas de trabalho.
155
ADOTANDO O ÁGIL
As organizações estão optando pelo Ágil devido a sua velocidade de entrega de um produto
ou serviço rápida e com qualidade.
No entanto para iniciar as boas práticas ágeis em uma organização não é tarefa fácil. Alguns
pensamentos que tem ser considerados em uma transição:
▪ Scrum não é somente na área de Desenvolvimento de Software;

▪ As boas práticas ágeis devem atingir todos os setores da organização;
▪ Melhoria Contínua é a alma do Scrum;
▪ Transparecer em todos da organizações os benefícios da implementação do ágil irá trazer.
156
CONSIDERAÇÕES NA TRANSIÇÃO PARA O SCRUM
▪ Até mesmo um CEO não terá como implementar o Scrum com uma correta visão, comunicar isso
aos demais, conseguir eliminar os obstáculos, ter ganhos a curto prazo e gerenciar diversos
projetos de mudança.
▪ Uma organização que quer implementar o Scrum sem o apoio da alta liderança, não terá um
resultado eficaz e eficiente.
▪ Análises de GAPs: Impossível prever o que irá acontecer no futuro, sozinho ou com a participação
de todos, Scrum é tudo diferente, coletar as melhores práticas pode ser algo perigoso, a mudança
acontece em uma velocidade acima do normal.
157
BENEFICIOS DO SCRUM
Aumento da Funcionários engajados e Time-to-Market

Produtividade envolvidos mais ágil
Redução dos Custos
Aumento da Qualidade Aumento da satisfação O que está sendo feito

das Partes Interessadas atualmente já não
funciona mais
158
ADOTANDO COM SUCESSO
Conscientizar as pessoas Mostrar que o Scrum é Evangelizar o Scrum com

que o método atual não Time-to-Market
uma forma de resolução a troca de experiências
está sendo satisfatório mais ágil
dos problemas atuais
Necessário definir onde todos da empresa:

pessoas, times e a organização como um todo
estão no processo de adoção do Scrum
Passar o conhecimento
da utilização do Scrum na
organização
159
MARCOS NA TRANSIÇÃO
A wareness – Consciência do que é feito hoje não está tendo resultados com valor.
D esire – Desejo ter o Scrum como um método para solucionar os problemas.
A bility – Capacidade para obter resultados com o Scrum.
P romotion – Promover a filosofia ágil com troca de experiências.
T ransfer – Transferência de sugestões da utilização do Scrum em toda organização.
160
RESISTÊNCIA NA ADOÇÃO DO SCRUM
O Scrum Master é responsável por envolver o time na utilização do Scrum mostrando regularmente os
benefícios que o framework traz.
Identificar as pessoas que podem ser resistentes a mudança, aquelas que podem ter a expectativa de
perder algo como: cargo, prestígio, influência, orçamento, entre outros.
161
TIPOS DE RESISTENTE
Céticos Sabotadores Resistentes
Teimosos Seguidores
162
LIDANDO COM A RESISTÊNCIA A MUDANÇA
▪ Com o tempo, fazer com que a pessoa acredite que dará certo, ao
acompanhar os bons resultados;
▪ Fornecer treinamento;
▪ Exemplificar com experiências de sucesso;
▪ Escolher um cético que conseguiu entender o processo;
Céticos ▪ Auxiliar a pessoa a ter consciência dos valores, princííos, práticas ágeis
e seus benefícios.
163
▪ Promover movimentação interna;

▪ Recomendar desligamento;
▪ Ter certeza de que está falando com as pessoas certas.
Sabotadores
164
▪ Deixar claro quais são os incentivos, extrínsecos e

intrínsecos;
▪ Gerar satisfação com o status quo;
▪ Reconhecer e lidar com o medo.
Teimosos
165
▪ Modificar a composição do time;

▪ Reconhecer o comportamento adequado;
▪ Envolvê-los;
▪ Modelar de maneira correta o comportamento de si mesmo;
Seguidores
▪ Verificar a verdadeira barreira: causa raiz.
166
TIME AUTO-ORGANIZADO
A prática Scrum preza pelas equipes auto-organizáveis, mas isso não significa que não há controles.
Os mesmos devem existir, de uma forma sutil e indireta.
O Time Scrum tem como objetivo ser auto-organizável em meio a desafios, e dentro dos limites e
restrições do ambiente.
O time ser capaz de se auto-organizar por meio das metas é fundamental em todas as práticas ágeis.
167
MONTANDO EQUIPES: CHA
▪ Listar todas as competências habilidades e atitudes (CHA) necessárias necessárias;

▪ Balancear níveis de conhecimento técnico;
▪ Balancear o domínio de conhecimento;
▪ Valorizar a diversidade;
▪ Ser persistente.
168
REQUISITOS ÁGEIS
▪ Ambiente de trabalho ideal auxilia no apoio ao time;

▪ A falta do ambiente ideal impede no esforço;
▪ Ter estrutura para poder questionar;
▪ Modelo em que os membros do time reportem a um gerente ou o Product Owner
(PO);
▪ Naturalmente a pressão sobre eles tende a minimizar, ajudando então o progresso
do produto e diminuindo a pressão;
▪ Product Owner (PO) e o Scrum Master não precisam estar na mesma linha do
organograma, porém os dois devem se tratar como parceiros no produto.
169
ESPAÇO DE TRABALHO
O Scrum preza por ambientes sem divisórias e sem salas para facilitar o fluxo de informações e
comunicação entre todos, com pequenas salas de reunião que podem ser utilizadas por qualquer
pessoa.
▪ Ambientes abertos facilitam a alteração do layout;

▪ Como os times mudam de tamanho, os ambientes abertos, são propícios para a alteração dos
lugares quando necessário;
▪ Sala de Guerra (War Room);
▪ Times Scrum também necessitam de sala para reuniões;
▪ Membros do time Scrum devem preferencialmente sentar juntos.
170
SOBRE O EXAME
Duração: 90 minutos
✓ Questões múltipla escolha
com 4 opções de resposta,
somente uma correta
✓ Acerto de 26 questões
Questões: 40
✓ Sem consulta
✓ Não é permitido o uso de nenhum

equipamento eletrônico
Aprovação: 65% da prova
171
Simulado Agile Scrum Foundation
172
1. A gerência sênior quer auditar regularmente se o time está seguindo
as práticas e princípios ágeis. Quem está na melhor posição para
conduzir tal auditoria?
a) Product Owner (PO)

b) Scrum Master
c) Time de Desenvolvimento
d) Time
173
2. O time Scrum pensa em uma boa prática para definir claramente um
checklist de itens que devem ser completados antes de chamar uma
história de usuário de “concluída”. Que artefato eles podem estar
usando para isto?
a) Gráfico de Burndown
b) Definição de Pronto
c) Backlog do Produto
d) Backlog da Sprint
174
3. Uma Sprint concluída foi um desastre total. As histórias de usuário
planejadas não foram cumpridas e a Sprint Review foi cancelada. A
gerência sênior quer saber quem foi o responsável por isso.
Quem é afinal o responsável pelo sucesso ou fracasso de um time

Scrum?

b) Scrum Master
c) Gerência sênior
d) Time Scrum
175
4. O que o W representa no acrônimo da técnica de priorização MoSCoW?
a) Whether
b) Wish
c) Won't
d) Would
176
5. Qual é o melhor momento para refatorar um código ao desenvolver
um produto?
a) Continuamente e na primeira oportunidade possível

b) Durante as iterações mais difíceis
c) Durante a última iteração
d) Quando o Product Owner (PO) decidir agendar
177
6. Qual das seguintes opções é uma característica desejável para um
Radiador de Informação? (Escolha a melhor opção)
a) Atual
b) Detalhado
c) Fornecido com base no que é “preciso saber”
d) Estável
178
7. Para estimar a complexidade de uma história de usuário específica,
que carga de trabalho deve ser planejada pelo time de desenvolvimento?
a) Conforme determinado pela Definição de Pronto

b) Design e desenvolvimento
c) Design, desenvolvimento e testes
d) Design, desenvolvimento, testes e documentação
179
8. Passadas oito Sprints, um time completou 85 pontos por história de
usuário em conjunto. O time foi agora acionada para iniciar um trabalho
em um novo desenvolvimento, o qual está estimado em 64 pontos por
história de usuário. Quantas Sprints serão necessárias para completar
este produto?
a) Cinco
b) Sete
c) Oito
d) Dez
180
9. Uma história de usuário tem a complexidade estimada em cinco pontos (story
points). Qual é a interpretação do número cinco?
a) O número de horas de duração requeridas para completar a história de usuário

b) O número de homem/dia em esforço requerido para completar a história de
usuário
c) O número de homem/hora de esforço requerido para completar a história de
usuário
d) Tamanho relativo da história de usuário com relação a outras histórias
181
10. Qual é o melhor caminho para melhorar a comunicação em um time Scrum distribuído?
a) A nomeação de um único ponto de contato para a comunicação entre todos os locais

b) Colocalização de toda a time para uma sessão de planejamento da versão de entrega
c) Estabelecer trilha de auditoria clara para toda a comunicação do produto
d) Apresentar etapas de transição adicionais no produto para assegurar supervisão
182
11. Qual das opções abaixo é um dos valores do Manifesto Ágil?
a) Valorizamos negociações de contrato mais do que colaboração com o cliente

b) b) Valorizamos seguir um plano mais do que responder a mudanças.
c) Valorizamos processos e ferramentas mais do que interação com o cliente.
d) Valorizamos o software funcionando mais do que documentação abrangente.
183
12. Em quanto tempo um time Scrum, com cinco integrantes, deve
finalizar o planejamento de uma Sprint (Sprint Planning) com duração de
3 semanas?
a) De uma a três horas

b) De três a seis horas
c) De seis a doze horas
d) Quinze horas
184
13. Uma pessoa está trabalhando no código e outra pessoa está observando,
criticando e ocasionalmente trocam de papéis entre eles. Qual prática está
sendo seguida aqui?
a) Revisão de código (Code Review)

b) Integração contínua (Continuous Integration)
c) Programação em pares (Pair Programming)
d) Desenvolvimento orientado a testes (TDD)
185
14. Um membro do time Scrum percebe que o arquiteto técnico sênior de
outro time Scrum pode ter alguma percepção e comentário de valor sobre o
desenvolvimento do produto. Em qual evento Scrum o arquiteto técnico
sênior deve ser convidado para participar? (Escolha a melhor opção)
a) Reunião Diária
b) Planejamento da Sprint
c) Retrospectiva da Sprint
d) Revisão da Sprint
186
15. O Product Owner (PO) quer que uma história de usuário seja concluída em
até dois dias. O membro do time que está trabalhando na história de usuário
acha que vai levar cinco dias. O Scrum Master considera que a história de
usuário deve durar três dias, e existe a possibilidade de ser feita consulta a um
especialista. De quem deve ser considerada a estimativa para o planejamento?

b) Scrum Master
c) Especialista no assunto
d) Membro do time
187
16. De acordo com as práticas ágeis, que tipo de time pode surgir com
melhores requisitos, arquiteturas e design?
a) Co-localizado
b) Experiente
c) Auto-organizado
d) Bem treinado
188
17. Um time Scrum está consciente de que está atrasado na entrega de um
componente que outro time Scrum está esperando. Qual é a melhor evento
para discutir esta questão e encontrar uma solução?
a) Reunião diária de um dos dois times Scrum

b) Scrum-de-Scrums
c) Revisão da Sprint
d) Retrospectiva da Sprint
189
18. Um time está em transição para o Scrum. Eles já possuem um papel de
Coordenador de Projeto, que facilita interações, remove impedimentos e atua
como um coach dos processos do time. Qual deve ser o nome deste papel após
a transição?
a) Coordenador de Projeto
b) Gerente de Projeto
c) Scrum Master
d) Gerente de Projeto Scrum
190
19. Ao rever o comportamento das barras verticais do gráfico de Burndown da versão
de entrega, um Scrum Master recém-chegado no time, observou que a parte inferior
da barra tinha se movido acima do eixo horizontal entre as iterações três e quatro. O
que pode se concluir com esta observação?
a) O time terminou menos histórias de usuário do que as alocadas para a iteração três
b) O time terminou mais histórias de usuário do que as alocadas para a iteração três
c) Foi adicionado trabalho para o produto durante a iteração três
d) Foi removido trabalho para o produto durante a iteração três
191
20. No final de cada dia de trabalho, os membros do time atualizam o número
de horas remanescentes nas tarefas no quadro Scrum. Em seguida, o Scrum
Master resume as horas e traça uma linha em um gráfico. Qual é o nome deste
gráfico?
a) Gráfico de Burndown
b) Gráfico de Burnup
c) Gráfico de linhas
d) Diagrama de estacionamento
192
GABARITO
1B 11 B
2B 12 C
3D 13 C
4D 14 C
5A 15 A
6B 16 A
7B 17 A
8C 18 B
9D 19 D
10 D 20 D
OBRIGADO !
Agile Scrum Foundation

ASF
194

Treinamento Agile Scrum Foundation - Trainning-Vfinal

Enviado por

Dados do documento

Título original

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

Treinamento Agile Scrum Foundation - Trainning-Vfinal

Enviado por

Direitos autorais:

Formatos disponíveis

1

Agile Scrum Foundation

Não há pré-requisito para realizar o

Entretanto, para melhor aproveitamento

▪ Gerente de Serviços de TI;

O que colaborou para que os projetos em que vocês participaram

O que colaborou para que os projetos em que vocês participaram

- Apenas 26% dos projetos de software tradicionais têm sido bem

- 8% dos projetos ÁGEIS tem falhado nos últimos anos.

- Investimento em TI atingiu US$ 3,7 trilhões em 2018, segundo Gartner

Standish Group 2018

Standish Group 2018

Fonte: VersionOne, Agile Annual Report, 2019

Scrum é a estrutura (framework) que eu construí para colocar

Metodologia: é um conjunto de métodos, padrões e regras

“Framework”: é uma estrutura, um conjunto de conceitos e

Então, um Framework pode fazer parte de uma metodologia ou

Sim! As abordagens ágeis são mais um hábito do que um processo.

O escopo do produto, no método tradicional, No Ágil, o escopo do produto é realizado

Inspeção ❑Inspecionar artefatos produzidos;

Adaptação ❑Analisar o grau de impacto de possíveis desvios dentro do plano;

Indivíduos e interação entre eles mais que processos e ferramentas

Source: VersionOne Annual State of Agil Report, 2019

Scrum trata de comportamento, de atitude, e não de um processo, de adotar nova

Controle sutil pela alta gerência

Transparência Inspeção Adaptação

Abertura Coragem Respeito Foco Comprometimento

• O PO cria uma lista inicial de necessidades que precisam ser produzidas

• No início de cada iteração (Sprint) o time deve se reunir para realizar a

➢ Remover a barreira entre desenvolvimento e cliente

➢ Assegure-se que todo mundo está fazendo o que se comprometeu a fazer

➢ Trabalhe no Product Backlog com o Product Owner (PO)

➢Zelar pelo bom funcionamento ágil em toda sua essência

É necessário que o Scrum Master entenda a dificuldade das

Esse repasse deverá ser realizado fazendo uso de CNV

Realizar análise em detalhes;

Treinar e formar para o conhecimento mais aprofundado do Scrum.

Informando a todos que o Scrum é diferente da metodologia tradicional.

▪ Determinar metas para todos os Scrum Masters de capacitação;

Realizar um programa de treinamento;

Vantagens de adotar coaching e treinamento interno:

▪ Equipes com conhecimento não precisa ser separada;

Algumas aprendizagens ocorre naturalmente outras procuram intencionalmente, se preocupando com o

▪ A mentalidade do time estar pensando sempre em aprender;

➢ Definir a visão do produto (product vision);

Método Tradicional Time Scrum

▪ Não dedica muito tempo na fase de

▪ Backlog do Produto é a lista dos

▪ Dinâmico, pois é permitido adicionar e remover itens, repriorizar conforme a

▪ A mudança constante que ocorre no Backlog do Produto faz dele um artefato

▪ O Backlog do Produto nunca será algo completo;

▪ O Product Owner (PO) é o responsável ;

Uma boa prática utilizada no Backlog é a técnica INVEST, acrônimo: Independent

A estimativa dos itens do Backlog do Produto é de responsabilidade do Time de

As outras atividades fica na responsabilidade do Product Owner (PO) que são:

▪ Dono do Backlog do Produto;

Detecte cada atividade por sua sequência cronológica, mapeando da

• Durante este workshop os participantes escrevem a quantidade de

• Prioridades não são associadas;

• Bons workshops combinam os melhores elementos de brainstorming

Para isso, fatores comuns nas critérios de aceite possui:

▪ Escopo (ou Roadmap de produto);

• Uma característica marcante de projetos/serviços baseados em “Histórias de