O documento aborda o papel do Product Owner no Scrum, destacando suas responsabilidades na gestão do product backlog e na condução das cerimônias Scrum, como o Sprint Planning, Review e Retrospective. Ele enfatiza a importância da colaboração com a equipe de desenvolvimento e a definição clara de histórias de usuário e critérios de aceitação para garantir entregas de valor. Além disso, são apresentadas ferramentas e boas práticas para otimizar o trabalho dentro do framework Scrum.

1. Entendendo o papel do
WORKSHOP PRÁTICO
Product Owner

2. AGENDA
PARTE 01
• O papel do Product Owner
• Perfil e características
• Atuação
• Ferramentas e boas práticas

3. SCRUM TEAM
Product Owner Scrum Master
Dev Team

4. PRODUCT OWNER
É a única pessoa responsável por
gerenciar o product backlog, ele é uma
pessoa e NÃO um comitê.
TODA ORGANIZAÇÃO DEVE RESPEITAR
AS DECISÕES DELE.

6. Eventos Scrum

7. SPRINT PLANNING
• Para esta cerimônia o PO deverá levar todas as estórias priorizadas e com um
grau de detalhe que permita ao time compreendê-las e estima-las.
• Cabe ao PO garantir que todo o time saia do planejamento com o conceito de
“pronto” e a meta da Sprint clara.
• Caso o time não sinta confiança para estimar uma ou mais atividades devido
a ausência de informações ou dúvidas que surgiram durante o planejamento,
ele poderá recusá-las.
• Neste caso o PO será responsável por buscar as informações necessárias e
apresentar esta estória em um novo planejamento.

8. SPRINT PLANNING
O que pode estar PRONTO nesta
Sprint
Como o trabalho escolhido se
tornará PRONTO
TÓPICOS

9. DAILY MEETING
• Nesta cerimônia a participação do PO é opcional.
• O time de desenvolvimento ou Scrum Master poderá acionar o PO em
casos específicos.
• O PO poderá por conta própria participar da reunião, porém, sugere-se
que ele o faça de forma passiva – apenas como ouvinte e com postura
amigável.

10. REVIEW MEETING
• Esta é uma das cerimônias mais importantes para o PO.
• É nesta cerimônia que o PO irá validar as entregas realizadas pelo time
formalizar o aceite.
• Quando possível o PO deverá convidar os stakeholders (partes
interessadas) para participar desta reunião.
• Esta reunião garante o feedback imediato a cada nova iteração do
produto, viabilizando possíveis mudanças no backlog.

11. REVIEW MEETING
O time de desenvolvimento apresenta quais itens do
backlog estão “Prontos”.
TÓPICOS
O Product Owner esclarece quais itens do backlog
estão “Prontos” e quais não estão.
O time de Scrum analisa e discute sobre o backlog
restante do produto.

12. RETROSPECTIVE MEETING
• Neta cerimônia o PO poderá apresentar sua percepção sobre a Sprint.
• Ele será avaliado pela equipe, recebendo um feedback sobre o seu
trabalho. Desta forma terá a oportunidade de traçar um plano de
melhoria para si.
• Ele também poderá propor reflexões sobre os possíveis problemas que
levaram o time a não concluir alguma estória de forma satisfatória ou, o
oposto, estórias que superaram sua expectativa inicial.

13. Fonte: http://www.scrum.org

14. Ferramentas e boas práticas

15. Invest
Independente
As estórias não devem possuir
requisitos interligados ou
dependências que gerem
gargalos.
Negociável
A essência da funcionalidade
não deve ser alterada, mas os
detalhes de sua implementação
podem ser.
Valorosa
A premissa básica de qualquer
estória é que ela deve entregar
valor ao cliente.
Estimável
A estória deve possuir o máximo
de informações e características
que permita ao time
compreendê-la e estima-la.
Pequena
Estórias menores facilitam a
compreensão e ajudam a expor
possível problemas.
Testável
A estória deve permitir que
após sua conclusão seja possível
testá-la.

