2. Marcia Maia. Product Owner no Terra. Arquiteta de informação.
Designer pela UFPE, pós graduada em Ergonomia e
Usabilidade pela PUC-RJ. Trabalhou com Scrum também na
Globo.com e na Locaweb.
Dezembro/2010

4. Manifesto Ágil:
Valores, princípios e práticas
“ Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste
trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os
”
itens à esquerda.
Fonte: http://manifestoagil.com.br/

5. Waterfall: Abismo entre
Definição de requisitos
Entrega do produto

6. O SCRUM é iterativo e incremental
O cliente não é apenas um gerador
de demandas, participa do processo
e é parte da equipe.

7. O Scrum é
Um processo de desenvolvimento
iterativo e incremental
para gerenciamento de projetos
e desenvolvimento ágil de software.

9. Responsável Responsável para Responsável pelo
pelo produto que o ambiente de desenvolvimento
trabalho funcione no dia-a-dia

10. PO é a voz do cliente

11. Responsabilidades do PO
 Visão de produto
 Requisitos / User stories
 Product backlog / Priorização
 Dar direcionamento ao trabalho
 Aprovar ou rejeitar entregas
 Metas e releases
 ROI

12. Visão de produto
Definir claramente o que é o produto
com objetivo de que todos trabalhem
com o própósito de atingir o mesmo
fim.
Deve ser feita antes de se começar o
desenvolvimento do projeto.

13. Visão de produto
Elevator statement or
Elevator speech

14. Visão de produto
O que estamos fazendo,
por quê, para quem, qual é
o principal benefício, qual é
o principal diferencial
30”de conversa

15. Visão de produto
Estamos redesenhando o webmail do
TerraMail para que o produto permita a
inclusão de novas funcionalidades,
possibilite futuras alterações e seja
possível integrá-lo a outros produtos Terra.
Além de oferecer uma nova interface web
mais simples de usar e mais consistente
para todos os usuários, e usuários em
potencial, Brasil e Latam.

16. Visão de produto
Product Vision Box
Frente
• Nome do produto
• Tres ou quatros pontos chave
que ajudem a vender o produto
Imagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/

17. Visão de produto
Product Vision Box
Verso
• Principais features
• Principais requisitos operacionais
Imagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/

18. Visão de produto
Trade off matrix
Fixo Variável
Custo x
Prazo x
Escopo x

19. Visão de produto
Fator de exploração

20. Visão de produto
Custo de atraso

21. Visão de produto
Atributos de performance e qualidade

22. Visão de produto
Arquitetura do produto

23. Visão de produto
Dificuldades e riscos

24. Visão de produto
Principais marcos do projeto

25. Visão de produto
Project data sheet
• Definição e objetivos do produto
• Funcionalidades chave do produto
• Benefícios para o cliente
• Trade off matrix
• Fator de exploração
• Custo de atraso
• Atributos de performance e qualidade
• Arquitetura do produto
• Dificuldades e riscos
• Principais marcos do projeto

26. Visão de produto

27. Visão de produto
Product Owner
• É responsável pela visão de produto
• Compartilha essa visão com o time
• Refina essa visão com o time

28. Visão de produto
Uma boa visão de produto
permanece relativamente
constante, o caminho para
implementação da visão é
frequentemente adaptado

29. Product backlog
Lista de tudo que gostaríamos de
ter no produto
Derivado de um plano de negócios
ou de uma visão de produto
Pode ser escrito em formato de user
stories, use cases, features, etc
Responsabilidade do PO, mas
todos podem contribuir

30. Product backlog
Utilizando user stories
User Story
Descrição de uma necessidade para um público
específico com um valor de negócio
Quem? / O que? / Por que?

31. Product backlog
User stories
Identificar/conhecer público e definir “personas”
Algumas técnicas:
• Entrevistas
• Questionários
• Observação

32. Product backlog
User stories
Para escrever as users stories:
• Necessidades dos usuários
• Necessidades do cliente/empresa
• Histórico do produto (se houver)
• PO pode escrever sozinho ou
promover story-writing workshop

33. Product backlog
User story - Story-writing Workshop
Fonte: http://www.agileway.com.br/2010/07/20/story-writing-workshop/

