Guia Scrum | 21. Erros na história do usuário

As histórias de usuário descrevem como uma nova funcionalidade do produto funciona na linguagem cotidiana ou comercial. No entanto, sua preparação exige muito tempo, esforço e reflexão. Na entrada de hoje, apontamos os erros mais comuns da história do usuário e sugerimos como lidar com eles.

Os erros mais comuns da história do usuário – índice:

1. Introdução
2. Problemas com 3W
3. Problemas com 3C
4. Erros da história do usuário - Resumo

Introdução

A User Story pode ser uma ótima ferramenta para motivar a equipe a propor novas soluções para problemas apresentados sob a perspectiva do usuário. Escrevemos sobre o que é a história do usuário em uma entrada separada. E neste artigo, apresentamos o INVEST, que é um método popular de escrever boas histórias de usuário. Hoje vamos nos concentrar nos erros da história do usuário.

Problemas com 3W

Uma história de usuário adequada responde às perguntas:

• Quem? (Quem é o usuário-alvo do Produto?)
• O que? (Quais recursos o Produto possui e o que ele pode fazer?)
• Por quê? (Que finalidade serve?)

No entanto, problemas podem acompanhar as respostas a cada uma dessas perguntas. O problema menos comum é a dúvida sobre o que deve mudar no produto em resposta às necessidades do cliente. Portanto, vamos nos concentrar em problemas relativos a Quem? e porque?

Quem – persona do usuário

Um dos erros mais comuns cometidos ao criar User Stories é não responder com precisão suficiente à pergunta: para quem? Em outras palavras, quem é o usuário para quem a mudança planejada se destina?

Muitas vezes, uma resposta genérica apontando para o Cliente ou Usuário Final como destinatário da mudança não é suficiente. A solução para esse problema é imaginar o destinatário como uma persona específica. Uma persona é uma imagem modelo do cliente-alvo. Em outras palavras, uma persona é uma representação da pessoa que usará o Produto de uma maneira específica.

Depois de analisar sua história de usuário, você pode descobrir que ela conta histórias de pessoas diferentes ao mesmo tempo. Se houver muitos usuários-alvo, vale a pena considerar dividir a história do usuário em fragmentos menores para evitar ações contraditórias, mutuamente exclusivas ou simplesmente ineficazes.

Por quê? – um objetivo mal definido

Às vezes, a última seção da história do usuário se torna a fonte de problemas. Ele deve especificar o valor comercial das alterações feitas durante a execução da história do usuário. Dê uma olhada em um exemplo de erros da história do usuário em que a descrição da funcionalidade adicional substitui o objetivo:

Como cliente, quero comprar uma varinha mágica com um clique porque quero comprar um tapete voador na próxima semana.

Em vez de dar o motivo da compra da varinha mágica, esta história de usuário adiciona outro item à lista de compras do cliente em potencial. Portanto, ao preparar uma User Story, não se esqueça dos motivos das alterações na funcionalidade do Produto.

Problemas com 3C

Podemos dividir o processo de trabalho com User Stories em três etapas chamadas 3Cs:

• Cartão – O cartão no qual a história do usuário é salva
• Conversa – Uma conversa dentro do Time Scrum sobre o cartão de história do usuário
• Confirmação - definição de critérios de aceitação confirmando que uma tarefa foi concluída

Erros podem ocorrer em qualquer um deles, que descrevemos abaixo.

Cartão

O cartão de memória que armazena a história do usuário tem capacidade limitada. Portanto, os problemas mais comuns dizem respeito à duração e ao volume da User Story. A história do usuário precisa de coerência e sem rodeios, como se costuma dizer, em um grau tão preciso que cada palavra conta.

Isso ocorre porque o problema do cartão User Story tem duas dimensões. Uma é a forma como é formulado: conciso e contendo uma quantidade mínima necessária de enumeração. A segunda é o tamanho real da história do usuário. Uma frase geral pode expressar um grande número de tarefas que não podem ser concluídas durante um único Sprint.

Conversação

A formulação de uma frase da história do usuário é o ponto de partida para uma conversa com a equipe de desenvolvimento. Portanto, é incorreto tratá-lo como uma descrição da tarefa a ser executada. Desabilita a possibilidade de negociação e discussão sobre as diversas formas de sua implementação. A História do Usuário não deve ser tratada como uma descrição de requisitos para a funcionalidade de um novo produto, mas sim um convite para iniciar uma conversa sobre soluções técnicas específicas que levarão à realização do valor comercial definido pela História do Usuário.

Confirmação

Escrevemos detalhadamente sobre os critérios de aceitação que devem ser definidos para cada User Story no texto que descreve o que é uma User Story. Um dos erros comuns, no entanto, é a falta de imprecisão dos critérios de desempenho.

Uma história de usuário bem escrita contém uma descrição da situação na qual ela é implementada. Seu teste é que o Usuário aproveite a nova funcionalidade criada pela Equipe de Desenvolvimento.

Uma ferramenta útil para validar a User Story é desenvolver um teste de aceitação. Isso geralmente está do outro lado do cartão que contém a história do usuário.

Erros da história do usuário - Resumo

Ao preparar e aplicar User Stories, vale a pena seguir as seguintes regras:

• Identifique com precisão o usuário afetado pela mudança
• Definir claramente o propósito de construir a nova funcionalidade do produto
• Mantenha seu Volume o mais curto possível
• Trate a história do usuário como um ponto de partida para discussões de solução com a equipe de desenvolvimento
• Estabeleça regras claras para aceitação

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto