Treinamento

Agile (Ágil)
Scrum Master
(SM)
1
Introdução

2
Gerenciamento de Projetos Tradicional

3
Por quê o ágil?
Desenvolvimento de soluções no modelo tradicional

Pesquisa Escrita Design Edição Aprovação Entrega

Desenvolvimento de soluções no modelo ágil

Sprint Sprint Sprint Sprint Sprint Sprint

Tempo

4
Preditivo x Empírico

5
6
Como surgiu o ágil? Scrum
(Ken Schwaber, Jeff
Sutherland)
O modelo de trabalho ágil surgiu da necessidade Adaptive Software
Development (ASD)
de entregar maior valor aos clientes de forma mais (Jim Highsmith, Sam Criação do
Crystal Clear
assertiva e vem sendo desenvolvido deste a década Bayer)
(Alistair Cockburn)
Manifesto Ágil
de 70. FDD Especialistas em diversas
XP metodologias de Lean SW
(Jeff De Luca)
Concept of “Adptive (Kent Beck, Ward desenvolvimento de Development
Waterfall Model Software Development” Rapid App. Development DSDM Cunningham, Ron Software se reúnem para (Marry & Tom
(Winston W. Royce) (Edmonds, E. A.) (James Martin) (DSDM Consortium) Jeffries) criar um “manifesto” ágil. Poppendieck)

1970 1974 1991 1995 1996 2001 2003

Conforme a timeline relacionada acima um grupo de profissionais
engajados e com experiência no desenvolvimento de softwares se Valores do manifesto ágil
reuniu e criou o manifesto ágil baseado em Pilares e Valores.
Satisfação do Indivíduos Atenção à técnica
cliente é prioridade motivados e bom design
Pilares do ágil Indivíduos e Processos e
interações ferramentas
Aceitar mudanças Conversa cara a Simplicidade
Estamos descobrindo
“ maneiras melhores de Software em
desenvolver software, funcionamento
Documentação
abrangente
cara

Software em Times auto

fazendo-o nós mesmos e Entregas frequentes funcionamento organizáveis
ajudando outros a fazerem Colaboração Negociação de
o mesmo. com o cliente contratos Trabalho conjunto e Ambiente Feedback
Mesmo havendo valor nos colaborativo sustentável recorrente
itens à direita, valorizamos Responder a Seguir um
mais os itens à esquerda. mudanças plano
” 7
Principais Conceitos
Desenvolvimento Cooperação entre
incremental, ou seja, equipe e cliente (ciclo
melhoria contínua; de feedback constante);

Entregas rápidas e de Flexibilidade de escopo

alta qualidade; do projeto;

Criação de valor
Adaptabilidade às
progressiva e de acordo
mudanças e alto nível
com as necessidades do
de inovação.
cliente;
8
 Desafios do Mercado atual

9
Standish Group
Módulo 1 - SCRUM GUIDE
The SCRUM Guide 2020
Guia de boas práticas ágeis, desenvolvido e mantido
pelos criadores do Scrum, Ken Schwaber e Jeff
Sutherland.

Esse material passou por algumas atualizações para

acompanhar as inovações e a última ocorreu em
2020. O Guia apresenta as regras e o
funcionamento do Scrum, descritos de forma
concisa e objetiva.

https://scrumguides.org/docs/scrumguide/v2020/2
020-Scrum-Guide-PortugueseBR-3.0.pdf

10
 Principais certificações
