O documento discute o papel do Product Owner no Scrum, explicando que ele é membro da equipe responsável por maximizar o retorno sobre o investimento no desenvolvimento de software, definindo as funcionalidades mais valiosas a partir das necessidades dos usuários por meio de ferramentas como visão do projeto, user stories e backlog do produto.

1. SCRUM: Maximizando o
ROI no desenvolvimento
de software
Guilherme Tossulino, CSPO
Instituto de Estudos Avançados – IEA
IV Fórum de Governança em TI – SUCESU/SC
Setembro de 2009

2. Programa
1. ROI
2. Uso de funcionalidades de software
3. O Product Owner no SCRUM
4. Ferramentas do PO
5. Problemas comuns

3. ROI – Return Of Investment
 ROI não é apenas retorno finaneiro

4. ROI – Return Of Investment
 Como então mesurar o ROI?
 Audiência, acessos
 Custo da mudança
 Satisfação do cliente
 Ciclo de vida do software

5. Uso de funcionalidades
7%
13%
Nunca
Raramente 45%
Algumas vezes
Frequentemente 16%
Sempre
19%
Fonte: Standish Group

6. Uso de funcionalidades
7%
13%
Nunca
Raramente 45%
Algumas vezes
Frequentemente 16%
Sempre
64% de desperdício 19%
Fonte: Standish Group

7. Uso de funcionalidades
7%
13%
Nunca
Raramente 45%
Algumas vezes
Frequentemente 16%
Sempre
19%
Apenas 20% agregam valor
Fonte: Standish Group

8. Desafio
Descobrir em um software quais
são as funcionalidades que
representam os 20% mais
importantes

9. Quem é o Product Owner?
 Gerente de Produto?
 Analista de Negócios?
 Gerente de Projetos?
 CEO da empresa?

10. Quem é o Product Owner?
 Membro da equipe
Product Scrum
Owner Master
Team

11. Quem é o Product Owner?
 Conhece BEM o negócio
 É a voz do cliente
 Guia o time visando o ROI
 Define entregas e metas
 Aceita ou não os resultados

12. Espera-se do Product Owner
 Habilidades de comunicação
 Fácil acesso aos stakeholders do projeto
 Poder de decisão
 Disponibilidade para a equipe
 Comprometimento: equipe e projeto

13. Ferramentas do PO
 Visão do projeto
 User Stories
 Product Backlog

14. Visão do projeto
 Guia a equipe aos resultados
 Precisa ser compartilhada com a equipe
“Uma visão é uma clara imagem que gera um
atração emocional entre pessoas e produto.”

15. Exemplo de uma visão
“Para atender aos profissionais
envolvidos com Scrum no IEA que
precisam entender o processo e os
papéis do Scrum a Palestra “Scrum e
seus papéis” é uma iniciação que
instrui esses profissionais para que
possam ter melhor desempenho e
entendimento do processo.”

16. User Stories
 Representam os requisitos do software
 São criadas pelo PO com a ajuda da equipe
 Devem ser claras e objetivas

17. User Stories
 Técnicas para captação
 Entrevistas;
 Questionários;
 Observação de usuários;
 Trabalhos em grupos.

18. User Stories - INVEST
 I – Independente
 N – Negociável
 V – Valiosa
 E – Estimável
 S – Small (pequena)
 T – Testável

19. Exemplos de User Stories
Template:
 Como um <PERFIL> desejo <PROPÓSITO> para
<VALOR DE NEGÓCIO>.

20. Exemplos de User Stories
Template:
 Como um <PERFIL> desejo <PROPÓSITO> para
<VALOR DE NEGÓCIO>.
Exemplo:
 Como um <aluno> desejo <receber mensagens no
meu celular> para <que eu possa ser avisado sobre
provas e notificações do sistema com
antecedência>.

21. Exemplos de User Stories
Template:
 Como um <PERFIL> desejo <PROPÓSITO> para
<VALOR DE NEGÓCIO>.
Exemplo:
 Como um administrador do sistema enviar
mensagens de SMS para alunos para que eles
possam ser avisados no celular com avisos e
notificações do sistema.

22. Product Backlog
 Conjunto de user stories
 Não precisa estar completo desde início
 Precisa estar sempre PRIORIZADO

23. Exemplo de Product Backlog
Não priorizado
User stories
Criar cadastro da mensagem
Imprimir mensagem
Enviar mensagem
Permitir acentos na mensagem
Criar campo celular

24. Exemplo de Product Backlog
Não priorizado Priorizado
User stories User stories
Criar cadastro da mensagem Criar campo celular
Imprimir mensagem Criar cadastro da mensagem
Enviar mensagem Enviar mensagem
Permitir acentos na mensagem Permitir acentos na mensagem
Criar campo celular Imprimir mensagem

25. Problemas comuns
 PO não tem poder de decisão sobre o produto
 Baixa disponibilidade do PO para atender as
dúvidas e demandas da equipe
 Falta de treinamento
 Cultura organizacional
 Product Backlog mal priorizado

26. Obrigado!
 Guilherme Tossulino
 E-mail: tossulino@iea.org.br
 Twitter: www.twiter.com/tossulino
 Skype: tossulino.iea

27. Polêmicas
 O Product Owner pode ser o cliente?
 O Product Owner precisa ter conhecimentos
técnicos?