(FM2S) Slides Diagramados - Especialista SCRUM - Parte 2

Passo 2.
4 -
Identificar
Tarefas
Processo de Identificar Tarefas:
ENTRADAS FERRAMENTAS SAÍDAS
1 - Time Central do Scrum 1 - Reuniões de Planejamento 1 - Lista de Tarefas

2 - Histórias de Usuário da Sprint 2 - Scrumboard Atualizado
Comprometidas 2 - Decomposição 3 - Histórias de Usuário
3 - Critérios de Aceitação das 3 - Determinação da Comprometidas Atualizadas
Histórias de Usuário Dependência 4 - Dependências
4 - Ferramenta do Projeto
Scrum
8.1 Criar a Visão do Product Owner
Projeto
8.2 Identificar Scrum Master 9.4

Scrum Master e os Identificar Tarefas
Business
Stakeholders
Scrum Team
8.3 Formar o Scrum
Team Lista de Tarefas
Critérios de
Aceitação
9.1 Criar Histórias
de Usuário
Comprometer 9.5 Estimar
9.3 Comprometer Histórias Tarefas
Histórias de
Usuário
Passo 2.4 - Identificar Tarefas
Entradas
As entradas a seguir já foram definidas
anteriormente:
▪ Time Central do Scrum;
▪ Histórias de Usuário Comprometidas;
▪ Critérios de Aceitação das Histórias de Usuário.
Ferramentas
Revisão das Histórias de
Usuário Comprometidas
▪ O Scrum Team revisa cada História de Usuário
comprometida para a Sprint;
▪ Identifica atividades acionáveis ou tarefas
necessárias para implementar os entregáveis
associados à História de Usuário;
▪ O Product Owner está presente para fornecer
esclarecimentos sobre as Histórias de Usuário
Comprometidas, ajudando a equipe a tomar
decisões de design.
Ferramentas
Decomposição
▪ O Scrum Team utiliza a técnica de decomposição
para dividir as Histórias de Usuário em tarefas
detalhadas;
▪ As Histórias de Usuário são decompostas a um
nível que fornece informações adequadas para
criar os entregáveis necessários.
Ferramentas
Determinação de Dependências
▪ O Scrum Team considera quaisquer
dependências, incluindo disponibilidade de
pessoas e dependências técnicas;
▪ A documentação adequada de dependências
ajuda a determinar a ordem relativa das tarefas,
facilitando a criação dos entregáveis da Sprint;
▪ Destaca o relacionamento e a interação entre as
tarefas dentro do Scrum Team que trabalha na
Sprint e entre diferentes Scrum Teams no projeto.
Saídas
Lista de Tarefas
É uma ferramenta essencial para acompanhar e
executar as atividades ao longo de uma Sprint.
Abrangendo todas as tarefas que o Scrum Team se
comprometeu a realizar durante a Sprint, ela inclui
descrições correspondentes a cada uma delas.
A granularidade das tarefas é decidida pelo próprio
Scrum Team, podendo abranger esforços de teste e
integração para garantir a incorporação
bem-sucedida do incremento de produto aos
entregáveis de Sprints anteriores.
Saídas
Lista de Tarefas
Durante as Reuniões de Planejamento da Sprint, a
Lista de Tarefas é uma ferramenta central para
atualizar o Sprint Backlog.
A capacidade de fazer ajustes durante a Sprint
permite que a equipe avalie se é necessário ajustar
seu comprometimento original, facilitando a decisão
de assumir ou não Histórias de Usuário adicionais
durante o Planejamento da Sprint para as próximas
Sprints.
Saídas
Atualização do Scrumboard
Atualização contínua é essencial no Scrum, e o
Scrumboard ajuda nesse processo, refletindo as
tarefas associadas a cada História de Usuário à
medida que são identificadas. Seja em formato físico
ou eletrônico, o Scrumboard é moldado pela
preferência da equipe.
Se as tarefas foram estimadas, o Scrumboard pode
exibir essas estimativas, contribuindo para uma
compreensão clara do esforço envolvido. Essa
funcionalidade auxilia na gestão eficiente do tempo
e recursos, fornecendo insights úteis durante o
desenvolvimento da Sprint.
Exemplo 2.4 -
Identificando
Tarefas
Exemplo 2.4 - Identificando Tarefas
Continuando o nosso Exemplo…

Lucas e Isabela conduziram as Reuniões de
Planejamento da Sprint conforme as práticas ágeis
do Scrum. Durante essas reuniões:
▪ O Scrum Team revisou cada História de Usuário
comprometida para a Sprint. Identificaram
atividades acionáveis ou tarefas necessárias
para implementar os entregáveis e atender aos
critérios de aceitação;
Exemplo 2.4 - Identificando Tarefas
▪ Lucas, Product Owner, estava presente para

esclarecimentos relacionados às Histórias de
Usuário e para auxiliar a equipe na tomada de
decisões de design.
Assim, asseguraram que as prioridades definidas
pela Product Owner fossem compreendidas e
refletidas no planejamento.
História de Usuário: Registro de Atividades Diárias
▪ Criar interface de usuário para entrada de atividades diárias;
▪ Desenvolver funcionalidades para armazenar registros de atividades diárias no
banco de dados;
▪ Implementar validações para garantir dados precisos na entrada do usuário.
História de Usuário: Notificações de Lembretes de Medicamentos
▪ Integrar sistema de notificações para alertar usuários sobre lembretes de
medicamentos;
▪ Configurar preferências de notificação para permitir personalização pelos
usuários.
História de Usuário: Integração com Dispositivos Wearables
▪ Pesquisar e integrar API de dispositivos wearables;
▪ Desenvolver lógica para capturar e processar dados de dispositivos wearables;
▪ Testar integração com dispositivos específicos.
História de Usuário: Visualização de Tendências de Saúde ao Longo do Tempo
▪ Criar gráficos e visualizações para representar tendências de saúde;
▪ Implementar algoritmos para análise e projeção de dados ao longo do tempo.
História de Usuário: Configuração de Metas Personalizadas de Exercício
▪ Desenvolver interface para usuários definirem metas de exercício pessoais.
▪ Integrar metas de exercício ao sistema de registro de atividades diárias.
História de Usuário: Registro de Alimentação
▪ Implementar funcionalidade de registro de alimentação no aplicativo;
▪ Integrar banco de dados nutricionais.
História de Usuário: Painel de Controle do Profissional de Saúde
▪ Desenvolver interface para profissionais de saúde monitorarem o progresso
dos usuários;
▪ Implementar recursos de comunicação segura entre usuários e profissionais de
saúde.
História de Usuário: Atualizações Automáticas de Notícias sobre Saúde
▪ Integrar feed de notícias sobre saúde de fontes confiáveis.
▪ Configurar sistema para fornecer atualizações automáticas aos usuários.
Passo 2.5 -
Estimar
Tarefas
Processo para Estimar Tarefas:
1 - Time Central do Scrum 1 - Reunião de Planejamento 1 - Lista de Tarefas

2 - Lista de Tarefas da Sprint 2 - Scrumboard Atualizado
3 - Critérios de Aceitação das 2 - Critérios de Estimativa
Histórias de Usuário 3 - Técnicas de Estimativa
4 - Dependências
4 - Ferramentas do Projeto
5 - Riscos Identificados Scrum
6 - Recomendações do Scrum
Guidance Body
7 - Estimativas pré-existentes
para Tarefas
Projeto
Scrumboard
8.2 Identificar 9.5 Atualizado
Scrum Master
Scrum Master e os Estimar Tarefas
Business
Stakeholders
Scrum Team
8.3 Formar o Scrum
Team Lista de Tarefas
9.4 Identificar Lista de Tarefas

Tarefas
9.6 Product
Backlog
Atualizado
Passo 2.5 - Estimar tarefas
Entradas
anteriormente:
▪ Lista de Tarefas;
▪ Critérios de Aceitação da História de Usuário;
▪ Dependências;
▪ Riscos Identificados;
▪ Recomendações do Scrum Guidance Body;
▪ Estimativas pré-existentes para Tarefas.
Ferramentas
▪ Reuniões de Planejamento da Sprint
▪ Estimativa do esforço para realizar tarefas e
determinação de recursos necessários;
▪ Uso da Lista de Tarefas como ferramenta central
durante as reuniões;
▪ Objetivo de alcançar uma perspectiva
compartilhada das Histórias de Usuário.
Ferramentas
▪ Critérios de Estimativa
▪ Expressos por meio de pontos de história
ou tempo ideal;
▪ Pontos de história representam esforço
relativo, enquanto o tempo ideal descreve
horas dedicadas exclusivamente ao
desenvolvimento.
Ferramentas
▪ Técnicas de Estimativa
▪ Aplicação das mesmas técnicas usadas para
estimar Histórias de Usuário;
▪ Utilização de métodos como Planning Poker para
facilitar o processo de estimativa.
Saídas
Lista de Tarefas Atualizada
É um documento abrangente que reflete os esforços
estimados necessários para completar as tarefas
durante uma Sprint.
Esta lista é dinâmica e passa por atualizações
contínuas para incluir as estimativas resultantes das
atividades detalhadas de estimativa realizadas
durante o processo de Estimar Tarefas. As
estimativas podem ser ajustadas com base em
mudanças no entendimento coletivo do Scrum Team
sobre as Histórias de Usuário e requisitos.
Saídas
Scrumboard Atualizado
À medida que as tarefas são estimadas, as
estimativas de esforço são atualizadas no
Scrumboard.
Exemplo 2.5 -
Estimando
Tarefas
Exemplo 2.5 - Estimando Tarefas
Isabela e Lucas conduziram as Reuniões de
Planejamento da Sprint de forma colaborativa,
envolvendo o Scrum Team na estimativa do esforço
necessário para concluir as tarefas.
Veremos algumas ações de Isabela e Lucas, durante
essas reuniões.
▪ Envolvimento da Equipe:
Ambos facilitaram a participação ativa de todos
os membros do Scrum Team. Incentivaram
discussões sobre as Histórias de Usuário
comprometidas para a Sprint, esclarecendo
dúvidas e obtendo diferentes perspectivas.
▪ Identificação de Atividades Acionáveis:
Revisaram cada História de Usuário
comprometida e identificaram as atividades
acionáveis ou tarefas necessárias para sua
implementação.
▪ Esclarecimento com o Product Owner:
Contaram com a presença do Product Owner para
obter esclarecimentos relacionados às Histórias
de Usuário e tomar decisões de design quando
necessário.
▪ Estimativas Colaborativas:
Utilizaram Critérios de Estimativa, como pontos
de história ou tempo ideal, para estimar o esforço
necessário para concluir tarefas específicas.
Incentivaram a equipe a compartilhar sua
perspectiva e experiência na atribuição de
esforços às tarefas.
▪ Atualização da Lista de Tarefas:
Com base nas estimativas detalhadas obtidas
durante as reuniões, atualizaram a Lista de Tarefas
para refletir os esforços estimados e suas
descrições correspondentes.
Mantiveram a lista dinâmica para refletir
mudanças no entendimento coletivo da equipe
sobre as Histórias de Usuário e requisitos.
Essa abordagem colaborativa e transparente nas
Reuniões de Planejamento da Sprint permitiu que
Isabela e Lucas atualizassem a Lista de Tarefas de
forma precisa, proporcionando uma base sólida para
o planejamento e execução eficaz da Sprint.
Passo 2.6 -
Atualizar o
Sprint Backlog
Passo 2.6 - Atualizar o Sprint Backlog
Relembrando
O Sprint Backlog, é uma lista de tarefas, histórias de
usuário e outros itens de trabalho específicos que a
equipe do Scrum planeja realizar durante uma
Sprint.
A Sprint Backlog é criada durante a reunião de
planejamento da Sprint, que ocorre no início de cada
Sprint.
Processo para Atualizar o Sprint Backlog:
1 - Time Central do Scrum 1 - Reuniões de Planejamento 1 - Sprint Backlog Atualizado