Scrum Alliance
•Fundação: 2001
•Fundada pelos criadores do Scrum: Jeff Sutherland e Ken Schwaber
•Possui aproximadamente 330 mil certificados em todo o mundo¹ (no Brasil são cerca de 2000 profissionais certificados)
•Certificações oferecidas pelo organização:
• Scrum Master (CSM)
• Product Owner (CSPO)
• Developer (CSD)
• Scrum Professional (CSP )
• Coach (CSC )
• Enterprise Coach (CEC)
• Trainer (CST)
• Agile Leadership (CAL)
•Necessário fazer um treinamento de 16 horas ministrado por um Certified Scrum Trainer para se submeter aos exames de certificação CSM e CSD
•Nível de dificuldade dos principais exames (CSM e CSD): Fácil
•Para obter a certificação CSPO basta frequentar um treinamento ministrado por um CST (não há exame para esta certificação)
•Principais exames disponíveis no idioma português-BR
•Certificações com validade de 2 anos (Taxa mínima de renovação: $100 dólares)
•Preço médio dos exames: Como é obrigatório passar por treinamento, o preço médio dos treinamentos, já com o exame incluso, está em torno
de $2.300,00 reais
•Formato do exame: Múltipla Escolha, com 4 alternativas por questão, sendo apenas uma correta
•Quantidade de questões: 35
•Duração do exame: 60 minutos
•Score mínimo para passar: 26 questões corretas
•Local do exame: Online
11
Scrum Alliance ou Scrum.org? | Café com o Scrum Master (cafecomscrum.com)
 Principais
Scrum Org
certificações
•Fundação: 2009
•Fundada por Ken Schwaber
•Possui aproximadamente 45 mil certificados em todo o mundo
•Certificações oferecidas pela organização:
1.Scrum Master (PSM I, PSM II, PSMIII)
2.Product Owner (PSPO I, PSPO II)
3.Developer (PSD I)
4.Trainer (PST)
5.Scaled Professional Scrum (SPS)
6.Professional Agile Leadership (PAL I)
7.Professional Scrum with Kanban (PSK I)
8.Professional Scrum Practitioner (PSP) [Certificação descontinuada, ler mais sobre aqui]
•Não é necessário fazer nenhum treinamento oficial para se submeter aos exames
•Nível de dificuldade dos principais exames (PSD I, PSM I, PSPO I): Médio
•Exames disponíveis apenas no idioma inglês
•Certificações emitidas pela organização não expiram, ou seja, não tem validade e não precisam de renovação
•Preço aproximado dos exames: $200 dólares
•Formato de exame: Múltipla Escolha, tendo várias questões com 7 ou 8 alternativas, podendo ser todas corretas ou apenas algumas delas (o
enunciado da questão dirá quantas alternativas deverão ser selecionadas) e questões de verdadeiro ou falso
•Quantidade de questões: 80
•Duração do exame: 60 minutos (45 segundos por questão)
•Score mínimo para passar: 85% (68 questões de 80)
•Local do exame: Online

Scrum Alliance ou Scrum.org? | Café com o Scrum Master (cafecomscrum.com)

12
Papéis e Responsabilidades

13
Squad: montando um Squad

14
Squad: Escalando em Tribos

15
Áreas de Conhecimentos

16
Papéis:
O Ágil na
prática

17
 Scrum Master (SM)
➢ Remover a barreira entre desenvolvimento e cliente;

➢ Ensinar o cliente a maximizar o ROI e atingir seus objetivos através do Scrum;

➢ Melhorar o dia-a-dia dos membros da equipe facilitando a criatividade e fortalecimento do grupo;

➢ Priorizar os impedimentos e combatê-los;

➢ Auxiliar o Product Owner com o Product Backlog;

➢ Garantir o uso do Scrum;

➢ Facilitar reuniões.
18
 Scrum Master (SM)
➢Motive para que todos estejam fazendo o que se comprometeram a fazer;

➢Determine onde Scrum está, comparado com onde poderia estar e atualize os
gráficos de Burndown ou Burnup;

➢Ofereça apoio no Product Backlog em conjunto com o Product Owner;

➢Zele pelo bom funcionamento do Framework ágil em toda sua essência.

19
 Scrum Master (SM)
