User Story Mapping
7 gostaram903 visualizações
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.
![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.](https://image.slidesharecdn.com/usm-141104025840-conversion-gate02/85/User-Story-Mapping-29-320.jpg)
User Story Mapping
- 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?
- 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