1) O documento apresenta a técnica de User Story Mapping, que auxilia na priorização e planejamento de lançamentos de produtos interativos. 2) O User Story Mapping envolve identificar histórias de usuários, organizá-las em um fluxo de tarefas e dividí-las em conjuntos temáticos para definir os primeiros lançamentos. 3) O processo inclui escrever cartões com as histórias, ordená-los, ajustar a criticidade, nomear os conjuntos de tarefas e marcar o primeiro lançamento.

1. Marcello de Campos Cardoso - www.mcardoso.com.br | www.latitude14.com.br |
Cortando o bolo com
User Story Mapping
Marcello de Campos Cardoso
www.mcardoso.com.br | www.latitude14.com.br
mcardoso@latitude14.com.br
#3

2. pesquisa
desenvolvimento
validação
Questionários eentrevistas
personas
prototipação
Storymapping
Benchmarking
Card Sorting
Análise Heurística
Percurso
Cognitivo
MIS
Método de Inspeção Semiótica
ocus group
etnografia testes de
usabilidade
MAC
Método de Avaliação de comunicabilida
netnografia

3. Onde aplicar?
Backlog do
produto
Backlog do
sprint
Reunião diária
Produto
potencialmente
“entregável”
definição do backlog

4. Técnica colaborativa, que
auxilia na priorização e
planejamento de releases
(lançamentos) de produtos
interativos.
(desenvolvida por Jeff Patton em 2005)
O que é User Story mapping?

5. Priorizando durante o planejamento
user story
user story
user story
user story
user story
user story
user story
user storyuser story
user story
user storyuser storyuser story
user story
user storyuser story
user story
user storyuser storyuser story
release 1 (MVP)
release 2
release 3

6. user story
user story
user story
user story
user story
user story
user story
user storyuser story
user story user story
user story
user story
user story
Priorizando durante o planejamento

7. ‣ Dificuldade de comunicar a visão do "todo"
‣ Risco de faltar funcionalidades importantes
para os usuários realizarem uma tarefa de
forma plena;
Por que mapa e não lista?

8. A equipe
•negócios
•marketing
•designers
•desenvolvedores
•cliente
•usuários
•etc

9. 1. Criar cartões de estórias
2. Ordenar em fluxo de tarefas
3. Ajustar posição quanto à criticidade
4. Marcar o primeiro release
Etapas

10. Passo 1
Identificar as possíveis user stories do seu sistema.
Pense “O que as pessoas podem fazer no meu sistema?”
‣ Cada item deve começar com um verbo, mantenha ponto de vista do usuário, NÃO DO
SISTEMA
‣ Esqueça detalhes de implementação, mantenha o foco nas tarefas

11. Passo 1
Ex.: software de controle de vendas
‣ Fazer pedido ao fornecedor
‣ Receber pedido do fornecedor
‣ Gerar etiquetas para itens recebidos
‣ Vender produtos
‣ Devolver e reembolsar produtos
‣ Analisar vendas

12. Passo 1
Escreva cada item em um cartão diferente.
Deixe espaço para outros detalhes.
Fazer pedido ao fornecedor

13. comprador interno
controlador de estoque
consultor de venda
analista de venda
Fazer pedido ao fornecedor
(comprador interno)
Frequência: semanalmente
Valor: médio
Adicione detalhes importantes:
‣ Usuários (profissão, cargo, papel desempenhado)
‣ Frequência de uso (muito, pouco, raro ou diariamente, semanalmente etc.)
‣ Valor (valor para o negócio. ROI: baixo, médio ou alto)
Passo 2

14. Passo 3
Ordene as cartas em uma sequência lógica de tarefas
‣ O objetivo é contar uma história de como o sistema funciona
‣ Sobreponha os cartões que aconteçam no mesmo tempo
(este OU este)