➢ O Scrum Master estimula por meio de treinamentos, coaching, removendo
impedimentos e solucionando problemas, que o framework Scrum seja entendido e
disseminado.
➢ Não é um gerente do projeto ou da equipe/time de desenvolvimento.
➢ Mas é papel do Scrum Master orientar e motivar o time a seguir o framework
➢ Scrum, sem obrigar a equipe a realizar ações, pois no ágil as equipes são
multidisciplinares e auto organizáveis.
Scrum Master tem como característica ser um líder servidor,
➢ sem impor nada ao time.
20
Scrum Master (SM)
Responsabilidades:
▪Humildade;
▪Colaboração;
▪Comprometimento;
▪Influência;
▪Conhecimento.
21
Módulo 3 - Aprendizagem
Scrum Master (SM)
Mesmo após a equipe estar com pleno entendimento do Scrum, comprometida com os
resultados e diminuir a dependência dos especialistas é importante que os membros
procurarem novas formas de aprender e de compartilhar os conhecimentos
proativamente.

Cabe ao Scrum Master incentivar a equipe a procurar o conhecimento através de:

▪ A mentalidade da equipe deve estar focada sempre em aprender;

▪ Os membros tem que ter a possibilidade de compartilhar o conhecimento;
▪ Liderança, mostrando a equipe a importância do aprendizado constante;
▪ Ter desafios que motivem a equipe a sempre procurarem por aprendizagem;
▪ Ambiente favorável para aprender.

22
Product Owner(PO)
➢ Definir a visão do produto e suas necessidades (Product Backlog);

➢ Gerenciar o retorno de investimento (ROI);

➢ Apresentar a equipe/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 projeto;

➢ 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. 23
Time DEV(Equipe)
➢ Executar as ações definidas para o Sprint Backlog

➢ Ser por característica multidisciplinar;

➢ Ter foco na meta da Sprint e do Produto;

➢ Prezar pela comunicação clara, objetiva e efetiva;

➢ Zelar pela garantia do DEADLINE da SPRINT;

➢ Ser inovador e contribuir ativamente para o sucesso do projeto;

➢ Entender a demanda apresentada e propor a melhor forma de atendê-la;

➢ Ser claro na informação sobre IMPEDIMENTOS encontrados durante a Sprint;

➢ Sempre entregar como resultado da Sprint, algo que agregue valor ao cliente; 24
Dinâmica 1
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas
Multidisciplinar: experiências variadas
Sala de discussão: cada grupo criará OBJETIVO:
Realizar Revisão : a partir da reunião de refinamento
e conceito do DoR aplicado
Técnicas aplicada: Spike, Workshop e refinamento
Artefato: seguir Planilha exemplo instrutor
Entrega: Revisão do(s) item(s) do Product Backlog que
iremos realizar a Planning.
25
Eventos do Scrum

26
SCRUM: ESTRUTURA
Product Owner ScrumMaster Equipe

27
SCRUM: ESTRUTURA
• O Product Owner define a Visão do Produto. Esta Visão é o que representa sua necessidade, é o que deve ser satisfeito ao fim do
projeto;
• Para definir esta Visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos, etc.;

28
SCRUM: ESTRUTURA
• O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog;
• O ScrumMaster deve auxiliar o PO na elaboração desta lista.

29
Product Backlog

30
Módulo 4 - Lista de Desejos no Product Backlog
Product Backlog
O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os requisitos que um
cliente espera receber ao final do projeto, descrito com sua própria linguagem. O ponto central do Scrum é a
criação do Product Backlog, é nele que o projeto começa.

Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder começar a
executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso. Afinal nesse ponto
ainda não conhecemos suficiente o projeto e precisamos avançar um pouco mais em algumas hipóteses antes
de ter tanta “certeza”.

Uma mudança muito clara no mindset é que no início do projeto o Product Backlog não precisa estar completo.
Podemos ter uma visão macro do produto e dos requisitos esperados. Conforme avançamos no projeto, o
Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Para melhor estruturar o Product Backlog nós utilizamos as chamadas estórias do usuário ou user storys —
oriundas do Product Backlog — elas contém a descrição detalhada dos requisitos de cada solicitação a ser
implementada.
31
Módulo 4 - Escrevendo o Backlog do Produto
Product Backlog
▪ 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 é 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.

32
 33

Estória do
Usuário –
Writing
Workshop
33
Se preocupando com a Qualidade
Definition of Ready (DoR)
O Scrum Team define critérios para que uma user story possa ser implementada
em uma sprint. Critérios de negócio, técnicos ou outros.