2 - Lista de Tarefas da Sprint 2 - Scrumboard Atualizado
3 - Duração da Sprint 2 - Ferramentas de 3 - Gráfico Burndown ou
Acompanhamento da Sprint Burnup da Sprint
4 - Sprint Backlog
3 - Medidas de
5 - Scrumboard Acompanhamento da Sprint
6 - Dependências 4 - Ferramentas do Projeto
7 - Calendário do Time Scrum
9.3 Comprometer
Histórias do
8.1 Criar a Visão do Product Owner Usuário Sprint
Projeto Backlog
Scrumboard
8.2 Identificar 9.6
Scrum Master
Scrum Master e os Atualizar o Sprint
Business Backlog
Stakeholders
8.3 Formar o Scrum Scrum Team

Lista de Tarefas
Team
8.6 Conduzir o Duração da Sprint

Planejamento da Sprint
Release Backlog 9.6 Product
Lista de Tarefas
Atualizada Atualizado Backlog
9.5 Estimar Tarefas Atualizado
Passo 2.6 - Atualizar o Sprint Backlog
Entradas
anteriormente:
▪ Lista de Tarefa;
▪ Duração da Sprint;
▪ Sprint Backlog;
▪ Scrumboard;
▪ Dependências.
Entradas
▪ Calendário do Time:
Contém informações sobre a disponibilidade dos
membros do time, incluindo informações
relacionadas a férias, afastamentos, eventos
importantes e feriados.
Um dos objetivos principais da utilização de um
Calendário do Time é acompanhar no que cada
membro do time está trabalhando durante todo o
projeto. Ajudando o time não apenas no
planejamento e execução eficiente das Sprints, mas
também no alinhamento das Sprints com datas das
releases.
Ferramentas
▪ Reuniões de Planejamento da Sprint:
Durante as Reuniões de Planejamento da Sprint, o
Scrum Team realiza atividades essenciais.
Inicialmente, Histórias de Usuário são
comprometidas para a Sprint, escolhidas a partir do
Product Backlog.
Em seguida, as tarefas associadas a cada História de
Usuário são identificadas e estimadas, utilizando
critérios acordados, como pontos de história ou
tempo ideal. Cada membro do time seleciona
tarefas com base em suas habilidades e experiência,
usando a Lista de Tarefas Estimadas de Esforço.
Ferramentas
▪ Reuniões de Planejamento da Sprint:
Por fim, o Sprint Backlog é formado com as Histórias
de Usuário comprometidas e a Lista de Tarefas
Estimadas de Esforço.
Simultaneamente, o Gráfico de Burndown da Sprint é
gerado, oferecendo uma visão visual do progresso
ao longo da Sprint. Essas práticas estruturadas
garantem um início organizado e eficaz para a
Sprint.
Ferramentas
▪ Ferramentas de Acompanhamento da Sprint:
O Scrumboard permite uma representação visual do
status das tarefas do Sprint Backlog.
▪ Medidas de Acompanhamento da Sprint:
Velocidade: número de Histórias de Usuário ou
funcionalidades entregues em uma única Sprint;
Valor do Negócio Entregue: mede o valor das
Histórias de Usuário entregues, avaliando seu
impacto do ponto de vista do negócio.
Número de Histórias: refere-se à quantidade de
Histórias de Usuário entregues em uma Sprint.
Saídas
▪ Sprint Backlog Atualizado:
O Sprint Backlog Atualizado fornece detalhes das
tarefas associadas às Histórias de Usuário
comprometidas, permitindo o acompanhamento
preciso do progresso durante a Sprint.
Se disponíveis, as estimativas de tarefa são
atualizadas, proporcionando uma visão mais precisa
do esforço necessário para concluir as atividades
planejadas.
Saídas
▪ Scrumboard Atualizado:
O Scrumboard é atualizado para refletir as
informações contidas no Sprint Backlog atualizado,
incluindo mudanças nas tarefas, status e
estimativas, proporcionando uma representação
visual em tempo real do progresso da equipe.
Gráfico de Burndown
e Burnup da Sprint
▪ Finalidade: rastrear o progresso em projetos
Scrum durante uma Sprint;
▪ Diferença entre Burndown e Burnup:
⬝ Burndown: mostra a quantidade de trabalho
restante em relação ao tempo;
⬝ Burnup: mostra o que foi concluído em relação
ao tempo;
▪ Uso na Fase Implementar: utilizado para
monitorar o progresso do Scrum Team durante a
Sprint.
Gráfico de Burndown
e Burnup da Sprint
▪ Antecipação de Desafios: oferece uma
indicação antecipada se o time conseguirá
concluir todas as Histórias de Usuário
comprometidas;
▪ Gráfico de Burndown da Sprint Inicial: reflete
como a equipe planeja realizar o trabalho
durante a Sprint. Atualizado diariamente para
mostrar o progresso real.
Gráfico de Burndown da Sprint
Mostra a queda planejada da

quantidade de trabalho. Burndown Real
Burndown Desejado
Fonte: Guia SBOK®, 2022, pg. 222.

Gráfico de Burnup da Sprint
Total a realizar
Total concluído
Fonte: Guia SBOK®, 2022, pg. 223.

Indica o aumento planejado
do trabalho concluído.
Características
▪ Facilidade de Atualização: pode ser atualizado
facilmente para refletir o progresso real e
ajustar estimativas de esforço;
▪ Indicação de Incompatibilidades: fornece uma
indicação de possíveis incompatibilidades entre
o esforço restante e o tempo restante na Sprint;
▪ Preferência pelo Gráfico de Burndown:
geralmente, preferido devido à facilidade de
atualização e melhor indicação de desempenho
da equipe durante a Sprint.
Exemplo 2.6 -
Atualizando o
Sprint Backlog
A fazer Em andamento Teste Concluído
Registro de Atividades Diárias
Visualização de Tendências de Saúde ao
Longo do Tempo
Painel de Controle do Profissional de
Saúde
Notificações de Lembretes de
Medicamentos
Configuração de Metas Personalizadas de
Exercício
Atualizações Automáticas de Notícias
sobre Saúde
Integração com Dispositivos Wearables
Registro de Alimentação
Sprint Backlog Atualizada
Atividade Estimativa Responsável Status

Registro de Atividades
3 pontos Lucas Em Andamento
Diárias
Visualização de
Tendências de Saúde ao 2 Pontos Isabela Em Andamento
Longo do Tempo
Painel de Controle do
5 Pontos Lucas Em Andamento
Profissional de Saúde
Notificações de
Lembretes de 8 Pontos Isabela A Fazer
Medicamentos
Sprint Backlog Atualizada
Atividade Estimativa Responsável Status

Configuração de Metas
Personalizadas de 3 Pontos Lucas Concluído
Exercício
Atualizações
Automáticas de 5 Pontos Isabela Em Andamento
Notícias sobre Saúde
Integração com
8 Pontos Lucas A Fazer
Dispositivos Wearables
Registro de
2 Pontos Isabela Concluído
Alimentação
Passo 3 -
Implementar
Passo 3 - Implementar
Para melhor aprofundamento desta etapa, iremos
dividi-la em 3 Sub Passos:
▪ Passo 3.1 - Criar Entregáveis:
Este Passo envolve a criação dos incrementos do
produto ou entregáveis ao final de cada Sprint.
Os entregáveis devem incluir todas as características e
funcionalidades definidas nas Histórias de Usuário
incluídas na Sprint, e devem ser testados com sucesso.
A equipe trabalha para produzir entregáveis de alta
qualidade que atendam aos critérios estabelecidos.
Passo 3.2 - Conduzir a Reunião Diária:
A Reunião Diária é uma reunião curta, com duração
fixa de 15 minutos. Os membros do Scrum Team
relatam seu progresso na Sprint e planejam as
atividades do dia.
Cada membro responde às Três Perguntas Diárias: o
que foi feito ontem, o que será feito hoje e quais
impedimentos estão enfrentando. A reunião é
gerenciada pelo Scrum Team, mas o Scrum Master pode
mediar conforme necessário.
Passo 3.3 - Refinamento do Product Backlog:
Envolve a revisão e atualização contínua do Product
Backlog durante a Sprint. O Product Owner pode ter
reuniões separadas com stakeholders, Scrum Master e
Scrum Team para garantir que o backlog esteja sempre
alinhado com os requisitos e prioridades do cliente.
Inclui a adição de novas Histórias de Usuário, trabalho
relacionado a Solicitações de Mudança ou riscos
identificados, bem como a repriorização das Histórias
de Usuário existentes. O objetivo é manter o backlog
dinâmico e relevante para o progresso do projeto.
Passo 3.1 -
Criar
Entregáveis
Processo para Criar Entregáveis:
1 - Time Central do Scrum 1 - Expertise do Time 1 - Entregáveis da Sprint

2 - Sprint Backlog 2 - Outras Ferramentas de 2 - Scrumboard Atualizado
3 - Scrumboard Desenvolvimento 3 - Registro de Impedimento
3 - Expertise do Scrum Atualizado
4 - Registro de Impedimento
Guidance Body 4 - Solicitações de Mudança
5 - Cronograma de Não Aprovadas
Planejamento da Release 4 - Ferramenta do Projeto
Scrum 5 - Riscos Identificados
6 - Dependências 6 - Mitigação de Riscos
7 - Recomendações do Scrum 7 - Dependências Atualizadas
Guidance Body
Projeto
8.2 Identificar Scrum Master

Scrum Master e os 10.1 Criar
Business Entregáveis
Stakeholders
8.3 Formar o Scrum Scrum Team

Team
9.3 Comprometer Duração da Sprint Registro de

Histórias de Entregáveis Impedimento
Usuário da Sprint Atualizado
11.1 Demonstrar e 10.2 Conduzir a

