O Papel do Product Owner na Sociedade O Product Owner é responsável por criar a visão do produto, manter o Product Backlog priorizado e estimado, criar o Release Plan e interface com os Stakeholders. Ele também ajuda o ScrumMaster a proteger o time e aceita ou rejeita funcionalidades no Sprint Review.

1. O Papel do Product
Owner na Sociedade
@aleuai

2. Quem é o sujeito
desta oração?
““Ouviram do Ipiranga as margens plácidasOuviram do Ipiranga as margens plácidas
de um povo heróico o brado retumbantede um povo heróico o brado retumbante””
Joaquim Osório Duque EstradaJoaquim Osório Duque Estrada

3. Não Sei
Porque eu deveria saber?
O que isto agrega?
Trabalho em TI, não dou aulas de
Português
Quem?

4. Se você não sabe quem é o
sujeito, não importa, mas o
PO deve saber, caso “saber
o sujeito daquela oração”
seja parte de uma história.

5. Responsável pelo ROI
Criar Visão
Manter o PB estimado e priorizado
Priorização de PB com pelo menos 3 sprints
Criar Release Plan do Produto
Interface de comunicação com StakeHolders
Ajudar o ScrumMaster a proteger o Time
Aceitar ou rejeitar funcionalidades no Scrum
Review

6. O cliente sempre tem
razão! Tem?
A razão do Cliente é limitada ao seu
conhecimento do negócio
Clientes não devem interferir no
desenvolvimento de software.
Se isto fosse correto, não haveria o
papel de cliente

7. Product Backlog
Não precisa estar completo no início
de um projeto
Deve-se começar com o que é mais
óbvio naquele momento
O PB cresce e muda à medida que se
aprende mais sobre o produto e o
usuário

8. Funcionalidades
Extras
Produzir 20% das funcionalidades que
geram 80% de valor ao cliente
Menos é mais
Saber o que se quer e o que se
precisa

9. Problema:
Em 7 dias, o programa deve
Voar
Andar
Nadar

11. Se aumentarmos os
recursos...

12. Pode resultar nisto,
também.

13. Não seria melhor?

14. Churn - Rotatividade
Se há requisitos churn, está
especificando cedo de mais
Se há ciclos de correções, esta
testando tarde de mais.
TDD

15. Crie Conhecimento
Os times devem estabelecer hipóteses
Conduza muitos experimentos rápidos
Crie documentação concisa - histórias
Implemente a melhor alternativa

16. Era uma vez...
O requisito ditado pelo cliente, não
pelo analista
3C
Cards
Conversation
Confirmation

17. Cards
Histórias devem ser escritas em
cartões ou post-its para força-las a
serem curtas, breves

18. Conversation
Devem ser lembretes para identificar
uma funcionalidade que foi conversada
ou discutida com o cliente

19. Confirmation
O cliente DEFINE uma maneira de
validar essa história

20. Épico
Uma história MUITO grande, ou muito
vaga
Deve ser ignorada ou quebrada em
várias histórias

21. Surpresa!
Você descobriu algo no meio de um
sprint
O cliente lembrou de algo no meio de
um sprint
Fica para a próxima...

22. Doenças de Gerenciamento de Projeto
Multi-tarefa Nociva
Times enfrentam prioridades que mudam, interrompendo
a tarefa atual em favor de outra
Lei de Parkinson
Mais tempo de Segurança, mais tempo de projeto
Síndrome do Estudante
O trabalho quase sempre é adiado
Dependência entre tarefas
O atraso é passado adiante, mas o adiantamento não

23. Curioso?
“As margens plácidas” é o sujeito da
oração inicial