34
SCRUM: ESTRUTURA
• No início de cada iteração (Sprint) o time deve se reunir para realizar a Planning Meeting; TimeBox = 8 horas
• Nesta reunião o time realizará o planejamento do que será entregue ao final do ciclo da Sprint (que deve ser de 2 a 4
semanas).

35
SCRUM: ESTRUTURA
• Na primeira parte da Planning Meeting o PO deverá: definir a meta da Sprint e falar para o time sobre os Itens mais
prioritários do Product Backlog;
• O time deve estimar os Itens em tamanho (caso ainda não estejam estimados) e selecionar o que acredita que possa ser feito
durante a Sprint. Essa lista selecionada chama-se Selected Product Backlog;
• O facilitador desta reunião é o ScrumMaster.

36
Módulo 4 – Planning Poker
Planning Poker
Definindo a complexidade das Estórias do usuário x dimensionamento da Sprint

37
Planning Poker
✓ O esforço estimado para os itens do Product Backlog deve ser avaliado pela equipe/time e
informado e negociado com o Product Owner, sempre praticando o bom senso;

✓ Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum. O
Planning Poker é uma das mais populares, onde, através de cartas com numeração seguindo a
tabela de Fibonacci, os membros do time “sugerem” um tamanho (size) para os requisitos do
Product Backlog.

✓ Baseado nas explicações do Product Owner 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.

38
Módulo 4 - Planning Poker Funciona porque...
Planning Poker

39
Dinâmica 2
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas
Multidisciplinar: experiências variadas
Sala de discussão: cada grupo criará OBJETIVO:
Realizar Planning Meeting: a partir da leitura da
individual da estória pelo PO
Técnicas aplicada: Planning Poker
Artefato: seguir Planilha exemplo instrutor
Entrega: Pontuação final da complexidade das
estórias, conversão em horas.
40
Estrutura do Scrum
SCRUM: ESTRUTURA
• Na segunda parte da Planning Meeting o time deverá colher mais detalhes dos Itens do Selected Product Backlog e decompô-
los em tarefas, gerando assim o Sprint Backlog;
• Para isso pode ser necessária a ajuda de Especilistas 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 ScrumMaster.

41
O que é Kanban?

42
Dinâmica 3
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas
Multidisciplinar: experiências variadas
Sala de discussão: cada grupo criará OBJETIVO:
Criar Kanban: listar atividades, distribuir quantidade
de horas, Criar Quadro Kanban/Guias e associar
atividades/estórias ao Kanban
Técnicas aplicada: Kanban
Artefato: utilizar ferramenta Planner
Entrega: Kanban
43
Estrutura do Scrum
SCRUM: ESTRUTURA
• Durante a execução da Sprint, valem as práticas de engenharia definidas para o projeto;
• O ScrumMaster, 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;.

44
 SPRINT
• Sempre entregar valor para o cliente ao final de cada Sprint;
• Nunca esquecer: o deadline é sagrado, as funcionalidades é o que pode “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

“O tamanho ideal de uma Sprint é o tamanho que sua equipe e cliente achar ideal.”

Pontos de atenção para mensurar:

• 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;

• Equipe e/ou cliente exaustos com loops tão curtos: ideal trabalhar com Sprints longos.
45
SCRUM: ESTRUTURA
• Diariamente o time realiza uma reunião de 15 minutos (Daily Meeting) na qual cada membro deve responder:
• O que fiz desde a última reunião?
• O que pretendo fazer até a próxima?
• 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 ScrumMaster novamente é o facilitador, e deve lembrar-se que a reunião é para o time e não para ele.

46
 Daily Meeting

O que eu fiz desde a última reunião?

Quais os problemas estão impedindo de realizar o meu trabalho?
O que vou fazer até a próxima reunião?
47
Trello Jira | Software para acompanhamento de itens e projetos (atlassian.com) TFS is Azure DevOps Server - Azure DevOps | Microsoft Docs
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.

48
Gráfico de BurnUp
A linha azul representa a quantidade de
trabalho a ser realizado no projeto de acordo
com o tempo.

A linha verde representa o que de fato foi