Scrumboard e
Validar a Sprint Reunião Diária
Registro de
Impedimento
Passo 3.1 - Criar Entregáveis
Entradas
As entradas são:
▪ Sprint Backlog;
▪ Scrumboard;
▪ Registro de Impedimento;
▪ Cronograma de Planejamento da Release;
▪ Dependências;
▪ Recomendações do Scrum Guidance Body.
Ferramentas
Expertise do Time no Desenvolvimento
em Scrum
A expertise do time no contexto do
desenvolvimento Scrum refere-se à
experiência coletiva dos membros do Scrum
Team em compreender as Histórias de
Usuários e tarefas presentes no Sprint Backlog.
Essa experiência é essencial para a criação dos
entregáveis finais do projeto.
Considerações Importantes
sobre a Expertise do Time
▪ Entendimento Profundo:
O conhecimento profundo dos membros do Scrum
Team sobre Histórias de Usuários e tarefas do Sprint
Backlog é fundamental para avaliar as entradas
necessárias na execução do trabalho planejado no
projeto.
▪ Julgamento e Expertise Aplicados:
O julgamento e a Expertise do Time são aplicados a
todos os aspectos técnicos e de gerenciamento do
projeto. Os membros do Scrum Team têm a autoridade
de determinar os melhores meios para converter os
Itens do Product Backlog em produtos acabados.
Considerações Importantes
sobre a Expertise do Time
▪ Scrum Guidance Body:
Pode fornecer orientação sobre regras
documentadas, diretrizes de desenvolvimento,
regulamentos, padrões e melhores práticas para a
criação dos entregáveis.
▪ Ferramentas de Desenvolvimento:
Além da expertise humana, outras ferramentas de
desenvolvimento podem ser empregadas com base
nos requisitos do projeto.
Saídas
▪ Entregáveis da Sprint
Ao término de cada Sprint, um Incremento do produto,
também conhecido como Entregável, é finalizado.
O Entregável deve incorporar todas as características
e funcionalidades especificadas nas Histórias de
Usuário incluídas no Sprint. Ele deve ser testado com
sucesso.
▪ Scrumboard Atualizado
O Scrumboard é atualizado regularmente à medida que
o time completa as tarefas durante a Sprint. Ao final da
Sprint, o Scrumboard é resetado, e um novo é criado
para a próxima Sprint.
Saídas
▪ Registro de Impedimento Atualizado
É uma ferramenta importante para rastrear e
gerenciar impedimentos que afetam o progresso da
equipe. Detalhes sobre impedimentos e ações
tomadas para resolvê-los, são mantidos atualizados
para fornecer clareza sobre os desafios enfrentados.
▪ Solicitações de Mudança Não Aprovadas
É importante documentar e comunicar claramente as
mudanças propostas que não foram aceitas para
manter a transparência no processo decisório.
Saídas
▪ Riscos Identificados:
A equipe Scrum documenta os riscos identificados
durante a criação dos entregáveis para garantir uma
abordagem proativa na gestão de possíveis problemas.
▪ Mitigação de Riscos:
Conforme a equipe Scrum avança na criação dos
Entregáveis, são implementadas ações de mitigação
previamente definidas para lidar com riscos
identificados. O registro de riscos é mantido
atualizado ao longo do projeto.
▪ Dependências Atualizadas
As dependências entre tarefas e atividades são
monitoradas e atualizadas conforme necessário.
Exemplo 3.1 -
Criando
Entregáveis
Exemplo 3.1 - Criando Entregáveis
Uma equipe de estilistas e designers de moda decide
adotar a metodologia ágil Scrum para o lançamento
de sua nova coleção de verão. A equipe é composta
por estilistas, designers gráficos, costureiros e um
Scrum Master.
O Product Owner é o líder da equipe de design, e o
objetivo é criar uma coleção inovadora, otimizando
o processo de criação e entrega.
Product Owner (Dono do Produto)
▪ Nome: Carla - Pesquisadora de Moda e consumo
▪ Responsabilidades:
▪ Representa os interesses dos clientes e do
mercado de moda;
▪ Define a visão e as prioridades da nova
coleção de verão;
▪ Colabora com os designers para traduzir as
tendências de moda em itens do Product
Backlog.
Scrum Master
▪ Nome: Marcos - Facilitador
▪ Responsabilidades:
▪ Garante que a equipe esteja aderindo aos
princípios e práticas do Scrum;
▪ Remove impedimentos que possam surgir
durante o processo de criação da coleção;
▪ Facilita uma colaboração eficaz entre os
membros da equipe.
Time de Desenvolvimento
(Estilistas e Designers)
▪ Membros:
▪ Sofia - Estilista;
▪ André - Designer de Moda;
▪ Rafaela - Designer de Estampas;
▪ Guilherme - Modelista;
▪ Camila - Assistente de Criação.
Responsabilidades do
Time de Desenvolvimento
▪ Colaboram na criação e design de peças para
a nova coleção;
▪ Trabalham em estreita colaboração para
garantir que as peças estejam alinhadas com
a visão de Carla;
▪ São responsáveis por transformar os itens do
Product Backlog em peças reais.
Histórias de Usuários
História de Usuário 1: Tendências de Moda (Pontuação: 8)

Tarefas:
▪ Pesquisar as tendências atuais no mercado;
▪ Criar um documento de referência visual;
▪ Reunião com Carla Fashionista para alinhamento.
História de Usuário 2: Design de Peças-Chave (Pontuação: 13)
Tarefas:
▪ Sessões de brainstorming para conceber designs inovadores;
▪ Criar esboços e protótipos;
▪ Apresentar os designs para revisão.
História de Usuário 3: Desenvolvimento de Protótipos (Pontuação: 10)
Tarefas:
▪ Selecionar tecidos e materiais;
▪ Produzir protótipos das peças selecionadas;
▪ Realizar testes de vestibilidade.
História de Usuário 4: Ajustes e Aprimoramentos (Pontuação: 5)
Tarefas:
▪ Implementar feedback recebido;
▪ Fazer ajustes nos designs conforme necessário.
História de Usuário 5: Documentação Fotográfica (Pontuação: 8)
Tarefas:
▪ Organizar sessões de fotos para as peças;
▪ Editar e selecionar fotos para catálogo.
História de Usuário 6: Preparação para o Lançamento (Pontuação: 7)
Tarefas:
▪ Criar materiais promocionais;
▪ Planejar eventos de lançamento.
Atividades Recorrentes
Tarefas:
▪ Reuniões Diárias: 15 minutos todas as manhãs para atualizações rápidas;
▪ Reuniões de Revisão da Sprint: ao final de cada sprint para revisar e validar o
trabalho concluído.
Scrumboard Atualizado
Carla conduz o time para em uma reunião produzirem o Scrumboard Atualizado:
A fazer Em andamento Em revisão Concluído

Ajustes e Desenvolvimento Design de Tendências de
Aprimoramento de Protótipos Peças-Key Moda
Documentação Preparação para
Fotogr. Lançamento
Passo 3.2 -
Conduzir a
Reunião Diária
Processo para Conduzir a Reunião
Diária:
1 - Time Central do Scrum 1 - Reunião Diária 1 - Scrumboard Atualizado

2 - Scrum Master 2 - Três Perguntas Diárias 2 - Registro de Impedimento
Atualizado
3 - Scrumboard 3 - Sala de Guerra
3 - Gráfico de Burndown ou
4 - Gráfico de Burndown ou 4 - Videoconferência Burnup Atualizado
Burnup da Sprint 5 - Ferramentas do Projeto 4 - Scrum Team Motivado
5 - Registro de Impedimento Scrum 5 - Solicitações de Mudanças
6 - Product Owner Não Aprovadas
7 - Experiência do Dia 6 - Riscos Identificados
Anterior de Trabalho 7 - Riscos Mitigados
8 - Dependências 8 - Dependências Atualizadas
8.2 Identificar
Scrum Master
Scrum Master e os
Business
Stakeholders
10.2 Conduzir
Scrumboard
8.3 Formar o Scrum Scrum Team a Reunião
Atualizado
Team Diária
9.3 Comprometer Scrumboard

Histórias de
Usuário
10.1 Criar
Entregáveis Gráfico de Burndown ou Gráfico de Burndown ou
Burnup da Sprint Burnup Atualizado
Registro de Registro de
Impedimento Impedimento
Entradas
As entradas são:
▪ Time Scrum;
▪ Scrum Master;
▪ Scrumboard;
▪ Gráfico de Burndown ou Burnup da Sprint;
▪ Registro de Impedimento;
▪ Dono do Produto;
▪ Experiência do Dia Anterior de Trabalho;
▪ Dependências.
Ferramentas
▪ Reunião Diária
▪ É uma breve reunião com duração fixa de 15
minutos no contexto do Scrum;
▪ Todos os membros do Scrum Team participam,
mesmo que alguns membros estejam ausentes;
▪ Gerenciada pelo Scrum Team, o Scrum Master pode
facilitar a reunião conforme necessário;
▪ Durante a reunião, os membros respondem às Três
Perguntas Diárias para compartilhar o progresso e
planejar as atividades do dia;
▪ As discussões mais detalhadas ocorrem após a
reunião para manter a brevidade do encontro.
Ferramentas
▪ Três Perguntas Diárias
Durante a Reunião Diária, os membros respondem a
três perguntas específicas:
▪ O que eu fiz ontem?
▪ O que eu vou fazer hoje?
▪ Quais impedimentos ou obstáculos estou
enfrentando atualmente?
A resposta a essas perguntas fornece uma
compreensão clara do status do trabalho e promove a
transparência.
Ferramentas
▪ Sala de Guerra
▪ Projetada para facilitar a comunicação,
colaboração e resolução de problemas, a sala
promove a interação fácil entre os membros;
▪ Ferramentas simples, como cartões de índice e
notas, são usadas para apoiar o fluxo de trabalho;
▪ A comunicação "cara a cara" é enfatizada, e a sala é
ideal para realizar Reuniões Diárias;
▪ Business Stakeholders e membros de outros Scrum
Teams podem circular na Sala de Guerra para
discussões relevantes.
Saídas
▪ Scrumboard Atualizado
▪ O Scrumboard é continuamente atualizado à
medida que a equipe completa tarefas;
▪ Essa atualização é parte regular do
acompanhamento do progresso da equipe no
Scrum.
Saídas
▪ Registro de Impedimento Atualizado
⬝ Detalhes sobre impedimentos são atualizados
conforme necessário.
▪ Gráfico de Burndown ou Burnup da Sprint:
⬝ O Gráfico de Burndown da Sprint é atualizado
diariamente para refletir o progresso da equipe;
⬝ Permite a detecção de estimativas incorretas e
ajuda a identificar obstáculos para o término
bem-sucedido da Sprint.
Saídas
▪ Scrum Team Motivado
⬝ As Reuniões Diárias reforçam a
importância de cada membro do time;
⬝ O conceito de times auto-organizados e a
valorização de cada contribuição melhoram
o moral e a motivação;
⬝ A motivação resultante contribui para um
melhor desempenho e qualidade dos
entregáveis do time.
Exemplo 3.2 -
Conduzindo a
Reunião
Diária
Exemplo 3.2 -
Conduzindo a Reunião Diária
O Scrum Team de Design de Moda incorporou a
metodologia ágil Scrum em sua rotina diária para
melhorar a eficiência e a colaboração.
Nessa aula apresentaremos como a equipe passou
pela Reunião Diária.
Local de Trabalho - Sala de Guerra
A equipe organizou sua Sala de Guerra em um
espaço aberto, facilitando a comunicação, a
colaboração e a resolução rápida de problemas.
Os membros estavam fisicamente próximos,
usando ferramentas simples como cartões de
índice e notas para apoiar o fluxo de trabalho.
Essa configuração proporcionou uma interação
fácil entre os membros da equipe, enfatizando a
comunicação "cara a cara".
Estrutura da Reunião Diária
▪ Realizada diariamente, com duração fixa de 15
minutos;
▪ Todos os membros do Scrum Team, incluindo
designers, estilistas e outros membros
relevantes, participavam da reunião, mesmo que
alguns estivessem ausentes;
▪ A reunião era gerenciada pelo próprio Scrum
Team, com Marcos, o Scrum Master facilitando
conforme necessário.
Três Perguntas Diárias
Durante a Reunião Diária, os membros do Scrum
Team respondiam às Três Perguntas Diárias para
compartilhar o progresso e planejar as atividades do
dia. As respostas forneciam uma compreensão clara
do status do trabalho e ajudavam a identificar
possíveis impedimentos. As perguntas eram:
▪ O que eu fiz ontem?
▪ O que eu vou fazer hoje?
▪ Quais impedimentos ou obstáculos estou
enfrentando atualmente?
Exemplo de Guilherme (Modelista)
resposta das três perguntas
1. O que eu fiz ontem?
▪ "Ontem, finalizei os esboços dos modelos para a coleção de verão. Realizei uma
reunião com a equipe de costura para alinhar os detalhes técnicos e ajustes
necessários nas peças."
2. O que eu vou fazer hoje?