16. Personas

18. Estórias de
Usuário
Quem?
O que?
Por quê?

19. Estórias de
Usuário
"Como um <papel>, eu quero <desejo>
de modo que <benefício>“
EXEMPLO
"Como um turista, eu quero encontrar
um hotel barato de modo que eu
possa descansar e ficar próximo à
praia“

20. Critérios de aceitação
O critérios de aceitação devem
ser escritos pelo PO em conjunto
com um time de qualidade,
quando este existir.
Estes critérios têm o intuito de
limitar os cenários possíveis e
garantir que o time de
desenvolvimento tenha diretrizes
para validação.
Eles também ajudam a evitar
ambiguidades e auxiliam na
compreensão das
funcionalidades e
comportamentos esperados.

21. Estórias de
Usuário
+
Critérios de
Aceitação
"Como um turista, eu quero encontrar um
hotel barato de modo que eu possa
descansar e ficar próximo à praia“
EXEMPLO
1. O hotel deve possuir no mínimo 3
estrelas.
2. O hotel deve possuir estacionamento.
3. A diária não deve ultrapassar o
valor de R$ 80,00.

22. MoSCoW
Must have
É necessário ter, eu preciso
disso para garantir o valor do
meu produto.
Should have
Deveria ter, eu devo fazer isso
mas não é prioritário no
momento.
Could have
Poderia ter, eu considero como
melhoria ou incremento de
baixo valor percebido
Won’t have
Não será feito! Eu percebo que
não irá agregar valor ao produto
ou não está alinhado com a
estratégia.

23. TEMA
ÉPICO
ESTÓRIA
TAREFA
TAREFA
TAREFA
ESTÓRIA
TAREFA
TAREFA
TAREFA
ÉPICO
ESTÓRIA
TAREFA
TAREFA
TAREFA
ESTÓRIA
TAREFA
TAREFA
TAREFA
TEMA
ÉPICO
ESTÓRIA
TAREFA
TAREFA
TAREFA
ESTÓRIA
TAREFA
TAREFA
TAREFA
ÉPICO
ESTÓRIA
TAREFA
TAREFA
TAREFA
ESTÓRIA
TAREFA
TAREFA
TAREFA

24. Plano de
release
• Sprint 1
• Sprint 2
• Sprint 3
Versão
1
• Sprint 4
• Sprint 5
Versão
2
• Sprint 6
• Sprint 7
• Sprint 8
Versão
3
• Sprint 9
• Sprint
10
Versão
4

25. Roadmap do produto
Versão 1 Versão 2 Versão 4Versão 3

26. Gravidade,
tendência e
urgência
Matrix GUT
Problema Gravidade Urgência Tendência Prioridade
Problema 5 5 5 5 125
Problema 4 5 5 4 100
Problema 6 1 5 5 25
Problema 2 2 2 2 8
Problema 3 2 1 3 6
Problema 1 1 3 1 3
Problema 7 1 2 1 2

27. Gravidade,
tendência e
urgência
Gravidade
5 = extremamente grave
4 = muito grave
3 = grave
2 = pouco grave
1 = sem gravidade
Urgência
5 = precisa de ação imediata
4 = é urgente
3 = o mais rápido possível
2 = pouco urgente
1 = pode esperar
Tendência ("se nada for feito...")
5 = ...irá piorar rapidamente
4 = ...irá piorar em pouco tempo
3 = ...irá piorar
2 = ...irá piorar a longo prazo
1 = ...não irá mudar

28. Gravidade,
tendência e
urgência
Matrix GUT
Problema
Valor
percebido
Gravidade Urgência Tendência Prioridade
Problema 4 5 5 5 4 500
Problema 5 3 5 5 5 375
Problema 6 1 1 5 5 25
Problema 3 2 2 1 3 12
Problema 2 1 2 2 2 8
Problema 7 2 1 2 1 4
Problema 1 1 1 3 1 3

29. CESAR@CONSULTORIACAP.COM.BR
OBRIGADO!

30. Créditos de Imagens