realizado por cada Sprint. Sendo que acima
da linha azul de monstra que está adiantado,
e abaixo, está atrasado.

No eixo vertical é apresentado a quantidade

de trabalho a ser completado no projeto.

No eixo horizontal é apresentado as datas de

conclusão de cada Sprint.

A linha em amarelo, representa o total do

projeto em pontos que deve ser alcançado.49
Dinâmica 4
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas OBJETIVO:
Multidisciplinar: experiências variadas
Executar Daily Meeting: a partir do Kanban, executar
Sala de discussão: cada grupo criará pelo menos 3 rodadas de Daily com atualização do
Quadro Kanban e elaboração do Gráfico de BurnDown
ou BurnUp
Técnicas aplicada: Daily meeting scrum, Gráfico
BurnDown/BurnUP
Artefato: utilizar ferramenta Planner e seguir planilha
exemplo instrutor
Entrega: Kanban atualizado e gráficos (Down ou UP)
50
Quando parar a
Sprint?
• Uma Sprint pode ser terminada antes da sua
finalização nas seguintes situações:

• A equipe sente que não conseguirá atingir a

meta; Sim ou não?

• O Product Owner percebe que mudanças em

fatores externos influenciarão diretamente no
valor da meta da Sprint, e solicita seu
cancelamento. Sim ou não?

• Caso uma Sprint seja cancelada deve se iniciar

imediatamente o planejamento da próxima
Sprint. Sim ou não?
51
Conceito de Feito (DoD)

Definição de Feito. É o contrato entre o time de

desenvolvimento e o cliente (P.O.) para cada Sprint,
baseado nisso é determinado se os objetivos foram
alcançados ou não.

52
 Criando o Conceito de Feito (DoD)
A criação do conceito de feito deve ser realizada de maneira colaborativa, ou seja, por todos os membros da
Equipe/Time Scrum.

Durante a primeira Sprint Planning, o time definir a v1 da sua definição de pronto. Por exemplo: comece com
coisas simples como “todo item dado como pronto deve ter passado em testes unitários” e depois se
aprofunde em itens mais “avançados” como testes de regressão e teste em pares

Seguindo os pilares no Scrum (inspeção e adaptação, transparência) itere e melhore seu conceito de pronto a
cada Sprint.

Pegue o que deu errado na Sprint Review e aborde na Sprint Retrospective e aplique de maneira aperfeiçoada
na próxima Sprint Planning. Comece simples e avance rapidamente. Lembre-se que a função deste artefato é
garantir a qualidade, mas lembre-se também de se manter ágil.

Na Sprint Planning considerar o conceito de pronto pois o tempo para que cada entrega fique pronta pode
mudar drasticamente. Tenha a definição de pronto pronta antes de jogar Planning Poker, por exemplo.
53
Criando o Conceito de Feito (DoD)
O conceito de feito é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas.
Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há um
elemento de software envolvido, lhe cobrando diariamente que cumpra os requisitos do documento.

Sendo um contrato moral e ao mesmo tempo algo colaborativo, o time terá de achar o checklist que agrade a
todos, incluindo aqui o Product Owner, que é quem tem a palavra final sobre os itens do Backlog que o Time
de Desenvolvimento está trabalhando. O documento deve ser útil para garantir a qualidade das entregas que
seja executável, exequível.

Raramente, ao realizar um acompanhamento do andamento do projeto, 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 projeto está e o que resta para terminá-lo. Caso
necessite de alterações no projeto, é importante considerar o trabalho já realizado e quais serão as alterações
realizadas no escopo.
54
Se preocupando com a Qualidade
Definition of Done (DoD)
O Time Scrum define critérios para que a Entrega possa seguir e ser apresentada
no evento Sprint Review. Critérios de negócio, técnicos, compliance ou outros.

55
 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, 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.

56
SCRUM: ESTRUTURA
• 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
para o Product Owner e convidados;
• O time é quem realiza a apresentação, que deve ser feita no formato de demo;
• Product Owner avalia se a Meta da Sprint foi alcançada;
• Product Owner faz anotações que poderão se transformar em novos Itens para o Product Backlog.