▪ "Hoje, pretendo começar a criação dos moldes para a produção. Vou revisar as
sugestões da equipe de design e começar a prototipagem de duas peças-chave.”
3. Quais impedimentos ou obstáculos estou enfrentando atualmente?

▪ "Estou enfrentando um atraso na entrega dos tecidos específicos para os protótipos.
Isso pode impactar o cronograma, e estou coordenando com o responsável pelos
suprimentos para resolver essa questão o mais rápido possível."
Discussões Detalhadas
Após a Reunião Diária, se surgissem questões ou se
fosse necessário um aprofundamento em
determinados tópicos, a equipe realizava discussões
mais detalhadas. Isso era feito de forma a manter a
brevidade da Reunião Diária e aprimorar a eficiência
global da equipe.
Exemplo: Após a Reunião Diária, o Scrum Team de
Design de Moda realizou discussões mais
detalhadas para abordar questões específicas e
planejar estratégias.
Exemplo de Discussões Detalhadas
Tópico: atraso na Entrega dos Tecidos;
Problema Identificado: durante a Reunião Diária,
Guilherme mencionou um atraso na entrega dos
tecidos específicos para os protótipos;
Discussão Detalhada: a equipe discutiu a gravidade
do atraso e seu impacto no cronograma geral do
projeto. Foram identificadas possíveis soluções,
como procurar fornecedores alternativos ou
priorizar outros aspectos da produção enquanto
aguardam a entrega.
Exemplo de Discussões Detalhadas
Ações Planejadas: O Scrum Team decidiu realizar
uma reunião extra com o responsável pelos
suprimentos para entender as razões do atraso e
buscar soluções imediatas. Além disso, foi decidido
realocar recursos para atividades que não
dependiam dos tecidos específicos, mantendo o
fluxo de trabalho.
Sala de Guerra como
Espaço Colaborativo
A Sala de Guerra não era apenas o local para a
Reunião Diária, mas também um espaço
colaborativo para discussões contínuas.
Business Stakeholders e membros de outros Scrum
Teams podiam circular na Sala de Guerra para
participar de discussões relevantes, promovendo
uma colaboração mais ampla.
Na reunião eles atualizam o Scrumboard
A fazer Em andamento Em revisão Concluído
Ajustes e Desenvolvimento de
Tendências de Moda
Aprimoramentos Protótipos
Documentação Preparação para Design de

Fotogr. Lançamento Peças-Key
E produziram o gráfico de Burnup
Exemplo 3.2 -
Conduzindo a Reunião Diária
Essa abordagem ajudou o Scrum Team de Design de
Moda a manter uma visão clara do progresso diário,
facilitando a comunicação e a resolução de
problemas de maneira rápida e eficiente.
Passo 3.3 -
Refinar o
Product Backlog
Processo para Refinar o Product Backlog:

1 - Time Central do Scrum 1 - Reuniões de Revisão 1 - Product Backlog
2 - Product Backlog do Product Backlog Atualizado
3 - Business Stakeholders 2 - Técnicas de 2 - Cronograma de
4 - Histórias de Usuário Rejeitadas Comunicação Planejamento da
5 - Solicitações de Mudanças Aprovadas 3 - Outras Técnicas de Release Atualizado
6 - Solicitações de Mudanças Não Aprovadas Refinamento do Product
7 - Riscos Identificados Backlog
8 - Registro(s) de Retrospectiva da Sprint 4 - Ferramenta do
9 - Dependências Projeto Scrum
10 - Cronograma de Planejamento da Release
11 - Recomendações do Scrum Guidance Body
Projeto
10.3 Refinar o
8.2 Identificar Scrum Master Product Backlog
Scrum Master e os
Business
Stakeholders
Product Backlog
8.3 Formar o Scrum Scrum Team Atualizado
Team
9.1 Criar Histórias de

8.5 Criar o
Usuário
Product Backlog Product Backlog
Entradas
As entradas são:
▪ Product Backlog;
▪ Business Stakeholders;
▪ Histórias de Usuário Rejeitadas;
▪ Solicitações de Mudança Aprovadas;
▪ Solicitações de Mudança Não Aprovadas;
▪ Registro(s) de Retrospectiva da Sprint;
▪ Dependências;
Ferramentas
Reuniões de Revisão do Product Backlog
▪ O Product Owner realiza reuniões com
Stakeholders, Scrum Master e o Scrum Team para
atualizar o Product Backlog;
▪ Garante compreensão adequada das Histórias
de Usuário e seus Critérios de Aceitação;
▪ Certifica-se de que as Histórias de Usuário
estejam alinhadas com os requisitos e
prioridades do cliente;
▪ Remove Histórias de Usuário irrelevantes e
incorpora Solicitações de Mudança Aprovadas
e riscos identificados.
Ferramentas
Técnicas de Comunicação
▪ Scrum favorece a comunicação precisa e eficaz,
principalmente através da colocação do Scrum
Team;
▪ Enfatiza interações informais "cara a cara" em
vez de comunicações escritas formais;
▪ Em equipes distribuídas, o Scrum Master
garante a disponibilidade de técnicas eficazes
de comunicação e Ferramentas de Projeto
Scrum.
Saídas
Product Backlog Atualizado
▪ Pode ser atualizado com novas ou atualizadas
Histórias de Usuário, trabalho relacionado a
Solicitações de Mudança ou riscos
identificados;
▪ Reflete a repriorização das Histórias de
Usuário existentes;
▪ Essencial para manter o alinhamento do
backlog com as necessidades do cliente.
Saídas
Cronograma de Planejamento da Release
Atualizado
▪ Pode ser atualizado para refletir o
impacto de Histórias de Usuário novas
ou alteradas no Product Backlog;
▪ Importante para ajustar o plano de
lançamento de acordo com as mudanças
no backlog.
Exemplo 3.3 -
Refinando o
Product Backlog
Exemplo 3.3 - Refinando o
Product Backlog
Os Stakeholders e o Scrum Team participam de uma
reunião de revisão do Product Backlog.
Além da revisão, identificam-se Histórias de Usuário
que precisam ser discutidas, removidas, ajustadas ou
incorporadas.
Durante a reunião, Carla, Product Owner, apresenta as
Histórias de Usuário selecionadas, detalhando seus
Critérios de Aceitação e relevância para os objetivos
do cliente.
Exemplo 3.3 - Refinando
o Product Backlog
Ocorrem discussões interativas para garantir uma
compreensão completa das Histórias de Usuário.
Perguntas são feitas, esclarecimentos são
fornecidos, e é incentivado o diálogo aberto.
Com base nas discussões, o Carla realiza ajustes no
Product Backlog, removendo Histórias de Usuário
irrelevantes e incorporando solicitações de
mudança aprovadas.
Carla, com insights do Scrum Team, reavalia a
priorização do backlog, garantindo que as Histórias
de Usuário mais importantes estejam no topo.
Product Backlog - Atualizado
História de Usuário: Quero Produtos de Alta Qualidade e Durabilidade

Critérios de Aceitação:
▪ Materiais premium;
▪ Garantia estendida.
História de Usuário: Quero Participar de Campanhas Exclusivas para Membros

▪ Cadastro simples para adesão;
▪ Ofertas exclusivas para membros.
História de Usuário: Quero Acesso Antecipado às Novas Coleções
▪ Notificações exclusivas para membros;
▪ Janela de compra antes do lançamento público.
História de Usuário: Quero Detalhes sobre o Processo de Fabricação
Sustentável
▪ Seção informativa no site;
▪ Certificações de práticas sustentáveis.
História de Usuário: Quero Conteúdo de Estilo e Combinações de Produtos
▪ Blog de estilo no site;
▪ Sugestões de combinações de produtos.
Passo 4 -
Revisar e
Realizar a
Retrospectiva
Passo 4 - Revisar e Realizar
a Retrospectiva
Para melhor aprofundamento desta etapa,
iremos dividi-la em 2 Sub Passos:
▪ Passo 4.1 - Demonstrar e Validar a Sprint:
Neste Passo, os membros do Scrum Team
apresentam os Entregáveis criados durante a Sprint.
A Reunião de Revisão da Sprint é realizada, onde o
Scrum Team e Stakeholders principais participam. O
objetivo é demonstrar as Histórias de Usuário e
outros entregáveis concluídos durante a Sprint. O
Product Owner valida as Histórias de Usuário com
base nos Critérios de Aceitação, aceitando ou
rejeitando as entregas.
Passo 4 - Revisar e
Realizar a Retrospectiva
Passo 4.2 - Retrospectiva da Sprint:
A Retrospectiva da Sprint é uma reunião realizada Sprint Retro
pelo Scrum Team para refletir sobre o desempenho da
Sprint que acabou de ser concluída. Durante a
Retrospectiva, os membros discutem o que funcionou
bem, o que pode ser melhorado e quais ações podem
ser implementadas na próxima Sprint para melhorar o
processo. É uma oportunidade para ajustar e
aprimorar continuamente o trabalho do time. O Scrum Scrum Team
Master media a Retrospectiva, e as informações
coletadas são usadas para melhorar o processo e a
colaboração na próxima Sprint.
Passo 4.1 -
Demonstrar e
Validar a Sprint
Passo 4.1 - Demonstrar e
Validar a Sprint
Relembrando:
Sprint é um período de tempo fixo durante o qual uma
equipe de desenvolvimento trabalha para entregar um
conjunto incrementado e potencialmente entregável
de funcionalidades.
As Sprints são a unidade básica de tempo no Scrum e
geralmente têm uma duração de duas a quatro
semanas. Durante uma Sprint, a equipe se concentra
em construir, testar e entregar um incremento do
produto.
Processo para Demonstrar e Validar a Sprint:

1 - Time Central do Scrum 1 - Aceitação/ Rejeição 1 - Histórias de Usuários
2 - Entregáveis da Sprint das Histórias de Aceitas
3 - Sprint Backlog Usuário 2 - Histórias de Usuários
4 - Critério de Pronto 2 - Reuniões de Revisão Rejeitadas
da Sprint 3 - Riscos Atualizados
5 - Critérios de Aceitação de Histórias do
3 - Análise de Valor 4 - Resultado da Análise
Usuário
Agregado de Valor Agregado
6 - Business Stakeholders
4 - Expertise do Scrum 5 - Cronograma de
7 - Cronograma de Planejamento da Release Guidance Body Planejamento da Release
8 - Riscos Identificados 5 - Ferramentas do Atualizado
9 - Dependências Projeto Scrum
10 - Recomendações do Scrum Guidance Body
8.1 Criar a Visão do
Projeto
8.2 Identificar Scrum