34. Product backlog
User stories
Independente
Negociável
Estimável
Pequena
Testável

35. Product backlog
User stories
• Devem ser compreensíveis por todos:
usuários, cliente e time de desenvolvimento
• Evitam “interpretações” de documentação
• Detalhes das users stories podem ser feitos
como casos de aceitação, wireframes ou
especificações e através da comunicação

36. (Sobre documentação...)
Do Manifesto Ágil:
“Software em funcionamento
mais que documentação abrangente”
A quantidade e o formato
da documentação deve ser
feita de acordo com as
necessidades da equipe e
do ambiente.

37. Product backlog
User Story
Descrição de uma necessidade Story
para um público específico com
um valor de negócio
Temas Tema
Um grupo de stories Story Story Story
Story Story Story
Épicos
Grande feature sem Épico
especificação ou definição clara,
é uma story grande, bruta

38. Fatores de priorização
Valor Custo
Exploração Risco

39. Fatores de priorização
Valor
• KANO
Feature: Empolgante, lienar, mandatória
• Theme Screening
A partir de uma funcionalidade eleita como base, as outras são
comparadas com ela
• Buy a feature
As funcionalidades são precificadas para que os clientes
negociem a compra das mais importantes

40. Fatores de priorização
Valor

41. Fatores de priorização
Custo
Planning poker

42. Fatores de priorização
Exploração
Exploração Quanto mais você acredita
de Requisitos que os requisitos vão
mudar ao longo do tempo
ou que a equipe não
conhece a tecnologia a ser
utilizada mais alto será o
nível de exploração, mais
adequado será utilizar o
scrum
Exploração
de Tecnologia
O scrum foi feito para projetos com fator de exploração alto

43. Fatores de priorização
Risco x Valor
Risco
Alto risco Alto risco
Baixo valor Alto valor
Baixo risco Baixo risco
Baixo valor Alto valor
Valor

44. Fatores de priorização
Risco x Valor
Risco
Alto risco Alto risco
Baixo valor Alto valor 1
Baixo risco Baixo risco
Baixo valor Alto valor 2
3
Valor

45. Product backlog
Alta prioridade Cada sprint implementa as
estórias de prioridade mais alta
Cada novo requisito é priorizado
e inserido no Product Backlog
pelo Product Owner a qualquer
momento
Requisitos podem ser
repriorizados pelo Product
Owner a qualquer momento
Requisitos podem ser retirados
do Product Backlog pelo Product
Owner a qualquer momento
Baixa prioridade

46. Do manifesto Ágil:
"Responder a mudanças
mais que seguir um plano”
“Colaboração com o cliente
mais que negociação de contratos”

47. Product backlog Sprint atual
(users stories)
Release atual
(users stories
agrupadas por temas)
Próxima release
(users stories ou epicos)

48. Condições de satisfação
Condição para o requisito entrar no sprint
• User story?
Ready • Teste de aceitação?
• Qual é o grau de detalhamento necessário?
Condição para saída de um item do sprint
• Codificado?
Done • Testado?
• Documentado?

49. Planejamento de release
Continua planejando releases até que a visão de produto seja alcançada
Selecionar
um tamanho
de Sprint
Determinar as Estimar os Estimar a Selecionar
condições de itens do velocidade itens e datas
satisfação Backlog do Sprint do Release
Priorizar
User Stories

50. PO + Time

51. comunicação

52. Product Owner deve
Manter um canal de comunicação forte e aberto
com Scrum master/ Time
Ter alta disponibilidade
Responder à questões diariamente

53. Product Owner dentro do

54. Product Owner nas cerimonias do Scrum
No Sprint Planning 1, PO leva o backlog idealmente
estimado e priorizado, onde a meta do Sprint deve
ser definida e o time junto com o PO decide o que
entra no Sprint
Deve participar, APENAS se convidado:
• Sprint planning 2
• Reuniões diárias
• Retrospectiva

55. Do manifesto Ágil:
“Indivíduos e interação entre eles
mais que processos e ferramentas

57. Time dentro do mesmo elevador que o PO

58. PO dentro do mesmo taxi que o TIME