57
Sprint REVIEW

Não é permitido o uso de Power Point !!

58
Dinâmica 5
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas
Multidisciplinar: experiências variadas
Sala de discussão: cada grupo criará OBJETIVO:
Executar Sprint REVIEW: utilizando o incremento
desenvolvido para demonstração
Técnicas aplicada: execução do software ou execução
de outro incremento
Artefato: incremento da Sprint
Entrega: Review realizada, incremento entregue e
atualização Product Backlog
59
SCRUM: ESTRUTURA
• A última cerimônia de um Sprint Scrum é a Retrospectiva;
• Reunião de lições aprendidas, facilitada pelo ScrumMaster, na qual o time deve avaliar: o que foi bom na última Sprint? O que deve ser melhorado? Quem
está no controle?
• Esta reunião representa o espírito de Inspeção-Adaptação dentro do Scrum;
• É uma reunião do time, mas – caso seja de acordo de todos seus membros – o PO também pode participar.

60
 Sprint RETROSPECTIVE
1 - Definir a segurança do ambiente
6 - Priorizar as melhorias
2 - Linha do tempo

3 - O que foi bom

5 - Dividir as melhorias por

responsabilidades 4 - O que pode melhorar

61
Planning meeting
TimeBox Scrum
Sprint

Daily Meeting

Sprint Review

8 horas Sprint Retrospectives

2a4
semanas

15 min

4 horas

3 horas
Dinâmica 6
GRUPOS:
Tamanho: Squad de até 11 pessoas
PO: 1 por Squad
SM: 1 por Squad
Time DEV: de 5 a 9 pessoas
Multidisciplinar: experiências variadas
Sala de discussão: cada grupo criará OBJETIVO:
Executar Sprint RETROSPECTIVE: utilizar retrospectiva
passada ou criar nova
Técnicas aplicada: Kanban, espinha de peixe, SWOT,
etc
Artefato: gerar planilha com pontos (fracos e fortes)
Entrega: Pontos fracos e forte
63
Release

64
RELEASE – entregando valor
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

S1 S2 S3 S4

S1, S2, S3 e S4 são produtos potencialmente entregáveis

R1

R1 é um entregável!
65
RELEASE – planejamento liberação
O Product Owner é quem possui a visão de
qual o período ideal para distribuir uma nova
versão do produto:

1. Não adianta entregar produto tão

rapidamente de forma a tornar impossível
o acompanhamento de atualização do
cliente;
2. Um Release deve ser algo integrado e de
grande valor para o cliente.

➢ 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 projeto e monitoramos o progresso do mesmo
( onde estamos e para onde vamos ). 66
Módulo 6 – Integração com outros Frameworks
Integração com outros Frameworks

67
Escalando o Scrum

68
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 equipe.

Cada equipe possuí seu próprio backlog

para otimizar a organização entre as
69
equipes.
 Em projetos grandes é difícil gerenciá-lo como um projeto pequeno, pois eles
são mais críticos para organização, de extrema urgência, pode ocorrer
conflitos, seu tempo é maior.

Desafio Quando isso ocorre, é necessário distribuir em pequenos times em vez de um

único de 05 a 09 pessoas podendo utilizar quantos times forem necessários,

das não há um limite.

equipes
O Product Owner e Scrum Master também podem ser escalados, pois pode
ocorrer atrasos, gerenciamento das dependências do time, em coordenar das

escaláveis
atividades entre as equipes. É aconselhável ter um Product Owner para cada
time.

Em casos de mais uma equipe, o ideal é ter apenas um Backlog do Produto

mas que contempla as diversas visões dos outros Product Owners.

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. 70
 SAFe 5 for Lean Enterprises

71
http://www.scaledagileframework.com/
https://www.scrumalliance.org/get-certified
Scrum Open | Scrum.org

https://www.exin.com/br-pt/certificacoes/

Certificações e Simulados

72
Auto-avaliação (Maturidade/Aderência)
Nível de
Maturidade

Aderência Metodológica

73
OBRIGADA!!

74
74