Master e os Business
Stakeholders 11.1 Demonstrar e
Validar a Sprint
8.3 Formar o Scrum
Team
8.5 Criar o
Product Backlog Histórias de
Usuários Aceitas
9.1 Criar Histórias de
Usuário
9.3 Comprometer
Histórias de Usuário 11.3
12.1 Envio de
Retrospectiva da
Entregáveis
10.1 Criar Entregáveis Sprint
Entrada
As entradas são:
▪ Entregáveis da Sprint;
▪ Sprint Backlog;
▪ Critério de Pronto;
▪ Business Stakeholder(s);
▪ Dependências;
Ferramentas
▪ Aceitação/Rejeição da História de Usuário
▪ Após a conclusão, as Histórias de Usuário são
disponibilizadas para revisão pelo Product Owner;
▪ A revisão pode ocorrer imediatamente após a
conclusão ou durante a Reunião de Revisão da
Sprint;
▪ O Product Owner aceita as Histórias de Usuário que
atendem aos Critérios de Aceitação e Critérios de
Pronto;
Ferramentas
▪ Aceitação/Rejeição da História de Usuário
▪ As Histórias que não atendem a esses critérios são
rejeitadas, idealmente com feedback sobre os
motivos da rejeição;
▪ Se houver tempo na Sprint, a equipe pode corrigir
as Histórias rejeitadas e submetê-las novamente
para revisão no mesmo Sprint;
▪ Algumas Histórias de Usuário podem permanecer
rejeitadas no final da Sprint, sendo tratadas na
Sprint subsequente.
Ferramentas
▪ Reuniões de Revisão da Sprint
▪ Convocadas no final de cada Sprint;
▪ Participação do Time Central do Scrum e principais
Business Stakeholders;
▪ Apresentação dos entregáveis, incluindo as novas
funcionalidades ou produtos criados durante a
Sprint;
▪ Demonstração das Histórias de Usuário
previamente aprovadas pelo Product Owner;
Ferramentas
▪ Reuniões de Revisão da Sprint
▪ Product Owner e Stakeholders inspecionam os
entregáveis e decidem se mudanças são
necessárias em Sprints subsequentes.
▪ No final, algumas Histórias de Usuário são
aprovadas e outras rejeitadas com base nos
Critérios de Aceitação e Critérios de Pronto.
Saídas
▪ Histórias de Usuário Aceitas

▪ Objetivo: garantir que as entregas da Sprint
atendam aos Critérios de Aceitação da História
do Usuário definidos pelo cliente e Product
Owner;
▪ Processo:
▪ Conclusão das Histórias de Usuário:
após o desenvolvimento, as Histórias de
Usuário são disponibilizadas para revisão;
Saídas
▪ Histórias de Usuário Aceitas
▪ Avaliação pelo Dono do Produto: o Product
Owner revisa as Histórias de Usuário para
verificar se atendem aos Critérios de Aceitação;
▪ Aceitação Formal: se uma História de Usuário
atende aos critérios, o Product Owner a
formalmente aceita;
▪ Registro de Histórias Aceitas: as Histórias de
Usuário aceitas são registradas em uma lista
atualizada, indicando que estão prontas para
serem liberadas ao cliente, se necessário.
Saídas
▪ Histórias de Usuário Rejeitadas
▪ Objetivo: tratar as Histórias de Usuário que não
atendem aos Critérios de Aceitação;
▪ Processo:
▪ Identificação de Não Conformidades: se
uma História de Usuário não atende aos
Critérios de Aceitação, é rejeitada pelo
Product Owner;
▪ Adição ao Backlog Priorizado do
Produto: As Histórias de Usuário rejeitadas
são adicionadas de volta ao Product
Backlog;
Saídas
▪ Histórias de Usuário Rejeitadas
▪ Tratamento em Sprint Subsequente: as Histórias de
Usuário rejeitadas podem ser consideradas para
inclusão em uma Sprint futura;
▪ Conclusão dos Entregáveis: os entregáveis
associados às Histórias de Usuário rejeitadas são
considerados incompletos. O trabalho neles pode
ser retomado por qualquer Scrum Team no futuro;
▪ Reavaliação da Estimativa: a estimativa para a
conclusão das Histórias de Usuário rejeitadas pode
ser ajustada com base no trabalho já realizado, e os
entregáveis parcialmente concluídos podem ser
considerados ou ignorados em futuras Sprints.
Exemplo 4.1 -
Demonstrando e
Validando a
Sprint
Exemplo 4.1 - Demonstrando
e Validando a Sprint
Uma startup chamada Travelify decidiu desenvolver
um aplicativo de viagens personalizado para oferecer
aos usuários uma experiência única ao planejar suas
viagens. A equipe optou por adotar a metodologia
Scrum para este projeto.
Rafael, o Product Owner do projeto Travelify, estava a
frente desse desafio. Consciente das dificuldades
inerentes ao desenvolvimento de software, ele estava
determinado a escolher uma metodologia ágil que
permitisse flexibilidade, feedback constante e entregas
incrementais.
Scrum Team
▪ Product Owner: Rafael (Representando os
interesses dos usuários finais);
▪ Scrum Master: Sofia;
▪ Time de Desenvolvimento:
○ Julia (Desenvolvedora);
○ Pedro (Desenvolvedor);
○ Fernanda (Testadora);
○ André (Designer).
Scrum Team
A interação constante entre o Scrum Team era
crucial.
As reuniões regulares de Revisão da Sprint e a
oportunidade de ajustar o backlog após cada Sprint
proporcionavam uma abordagem iterativa que
garantia o alinhamento contínuo com as
expectativas do cliente.
Product Backlog
História de Usuário (HU1):

Como usuário, quero uma interface intuitiva para pesquisar e planejar minhas
viagens.

Como usuário, quero receber recomendações personalizadas com base em minhas
preferências de viagem.

Como usuário, quero um sistema de reserva fácil e seguro integrado ao aplicativo.

Como usuário, quero notificações em tempo real sobre ofertas e atualizações de
viagens.
Product Backlog

Como usuário, quero um diário de viagem digital para documentar minhas
experiências.

Como usuário, quero integração do app com as redes sociais.

Como usuário, quero um sistema de gamificação do uso do app para recebimento
de benefícios.
Sprints
O projeto foi dividido em sprints de três semanas, cada
uma focada em entregar incrementos de funcionalidades.
Sprint 1
▪ Objetivo: desenvolver a interface de pesquisa;
▪ Desenvolvimento: Júlia e Pedro colaboraram na criação de uma interface intuitiva,
enquanto Fernanda e André ofereceram feedback constante;
▪ Resultado: HU1 concluída, interface de pesquisa eficiente.
Sprint 2
▪ Objetivo: implementar sistema de recomendações personalizadas;
▪ Desenvolvimento: André e Júlia trabalharam no algoritmo de recomendação,
ajustando-o com base no feedback de Fernanda e Pedro;
▪ Resultado: HU2 concluída, recomendações personalizadas disponíveis.
Sprints
Sprint 3
▪ Objetivo: integração do sistema de reserva;
▪ Desenvolvimento: todos os membros colaboraram para integrar um sistema de
reserva seguro;
▪ Resultado: HU3 concluída, sistema de reserva fácil para os usuários.
Sprint 4
▪ Objetivo: implementar notificações em tempo real;
▪ Desenvolvimento: Pedro liderou a implementação das notificações, enquanto
Fernanda realizou testes extensivos;
▪ Resultado: HU4 concluída, usuários recebem notificações relevantes.
Sprints
Sprint 5
▪ Objetivo: desenvolver o diário de viagem digital;
▪ Desenvolvimento: Júlia e André trabalharam no diário, incorporando
feedback de Fernanda e Pedro;
▪ Resultado: HU5 concluída, usuários podem documentar suas viagens.
Histórias de Usuários Aceitas
Guiados por Rafael e Sofia, o Scrum Team separou as Histórias de Usuários Aceitas:
História de Usuário (HU1): Como usuário, quero uma interface intuitiva para pesquisar
e planejar minhas viagens.
▪ Decisão: Aceita;
▪ Razão: a interface intuitiva foi implementada conforme os critérios de aceitação,
proporcionando uma experiência amigável para os usuários.
História de Usuário (HU2): Como usuário, quero receber recomendações
personalizadas com base em minhas preferências de viagem.
▪ Decisão: aceita;
▪ Razão: o sistema foi configurado para fornecer recomendações personalizadas,
atendendo aos critérios de aceitação.
História de Usuário (HU3): Como usuário, quero um sistema de reserva fácil e

seguro integrado ao aplicativo.
▪ Razão: um sistema de reserva fácil e seguro foi integrado com sucesso,
atendendo às expectativas dos usuários.
História de Usuário (HU4): Como usuário, quero notificações em tempo real
sobre ofertas e atualizações de viagens.
▪ Razão: o sistema foi implementado para fornecer notificações em tempo real,
proporcionando aos usuários informações atualizadas sobre ofertas e
atualizações.
História de Usuário (HU5): Como usuário, quero um diário de viagem

digital para documentar minhas experiências.
▪ Razão: um diário de viagem digital foi desenvolvido e integrado ao
aplicativo, permitindo aos usuários documentar suas experiências de
viagem.
Histórias de Usuários Rejeitadas
Eles também separaram as Histórias de Usuários Rejeitadas:
História de Usuário: Como usuário, quero integração do app com as redes sociais.
▪ Critérios de Aceitação:
▪ Os usuários podem compartilhar automaticamente detalhes de suas viagens
nas redes sociais;
▪ Opções de privacidade são fornecidas.
▪ Status: rejeitada;
▪ Razão: a integração com redes sociais não atendeu aos critérios de aceitação
devido a preocupações de privacidade identificadas durante a revisão.
Histórias de Usuários Rejeitadas
História de Usuário: Como usuário, quero um sistema de gamificação do uso do app

para recebimento de benefícios.
▪ Critérios de Aceitação:
▪ Os usuários ganham pontos e distintivos com base em suas atividades de viagem;
▪ Classificação competitiva entre os usuários.
▪ Status: rejeitada;
▪ Razão: a funcionalidade de gamificação foi rejeitada devido a considerações de
simplicidade e foco nas necessidades essenciais dos usuários.
Passo 4.2 -
Retrospectiv
a da Sprint
Passo 4.2 - Retrospectiva da Sprint
Nesse momento pós-Sprint, o Scrum Time se reúne para
discutir as lições aprendidas ao longo da Sprint.
Durante essa reunião, são abordados temas como os
desafios enfrentados, sucessos alcançados e
oportunidades de melhoria identificadas durante o
ciclo de trabalho.
Essas lições aprendidas são registradas, criando um
acervo de insights que servirá como referência para
Sprints futuras.
Processo para a Retrospectiva da Sprint:
1 - Scrum Master 1 - Reunião de 1 - Pontos de Melhoria Acordados

