Guia Scrum | 21. Erros de User Story

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

Os erros mais comuns em histórias de usuário – índice:

1. Introdução
2. Problemas com 3W
3. Problemas com 3C
4. Erros em histórias de usuário – Resumo

Introdução

A história de usuário pode ser uma ótima ferramenta para motivar a equipe a propor novas soluções para problemas apresentados a partir da perspectiva do usuário. Escrevemos sobre o que é uma história de usuário em uma entrada separada. E neste artigo, apresentamos o INVEST, que é um método popular para escrever boas histórias de usuário. Hoje, vamos nos concentrar nos erros em histórias de 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 capacidades o produto possui e o que ele pode fazer?)
• Por quê? (Qual é o propósito disso?)

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 relacionados a Quem? e Por quê?

Quem – persona do usuário

Um dos erros mais comuns ao criar histórias de usuário é não responder à pergunta de forma precisa o suficiente: para quem? Em outras palavras, quem é o usuário para quem a mudança planejada é destinada?

Frequentemente, uma resposta genérica apontando para o Cliente ou Usuário Final como o 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.

Após analisar sua história de usuário, você pode descobrir que ela conta as histórias de diferentes pessoas ao mesmo tempo. Se houver muitos usuários-alvo, vale a pena considerar dividir a história de 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 de usuário se torna a fonte de problemas. Ela deve especificar o valor comercial das mudanças feitas durante a execução da história de usuário. Veja um exemplo de erros em histórias de usuário onde a descrição de uma 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 a razão para comprar a varinha mágica, esta história de usuário adiciona outro item à lista de compras do cliente potencial. Portanto, ao preparar uma história de usuário, não se esqueça das razões para as alterações na funcionalidade do produto.

Problemas com 3C

Podemos dividir o processo de trabalho com histórias de usuário em três etapas chamadas 3Cs:

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

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

Cartão

O cartão de memória que armazena a história de usuário tem uma capacidade limitada. Portanto, os problemas mais comuns dizem respeito ao comprimento e volume da história de usuário. A história de usuário precisa de coerência e não pode enrolar, como dizem, a tal ponto que cada palavra conta.

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

Conversa

A formulação de uma frase da história de usuário é o ponto de partida para uma conversa com a equipe de desenvolvimento. Portanto, é incorreto tratá-la como uma descrição da tarefa a ser realizada. Isso desabilita a possibilidade de negociações e discussões sobre várias maneiras de sua implementação. A história de usuário não deve ser tratada como uma descrição de requisitos para uma nova funcionalidade do produto, mas sim como 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 de usuário.

Confirmação

Escrevemos sobre os critérios de aceitação que devem ser definidos para cada história de usuário em detalhes no texto que descreve o que é uma história de usuário. Um dos erros comuns, no entanto, é a falta de clareza dos critérios de desempenho.

Uma história de usuário bem escrita contém uma descrição da situação em que é implementada. Seu teste é que o usuário aproveite a nova funcionalidade criada pela equipe de desenvolvimento.

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

Erros em histórias de usuário – Resumo

Ao preparar e aplicar histórias de usuário, vale a pena seguir as seguintes regras:

• Identificar precisamente o Usuário afetado pela mudança
• Definir claramente o propósito de construir uma nova funcionalidade do produto
• Manter seu Volume o mais curto possível
• Tratar a história de usuário como um ponto de partida para discussões com a equipe de desenvolvimento
• Estabelecer 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.