15. Analisar vendas
(analista de vendas)
Frequência: mensal
Valor: alto
sequência de uso
Necessidade
mais usado
raramente usado
Fazer pedido ao fornecedor
(comprador interno)
Frequência: semanalmente
Valor: médio
Receber pedido do fornecedor(comprador interno)Frequência: diário
Valor: alto
Fazer pedido ao comprador
(controlador de estoque)
Frequência: semanalmente
Valor: médio
Vender produto
(vendedor)
Frequência: diário
Valor: alto
Devolver e reembolsar
(vendedor)
Frequência: diário
Valor: médio

16. Passo 4
Ajustar conforme criticidade (verticalmente)
‣ Coloque acima as cartas mais importantes: alta frequência e alto valor.
‣ Discuta com a equipe o quão crítico cada funcionalidade é para o negócio

17. Analisar vendas
(analista de vendas)
Frequência: mensal
Valor: alto
Fazer pedido ao fornecedor
(comprador interno)
Frequência: semanalmente
Valor: médio
Receber pedido do
fornecedor
(comprador interno)Frequência: diário
Valor: alto
Fazer pedido ao comprador
(controlador de estoque)
Frequência: semanalmente
Valor: médio
Vender produto
(vendedor)
Frequência: diário
Valor: alto
Devolver e reembolsar
(vendedor)
Frequência: diário
Valor: médio

18. Passo 5
Divida e dê nome aos conjuntos de tarefas
‣ Discuta onde há quebras no modelo
‣ Pode ser uma mudança de usuário, regras de negócio ou processo
‣ Divida verticalmente as quebras e dê um nome

19. compra
recebimento
venda
análise
Analisar vendas
(analista de vendas)
Frequência: mensal
Valor: alto
Fazer pedido ao comprador
(controlador de estoque)
Frequência: semanalmente
Valor: médio
Vender produto
(vendedor)
Frequência: diário
Valor: alto
Devolver e reembolsar
(vendedor)
Frequência: diário
Valor: médio
Fazer pedido ao fornecedor
(comprador interno)
Frequência: semanalmente
Valor: médio
Receber pedido do
fornecedor
(comprador interno)Frequência: diário
Valor: alto

20. Passo 6
Marcar primeiro release (MVP)
‣ Deve ser o menor número de funcionalidades úteis para os usuários
e o contexto do negócio
‣ É o primeiro release mas não necessariamente o primeiro a ser
público

21. compra
recebimento
venda
análise
Analisar vendas
(analista de vendas)
Frequência: mensal
Valor: alto
Fazer pedido ao comprador
(controlador de estoque)
Frequência: semanalmente
Valor: médio
Vender produto
(vendedor)
Frequência: diário
Valor: alto
Devolver e reembolsar
(vendedor)
Frequência: diário
Valor: médio
Fazer pedido ao fornecedor
(comprador interno)
Frequência: semanalmente
Valor: médio
Receber pedido do
fornecedor
(comprador interno)Frequência: diário
Valor: alto
1º Release
(MVP)

29. Desafios e Recomendações
4. Os requisitos, as ideias mudam.
3. Definir valor para negócio.
2. Frequência de uso de cada estória.
(a frequência pode variar em grupos de usuários e
pode haver falta de conhecimento real sobre a
atividade dos usuários)
1. Como escrever as user story?
(“Busca” “Digitar palavra” ou “Encontrar produtos”?)
Não usar termos técnicos para descrever as estórias.
Qual o objetivo do usuário? Usar “Eu como [usuário]
preciso de...”
Observações, entrevistas contextuais e
testes de usabilidade.
Participação do dono do produto, equipe multidisciplinar.
Repriorização, ciclo de vida iterativos de design,
reuniões diárias.

30. EM GRUPO!
Fazer um User Story Map Backlog para
seu produto.
Enviar apresentação para email até a
próxima aula com “PUC PFC USM” no
subject.
Não esquecer nome dos integrantes!
TO DO DONE

31. Marcello Cardoso
contato@latitude14.com.br / (31) 9793-6456 - skype: mcardoso82