2 - Scrum Team Retrospectiva da Sprint 2 - Itens de Ação Atribuída e Datas
2 - ESVP de Vencimento
3 - Saídas de Demonstrar e
Validar a Sprint 3 - Lancha 3 - Itens Não Funcionais Propostos
para o Product Backlog
4 - Product Owner 4 - Técnicas de Medição
4 - Registros de Retrospectiva da
5 - Recomendações do 5 - Expertise do Scrum Sprint
Scrum Guidance Body Guidance Body
5 - Lições Aprendidas pelo Scrum
6 - Ferramentas do Projeto Team
Scrum
6 - Recomendações Atualizadas do
Scrum Guidance Body
Stakeholders
11.2 Retrospectiva
da Sprint
8.3 Formar o
Scrum Team
11.1 Demonstrar e
Validar a Sprint Pontos de
Melhorias
Acordados
Entradas
As entradas são:
▪ Scrum Master;
▪ Scrum Team;
▪ Saídas de Demonstrar e Validar a Sprint;
▪ Product Owner;
Ferramentas
Reunião de Retrospectiva da Sprint:
Baseada em inspecionar e adaptar, esta reunião
representa a etapa final de uma Sprint, envolvendo a
participação de todos os membros do Scrum Team,
com o Scrum Master moderando o processo.
Embora a presença do Product Owner seja
recomendada, não é obrigatória. Durante a reunião,
um membro do time atua como escrivão,
documentando as discussões e os itens identificados
para ações futuras.
Ferramentas
Reunião de Retrospectiva da Sprint:
A atmosfera da Reunião deve ser aberta e descontraída,
promovendo a participação dos membros da equipe. As
discussões abordam tanto os aspectos positivos quanto
os desafios enfrentados durante a Sprint. O objetivo é
identificar três categorias específicas de itens:
▪ Coisas que o time precisa continuar fazendo
(melhores práticas);
▪ Coisas que o time precisa começar a fazer
(melhorias de processo;
▪ Coisas que o time precisa parar de fazer
(problemas do processo e gargalos).
Ferramentas
ESVP:
O Explorer—Shopper—Vacationer—Prisoner (ESVP) é
um exercício realizado no início da Reunião de
Retrospectiva da Sprint para compreender a
mentalidade dos participantes e orientar a direção
da reunião.
Os membros do time são convidados a indicar
anonimamente qual papel melhor representa sua
visão na retrospectiva.
ESVP
Os quatro perfis são:

▪ Explorer (Explorador): Quer participar e aprender tudo o que foi discutido na
retrospectiva. Está aberto a explorar e absorver o máximo possível;
▪ Shopper (Comprador): Quer ouvir todas as discussões e escolher conscientemente o

que pode extrair da retrospectiva. Tem uma abordagem seletiva;
▪ Vacationer (Turista): Deseja relaxar e ser mais passivo na retrospectiva, como se

estivesse em férias. Pode não estar tão envolvido ativamente;
▪ Prisoner (Prisioneiro): Preferiria estar em outro lugar e está participando da

retrospectiva apenas porque é uma obrigação. Pode não estar totalmente engajado.
Ferramentas
ESVP:
O Scrum Master coleta as respostas de forma
anônima, compila as informações e compartilha os
resultados com o grupo.
Essa dinâmica ajuda a compreender as atitudes e
expectativas dos membros da equipe, permitindo
uma abordagem mais personalizada na condução da
Reunião de Retrospectiva da Sprint.
Ferramentas
Lancha:
Nesse exercício, os membros do time assumem os
papéis da tripulação de uma lancha, cujo objetivo é
chegar a uma ilha simbolicamente representando a
Visão do Projeto. Durante o exercício, os participantes
utilizam post-its para indicar "motores" e "âncoras":
▪ Motores: representam as coisas que impulsionam
o time em direção à ilha, ou seja, fatores positivos
que contribuem para o sucesso;
▪ Âncoras: são as coisas que atuam como
obstáculos, impedindo o progresso do time em
direção à ilha.
Ferramentas
Lancha:
O exercício tem um tempo limitado, geralmente
apenas alguns minutos. Após esse período, todos os
itens são documentados. A informação é então
coletada, discutida e priorizada por meio de um
processo de votação. Com base na prioridade
atribuída, são identificados os motores mais
significativos, enquanto ações de mitigação são
planejadas para lidar com as âncoras.
Essa abordagem ajuda a equipe a refletir sobre o que
impulsionou o sucesso e o que impediu o progresso.
Ferramentas
Técnicas de Medição:
São instrumentos utilizados para avaliar e comparar o
desempenho do time durante a Sprint atual em relação
a Sprints anteriores. Algumas dessas técnicas incluem:
▪ Velocidade do Time;
▪ Taxa de Sucesso de Pronto;
▪ Eficácia da Estimativa;
▪ Revisão das Classificações de Feedback;
▪ Classificações da Moral do Time;
▪ Feedback dos Membros do Time;
▪ Progresso para Release ou Lançamento.
Saídas
Pontos de Melhoria Acordados:
Uma lista dos pontos de melhoria identificados pela
equipe para resolver problemas e aprimorar os
processos que busca melhorar o desempenho da
equipe nas próximas Sprints, promovendo uma
cultura de melhoria contínua.
Saídas
Itens de Ação Atribuída e Datas de
Vencimento:
▪ A equipe identifica ações práticas que podem ser
realizadas para abordar os pontos de melhoria
acordados;
▪ Cada item de ação é atribuído a membros
específicos da equipe Scrum. Isso garante clareza
sobre quem é responsável por executar cada ação;
▪ Cada item de ação é associado a uma data de
vencimento clara e específica. Estabelecer prazos
ajuda a manter o foco e a responsabilidade,
garantindo que as ações sejam concluídas em
tempo hábil.
Saídas
Itens Não Funcionais Propostos para o Backlog
Priorizado do Produto:
Referem-se a requisitos que não se enquadram
estritamente na categoria de funcionalidades
diretas ou Histórias de Usuários. Enquanto o
Product Backlog inicialmente se concentra em
Histórias de Usuários e funcionalidades essenciais,
itens não funcionais podem surgir ao longo do
tempo, especialmente durante as Reuniões de
Revisão da Sprint ou de Retrospectiva da Sprint.
Saídas
Itens Não Funcionais Propostos para o
Backlog Priorizado do Produto:
Assim que os requisitos não funcionais são
descobertos, eles devem ser adicionados ao
Product Backlog para garantir que sejam
considerados nas futuras iterações do
desenvolvimento;
À medida que a equipe avança no
desenvolvimento, novos requisitos não
funcionais podem surgir, e a inclusão contínua
no Product Backlog permite ajustes conforme
necessário.
Saídas
Registro(s) da Retrospectiva da Sprint:
Documento que registra as opiniões, discussões e
itens acionáveis identificados durante a Reunião de
Retrospectiva da Sprint no contexto do framework
Scrum.
O registro é criado para documentar as discussões e
insights provenientes da Reunião de Retrospectiva da
Sprint.
O Scrum Master geralmente atua como um facilitador
para garantir que as informações relevantes sejam
capturadas.
Saídas
Registro(s) da Retrospectiva da Sprint:
A criação do registro envolve a participação ativa dos
membros da equipe. Eles contribuem com suas
opiniões, identificam pontos de melhoria e discutem as
lições aprendidas ao longo da Sprint.
O registro não se limita apenas a problemas ou
desafios enfrentados pela equipe. Ele também inclui
sucessos, boas práticas e qualquer outra informação
considerada relevante para aprimorar o desempenho
futuro da equipe.
Saídas
Lições Aprendidas pelo Scrum Team:
Refere-se ao processo em que o time, após completar
uma Sprint no framework Scrum, reflete sobre as
experiências e aprendizados adquiridos durante o ciclo
de trabalho. O Scrum Team é incentivado a aprender
com os erros e desafios enfrentados durante a Sprint.
Essa abordagem visa a melhoria contínua e a correção
de práticas que não foram eficazes.
Em casos em que as melhorias vão além do alcance do
Scrum Team ou das recomendações do Scrum Guidance
Body, o envolvimento da Alta Administração e outros
stakeholders é importante.
Exemplo 4.2 -
Realizando a
Retrospectiva
da Sprint
Exemplo 4.2 - Realizando a
Retrospectiva da Sprint
O Scrum Team do Travelify realizou a Reunião de
Retrospectiva da Sprint com a dinâmica ESVP para
entender a mentalidade dos participantes e moldar a
direção da reunião.
Veremos como a dinâmica foi conduzida.
Preparação:
▪ Sofia, Scrum Master, explicou brevemente os
quatro perfis: Explorer, Shopper, Vacationer e
Prisoner.
▪ Foram distribuídos cartões para que cada
membro do time indicasse anonimamente qual
papel melhor representava sua visão na
retrospectiva.
Coleta Anônima:
▪ Os membros do time escreveram
anonimamente o perfil escolhido em seus
papéis ou cartões;
▪ O objetivo era garantir uma resposta franca
e honesta, sem influência dos outros
membros do time.
Na dinâmica, o perfil mais predominante foi o
"Explorer" (Explorador). Isso indica que a maioria dos
membros do time estava interessada em participar
ativamente, aprender e absorver o máximo possível
durante a retrospectiva.
Esse insight direcionou a abordagem da reunião,
focando em explorar as discussões de forma
aprofundada e facilitar um ambiente propício para
aprendizado e colaboração.
Após muitas discussões, chegaram na seguinte
classificação:
Coisas que o time precisa continuar
fazendo (melhores práticas)
▪ Realizar reuniões diárias curtas para manter
todos atualizados;
▪ Utilizar a Sala de Guerra como ambiente de
trabalho preferido, promovendo a comunicação
e colaboração;
▪ Atualizar diariamente o Gráfico de Burndown da
Sprint para monitorar o progresso;
▪ Manter a comunicação "cara a cara" enfatizada,
mesmo em equipes distribuídas.
Coisas que o time precisa começar a
fazer (melhorias de processo)
▪ Implementar um processo mais eficaz para
documentar e lidar com impedimentos;
▪ Introduzir uma revisão mais estruturada das
Histórias de Usuário antes do início da Sprint;
▪ Explorar ferramentas adicionais para melhorar
a comunicação em equipes distribuídas.
Coisas que o time precisa parar de fazer
(problemas do processo e gargalos)
▪ Interromper a prática de resolver impedimentos
fora da Reunião Diária;
▪ Parar de adiar a revisão de impedimentos
críticos;
▪ Evitar a dependência excessiva de comunicação
escrita formal em equipes distribuídas.
Passo 5 -
Release
Passo 5 - Release
Para melhor aprofundamento desta etapa,
iremos dividi-la em 2 Sub Passos:
▪ Passo 5.1 - Envio de Entregáveis
Verifica-se a conclusão dos itens planejados para a
release, revisando sua conformidade com os critérios
de aceitação e entregando-os ao cliente. Isso inclui a
documentação relevante para garantir uma
compreensão clara do produto entregue.
Passo 5 - Release
Passo 5.2 - Retrospectiva da Release
Realiza-se uma avaliação do sucesso da Release,
considerando objetivos estabelecidos, feedback do
cliente e outros critérios de desempenho.
São discutidas lições aprendidas durante a Release,
incluindo aspectos positivos, desafios enfrentados e
oportunidades de melhoria. O processo geral da
Release é revisado, e ajustes são identificados para
otimizar futuras iterações.
Passo 5.1 -
Envio de
Entregáveis
Processo para o Envio de Entregáveis:
1 - Product Owner 1 - Métodos de Implantação 1 - Contrato de Prestação

2 - Business Stakeholder(s) Organizacional de Trabalho
3 - Entregáveis Aceitos 2 - Plano de Comunicação 2 - Entregáveis em
4 - Cronograma de Planejamento 3 - Ferramentas do Projeto Funcionamento
da Release Scrum 3 - Releases do Produto
5 - Scrum Master 4 - Plano de Comunicação
6 - Scrum Team
7 - Critérios de Aceitação da
História do Usuário
8 - Plano Piloto
9 - Recomendações do Scrum
Guidance Body
Projeto
Stakeholder(s) 12.1 Envio de

Entregáveis
Stakeholders
Cronograma de
Planejamento
8.6 Conduzir o da Release
Planejamento da
Release Contrato de Prestação de
Trabalho
Entregáveis Entregáveis em
11.2 Demonstrar e Aceitos Funcionamento
Validar a Sprint Releases de Produto
Entradas
As entradas são:
▪ Product Owner;
▪ Entregáveis Aceitos;
▪ Scrum Master;
▪ Scrum Team;
▪ Plano Piloto;
Ferramentas
Métodos de Implantação Organizacional:
A implantação pode ocorrer de várias maneiras,
incluindo remotamente, através de meios digitais,
ou envolvendo transporte físico para locais
específicos.
A complexidade e o risco associados à implantação
geralmente levam as organizações a estabelecerem
mecanismos robustos e processos detalhados para
garantir a conformidade com normas aplicáveis e
padrões de qualidade.
Ferramentas
Métodos de Implantação Organizacional:
Esses mecanismos de implantação podem incluir
etapas como a assinatura de conclusão por
representantes de gerenciamento designados,
aprovação do usuário e diretrizes específicas sobre
as funcionalidades mínimas que devem estar
presentes em uma release.
Em essência, os métodos de implantação
organizacional são projetados para garantir uma
transição suave e controlada do desenvolvimento
para a entrega, minimizando riscos e garantindo a
qualidade do produto final.
Ferramentas
Plano de Comunicação:
Este plano tem como objetivo especificar os
registros que devem ser criados e mantidos ao longo
do projeto, delineando a estratégia de comunicação
a ser seguida.
A comunicação eficaz é essencial para o sucesso de
qualquer projeto, garantindo que as informações
pertinentes sejam transmitidas de maneira clara e
oportuna para os stakeholders do negócio.
Saídas
Contrato de Prestação de Trabalho:
Refere-se a um acordo formal entre as partes
envolvidas em um projeto, estabelecendo as condições
e responsabilidades relacionadas à prestação de
serviços. No contexto de entrega de projetos os
entregáveis aceitos no âmbito desse contrato recebem
aprovação formal do negócio, bem como do cliente
e/ou patrocinador.
A obtenção da aceitação formal do cliente, significa
que o cliente ou patrocinador concorda que os
entregáveis atendem aos critérios de aceitação
definidos, estão em conformidade com as expectativas
e estão prontos para serem colocados em operação.
Saídas
Entregáveis em Funcionamento:
Esses entregáveis representam incrementos
contínuos do produto, sendo integrados aos
incrementos anteriores.
A presença constante de um produto com potencial
de envio ao longo do projeto significa que há sempre
algo pronto para ser entregue, promovendo uma
abordagem iterativa e incremental no
desenvolvimento do produto.
Saídas
Releases do Produto:
Referem-se à versões específicas do produto que são
disponibilizadas para os clientes ou usuários finais.
Essas Releases são parte integrante do processo de
entrega contínua e incremental no desenvolvimento
de produtos.
Para garantir uma entrega eficaz, as Releases do
Produto devem abranger os aspectos que veremos a
seguir.
Saídas
Conteúdo da Release
▪ Detalhes sobre os entregáveis específicos
incluídos na release. Isso pode abranger novas
funcionalidades, correções de bugs, melhorias
de desempenho, entre outros;
▪ Informações úteis para o time de suporte ao
cliente lidar com consultas ou problemas
relacionados ao novo conteúdo da release.
Notas da Release
▪ Especificações e critérios importantes
relacionados ao lançamento do produto no
mercado ou para os clientes.
Exemplo 5.1 -
Enviando
Entregáveis
Exemplo 5.1 - Enviando Entregáveis
Renata é a Gerente de Marketing da "Elegance
Beauty", uma renomada empresa de cosméticos. Ela
é apaixonada por inovação e sempre busca maneiras
de aprimorar os processos internos para garantir o
sucesso dos lançamentos de produtos.
Em um ambiente dinâmico e competitivo, Renata
percebeu a necessidade de adotar uma abordagem
ágil para o desenvolvimento e lançamento de novos
produtos.
A decisão de implementar o Scrum na equipe de
desenvolvimento de produtos foi tomada após uma
análise cuidadosa dos desafios enfrentados
anteriormente.
Renata identificou alguns problemas comuns, como
a falta de comunicação eficaz entre as equipes, a
dificuldade em se adaptar a mudanças rápidas no
mercado e a necessidade de maior transparência no
progresso do projeto.
A Elegance Beauty está lançando uma nova linha de
produtos cosméticos voltados para cuidados com a
pele. A empresa adotou a metodologia Scrum para
gerenciar o projeto de desenvolvimento e lançamento
desses novos produtos.
Scrum Team:
▪ Product Owner: Renata (Gerente de Marketing);
▪ Scrum Master: André;
▪ Designers de Produto: Gabriela, Lucas;
▪ Especialista em Produtos: Carla;
▪ Analista de Qualidade: Thiago.
Sprint Atual
O time está na última semana de uma Sprint de
quatro semanas, durante a qual se comprometeu a
finalizar o desenvolvimento e preparar o
lançamento da nova linha de produtos.
No final da Sprint, o time trabalha para garantir que
os produtos estejam prontos para serem lançados
no mercado.
Atividades
▪ Finalização do Design e Produção: Gabriela e
Lucas, os designers, concluem os designs finais das
embalagens e garantem que os produtos estejam
prontos para produção em massa;
▪ Testes de Qualidade: Thiago, o analista de
qualidade, realiza testes rigorosos nos produtos
para garantir que atendam aos padrões de
qualidade estabelecidos;
▪ Validação com o Especialista em Produtos: Carla,
especialista em produtos, valida os produtos em
relação aos benefícios prometidos e às
expectativas do cliente;
Atividades
▪ Preparação para o Lançamento: Renata, o
Product Owner, coordena a preparação para o
lançamento, incluindo campanhas de marketing,
materiais promocionais e estratégias de
distribuição;
▪ Reunião de Revisão da Sprint: o time realiza uma
Reunião de Revisão da Sprint para revisar os
produtos finais, alinhar-se sobre os detalhes do
lançamento e garantir que tudo esteja pronto
para a entrega;
▪ Aceitação e Lançamento: Renata aceita
formalmente os produtos, indicando que estão
prontos para o lançamento. Os produtos são
lançados no mercado conforme o planejado.
Entregáveis em Funcionamento
▪ Identificação de Incrementos do Produto: a
equipe Scrum, liderada por Renata como Product
Owner, identificou incrementos contínuos do
produto. Isso envolveu a divisão do produto em
funcionalidades ou melhorias específicas que
poderiam ser desenvolvidas em iterações;
▪ Desenvolvimento Iterativo e Incremental: a
equipe seguiu uma abordagem iterativa e
incremental, desenvolvendo incrementos do
produto em sprints sucessivas. Cada incremento
representava uma versão funcional adicional do
produto, integrada aos incrementos anteriores
para criar uma solução completa.
Entregáveis em Funcionamento
▪ Integração Contínua: a prática de integração
contínua foi adotada para garantir que os
entregáveis fossem integrados de maneira
eficiente, evitando problemas de compatibilidade e
promovendo a estabilidade do produto;
▪ Avaliação e Aceitação Contínuas: à medida que os
incrementos eram desenvolvidos, eram avaliados
continuamente pela equipe Scrum e pelos
stakeholders. A aceitação contínua garantia que os
incrementos atendessem aos padrões de
qualidade e expectativas dos clientes.
Releases do Produto
▪ Identificação de Versões para Lançamento:
▪ A equipe, em colaboração com o Scrum
Master, identificou as versões específicas do
produto que seriam disponibilizadas para os
clientes como Releases;
▪ Cada release incluía um conjunto de
funcionalidades ou melhorias significativas.
▪ Conteúdo da Release:
▪ As Releases do Produto foram planejadas com
informações essenciais sobre os entregáveis
incluídos, como novas linhas de produtos,
correções de produtos existentes e
aprimoramentos de fórmulas.
Releases do Produto
▪ Auxílio ao Time de Suporte ao Cliente:
▪ Notas detalhadas foram fornecidas para auxiliar
o time de suporte ao cliente a lidar com consultas
relacionadas ao novo conteúdo da Release. Isso
incluiu informações sobre a aplicação correta,
benefícios dos produtos e possíveis
preocupações dos clientes.
▪ Notas da Release:
▪ Critérios de Envio Externos ou Voltados ao
Mercado foram detalhados nas notas da Release.
Isso abrangeu especificações importantes, como
datas de lançamento, requisitos de
armazenamento, instruções de uso e outros
detalhes relevantes.
Release 1.0 - "Primavera Encantada"
Identificação da Release
▪ Nome: Primavera Encantada
▪ Versão: 1.0
Nova Linha de Produtos:
▪ Introdução da coleção "Flores da Primavera", incluindo produtos para
cuidados com a pele e maquiagem inspirados na estação.
Correções e Aprimoramentos:
▪ Ajustes nas fórmulas de produtos existentes para melhorar a
durabilidade e eficácia.
Correções de pequenos bugs identificados pelos clientes.
Release 1.0 - "Primavera Encantada"
Notas da Release
Critérios de Envio Externos:

▪ Data de Lançamento: 15 de março de 2023;
▪ Requisitos de Armazenamento: manter em local fresco e seco;
▪ Instruções de Uso: incluídas em cada produto da coleção.
Informações Adicionais:
▪ Destaque nas redes sociais: campanha de lançamento com influenciadores;
▪ Evento de Lançamento: participação em eventos locais para promover a nova
coleção.
Release 1.1 - "Verão Radiante"
Identificação da Release
▪ Nome: Verão Radiante

▪ Versão: 1.1
▪ Expansão da Linha de Protetores Solares:

▪ Adição de novos protetores solares com fórmulas aprimoradas e opções para
diferentes tipos de pele.
Colaboração Exclusiva
▪ Parceria com um renomado maquiador para lançar uma paleta exclusiva de

sombras inspirada no verão.
Release 1.1 - "Verão Radiante"
Notas da Release
Critérios de Envio Externos:

▪ Data de Lançamento: 1º de junho de 2023;
▪ Armazenamento: proteger da luz solar direta;
▪ Instruções de Uso: incluídas em cada produto novo;
Informações Adicionais:
▪ Promoção Especial: descontos para os primeiros clientes a adquirirem
os produtos da Release;
▪ Conteúdo Exclusivo: vídeos tutoriais com o maquiador parceiro nas
redes sociais.
Ao seguir esses processos, a "Elegance Beauty"
garantiu uma entrega contínua de produtos de
qualidade, mantendo os clientes informados e
satisfeitos com cada nova versão lançada no
mercado de beleza.
Passo 5.2 -
Retrospectiva
da Release
Processo para a Retrospectiva da Release:

1 - Time Central do Scrum 1 - Reunião de Retrospectiva 1 - Pontos de Melhoria
2 - Scrum Master Chefe da Release Acordados
3 - Chief Product Owner 2 - Outras Ferramentas para a 2 - Itens de Ação Atribuída e

Retrospectiva da Release Datas de Vencimento
4 - Business Stakeholder(s)
3 - Expertise do Scrum 3 - Itens Não Funcionais
5 - Recomendações do Scrum Guidance Body Propostos para o Backlog do
Guidance Body Produto do Programa e para
4 - Ferramenta do Projeto
Scrum o Product Backlog
4 - Recomendações
Atualizadas do Scrum
Guidance Body
Projeto
Scrum Master 12.2

Retrospectiva da Release
Stakeholders
8.3 Formar o Scrum Team

Scrum Team Pontos de Melhoria
Acordados
Itens de ação atribuídos e
prazos
Entradas
As entradas são:
▪ Time(s) Central(s) do Scrum;
▪ Scrum Master Chefe;
▪ Chief Product Owner;
▪ Recomendações do Scrum Guidance
Body.
Ferramentas
Reunião de Retrospectiva da Release:
Realizada ao término de uma Release, seu propósito
central é promover a melhoria contínua, buscando
aprimorar a colaboração e a eficácia da equipe nas
futuras entregas do produto.
Durante a reunião, participantes essenciais, como
membros do Time Central do Scrum, Scrum Master
Chefe, Chief Product Owner e Stakeholders do
negócio, se reúnem para avaliar tanto os aspectos
positivos quanto os negativos do ciclo de
desenvolvimento.
Ferramentas
Reunião de Retrospectiva da Release:
Esse encontro não possui um tempo fixo,
oferecendo flexibilidade para discussões mais
aprofundadas e pode ocorrer presencialmente ou
virtualmente, adaptando-se às necessidades da
equipe.
Durante as discussões, são levantadas lições
aprendidas ao longo da release, proporcionando
insights valiosos para aprendizado futuro. Pontos
positivos e negativos são abordados, e
oportunidades de melhoria nos processos são
exploradas e documentadas.
Saídas
▪ Pontos de Melhoria Acordados:
Explicado na aula anterior;
▪ Itens de Ação Atribuída e Datas de Vencimento:
Explicado na aula anterior.
Exemplo 5.2 -
Realizando a
Retrospectiva
da Release
Reunião de Retrospectiva da Release - Elegance Beauty
▪ Condução da Reunião:
Ao término de cada Release, o Time Central do Scrum,
André, Renata e Stakeholders do negócio se reuniram
para a Reunião de Retrospectiva da Release na Elegance
Beauty.
A reunião foi conduzida de forma a proporcionar uma
avaliação aberta e construtiva do ciclo de
desenvolvimento da release recentemente concluída.
Tópicos Abordados
Pontos Positivos:
▪ Lançamento bem-sucedido da coleção "Primavera
Encantada" com boa aceitação dos clientes;
▪ Melhorias percebidas na eficiência da comunicação
entre as equipes durante a release;
Pontos Negativos:
▪ Atraso na entrega de alguns protótipos de produtos,
impactando o cronograma inicial;
▪ Dificuldades identificadas na gestão de estoque
devido à alta demanda de alguns produtos.
Tópicos Abordados
Oportunidades de Melhoria:
▪ Exploração de estratégias para antecipar
potenciais gargalos de produção;
▪ Investimento em treinamentos específicos para
aprimorar a gestão de estoque.
Tópicos Abordados
Durante a Reunião de Retrospectiva da Release,
as seguintes saídas foram documentadas:
Pontos de Melhoria Acordados:
▪ Estratégias para otimização do processo de entrega
de protótipos;
▪ Implementação de treinamentos adicionais para a
equipe de estoque;
Itens de Ação Atribuída e Datas de Vencimento:
▪ Designação de responsáveis para as estratégias de
otimização e treinamentos;
▪ Estabelecimento de datas específicas para a
conclusão dessas ações.
Com base nas melhorias identificadas e nas ações
implementadas após a Reunião de Retrospectiva da
Release, a Elegance Beauty alcançou resultados notáveis
na seguinte temporada, a "Verão Radiante".
As estratégias adotadas para otimizar o processo de
entrega de protótipos mostraram-se eficazes,
resultando em lançamentos pontuais e uma resposta
positiva dos clientes.
O investimento em treinamentos específicos
para a equipe de estoque também gerou
impactos significativos.
A gestão de estoque tornou-se mais eficiente,
minimizando problemas relacionados à demanda
inesperada e permitindo uma melhor
organização dos produtos.
Além disso, a flexibilidade e abertura para a
aprendizagem contínua foram incorporadas à cultura
da equipe, fortalecendo ainda mais a capacidade de
adaptação a desafios futuros.
A equipe da Elegance Beauty pôde, assim, celebrar não
apenas o sucesso da "Verão Radiante" mas também a
consolidação de práticas ágeis que impulsionam a
excelência em cada release.
Este caso demonstra como a implementação do
Scrum, aliada a uma abordagem colaborativa e à
valorização do aprendizado contínuo, contribuiu
para o sucesso sustentável da Elegance Beauty em
suas iniciativas de lançamento de coleções.
Dicas e
Boas
Práticas
Dicas e Boas Práticas
▪ Treinamento e Conscientização: certifique-se de
que todos os membros da equipe, tenham um
entendimento claro dos princípios e valores do
Scrum;
▪ Formação de Equipe: construa equipes
multifuncionais e auto-organizadas, promovendo a
colaboração entre os membros da equipe;
▪ Definição Clara de Papéis e Responsabilidades:
garanta que os papéis de Scrum Master, Product
Owner e membros da equipe sejam bem definidos,
entendidos e aceitos pela equipe. Evite
sobrecarregar membros com responsabilidades
adicionais;
▪ Planejamento Adequado: dedique tempo
suficiente para o planejamento eficiente da Sprint,
garantindo que o Backlog do Produto esteja bem
refinado e pronto para a Sprint Planning;
▪ Backlog Bem-Gerenciado: mantenha um Product
Backlog Atualizado, com Histórias de Usuário
claras e estimativas para facilitar o planejamento
da Sprint;
▪ Comunicação Efetiva: realize reuniões diárias
curtas e focadas para manter todos atualizados
sobre o progresso e possíveis impedimentos.
▪ Sprint Review e Retrospectiva: conduza reuniões
de Sprint Review e realize retrospectivas de Sprint
de forma regular para identificar oportunidades de
melhoria contínua;
▪ Adaptação Contínua: esteja aberto à mudança e
adapte o processo conforme necessário para
melhor atender às necessidades da equipe e do
projeto;
▪ Ferramentas Adequadas: utilize ferramentas ágeis
e de gerenciamento de projetos que possam
facilitar a colaboração e a transparência;
▪ Cultura de Melhoria Contínua: crie uma cultura
que promova a melhoria contínua, incentivando a
equipe a identificar oportunidades de
aprimoramento e a implementar soluções
iterativas;
▪ Formação: mantenha-se atualizado sobre os novos
lançamentos oficiais do SCRUM, através do Scrum
Guide e do SBOK;
▪ Para facilitar, todo lançamento novo a scrum.org
publica um artigo em seu site sobre o que mudou
do guia anterior para o novo guia
Além das práticas comuns, existem algumas dicas
não convencionais que podem adicionar um
toque inovador à implementação do Scrum.
A aplicação dessas dicas não convencionais
depende da cultura da equipe e da disposição
para experimentar novas abordagens. É sempre
importante adaptar as práticas ao contexto
específico do projeto e da organização.
Exemplos
▪ Desafios Semanais: introduza desafios semanais
ou mensais para a equipe, promovendo a resolução
criativa de problemas;
▪ Rotação de Papéis Incomuns: permita que
membros da equipe assumam papéis fora de suas
especialidades usuais durante uma Sprint;
▪ "Não faça" List: além da lista de tarefas a fazer,
mantenha uma lista "não faça". Isso destaca
práticas prejudiciais identificadas durante as
retrospectivas que a equipe concordou em evitar;
▪ Mural de Agradecimento: mantenha um mural
físico ou virtual onde os membros da equipe
possam expressar gratidão ou reconhecimento
pelos esforços uns dos outros;
▪ Sprint de Inovação: dedique uma Sprint inteira
para a inovação, onde os membros da equipe
podem explorar tecnologias novas ou propor ideias
disruptivas.
Revisão
Revisão
▪ Boas Vindas;
▪ O que é SCRUM?
▪ Case;
▪ Vantagens do SCRUM;
▪ Contexto Histórico;
▪ Conceitos Importantes:
▪ Metodologias ágeis;
▪ Scrum x Modelo tradicional de
Gerenciamento de Projetos;
▪ Aprofundamentos do scrum;
▪ Time Scrum (Scrum Team);
Revisão
▪ Scrum Guide;
▪ Certificações em SCRUM;
▪ Glossário do Scrum;
▪ Passo a Passo;
▪ Passo 1 - Iniciar;
▪ Passo 2 - Planejar e Estimar;
▪ Passo 3 - Implementar;
▪ Passo 4 - Revisão e Retrospectiva;
▪ Passo 5 - Release;
▪ Dicas e boas práticas.

Parabéns!
Obrigado pela
caminhada até aqui!
Que você consiga

aplicar seus
novos conhecimentos
sobre Scrum!
Referências
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. 1986.
Harvard Business Review. Disponível em:
https://hbr.org/1986/01/the-new-new-product-development-game.
Manifesto for Agile Software Development. Disponível em:

http://agilemanifesto.org/.
Um Guia para o Conhecimento em Scrum (Guia SBOK®) – Quarta Edição. 2022.

SCRUMstudyTM,

(FM2S) Slides Diagramados - Especialista SCRUM - Parte 2

Enviado por

Direitos autorais:

Formatos disponíveis

Você também pode gostar

(FM2S) Slides Diagramados - Especialista SCRUM - Parte 2

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

(FM2S) Slides Diagramados - Especialista SCRUM - Parte 2

Enviado por

Direitos autorais:

Formatos disponíveis

Passo 2.

ENTRADAS FERRAMENTAS SAÍDAS

1 - Time Central do Scrum 1 - Reuniões de Planejamento 1 - Lista de Tarefas

8.2 Identiﬁcar Scrum Master 9.4

Continuando o nosso Exemplo…

▪ Lucas, Product Owner, estava presente para

ENTRADAS FERRAMENTAS SAÍDAS

1 - Time Central do Scrum 1 - Reunião de Planejamento 1 - Lista de Tarefas

9.4 Identiﬁcar Lista de Tarefas

ENTRADAS FERRAMENTAS SAÍDAS

1 - Time Central do Scrum 1 - Reuniões de Planejamento 1 - Sprint Backlog Atualizado

8.3 Formar o Scrum Scrum Team

8.6 Conduzir o Duração da Sprint

Mostra a queda planejada da

Fonte: Guia SBOK®, 2022, pg. 222.

Fonte: Guia SBOK®, 2022, pg. 223.

Atividade Estimativa Responsável Status

Atividade Estimativa Responsável Status

ENTRADAS FERRAMENTAS SAÍDAS

1 - Time Central do Scrum 1 - Expertise do Time 1 - Entregáveis da Sprint

8.2 Identiﬁcar Scrum Master

8.3 Formar o Scrum Scrum Team

9.3 Comprometer Duração da Sprint Registro de

11.1 Demonstrar e 10.2 Conduzir a

História de Usuário 1: Tendências de Moda (Pontuação: 8)

Carla conduz o time para em uma reunião produzirem o Scrumboard Atualizado:

A fazer Em andamento Em revisão Concluído

1 - Time Central do Scrum 1 - Reunião Diária 1 - Scrumboard Atualizado

9.3 Comprometer Scrumboard

2. O que eu vou fazer hoje?

3. Quais impedimentos ou obstáculos estou enfrentando atualmente?

A fazer Em andamento Em revisão Concluído

Documentação Preparação para Design de

ENTRADAS FERRAMENTAS SAÍDAS

9.1 Criar Histórias de

História de Usuário: Quero Produtos de Alta Qualidade e Durabilidade

História de Usuário: Quero Participar de Campanhas Exclusivas para Membros

ENTRADAS FERRAMENTAS SAÍDAS

8.2 Identiﬁcar Scrum

▪ Histórias de Usuário Aceitas

História de Usuário (HU1):

História de Usuário (HU2):

História de Usuário (HU3):

História de Usuário (HU4):

História de Usuário (HU5):

História de Usuário (HU6):

História de Usuário (HU7):

História de Usuário (HU3): Como usuário, quero um sistema de reserva fácil e

História de Usuário (HU5): Como usuário, quero um diário de viagem

Eles também separaram as Histórias de Usuários Rejeitadas:

História de Usuário: Como usuário, quero um sistema de gamiﬁcação do uso do app

ENTRADAS FERRAMENTAS SAÍDAS

1 - Scrum Master 1 - Reunião de 1 - Pontos de Melhoria Acordados

Os quatro perﬁs são:

▪ Shopper (Comprador): Quer ouvir todas as discussões e escolher conscientemente o

▪ Vacationer (Turista): Deseja relaxar e ser mais passivo na retrospectiva, como se

▪ Prisoner (Prisioneiro): Preferiria estar em outro lugar e está participando da

ENTRADAS FERRAMENTAS SAÍDAS