Criar uma história de usuário

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

Destacar a importância de estabelecer um critério de aceitação.
Resumir o conceito de INVEST para escrever a história de um usuário.
Identificar erros comuns a serem evitados ao escrever a história de um usuário.

Equipe do projeto: prepare-se!

É recomendado que um workshop de escrita de histórias de usuários seja realizado perto do início de um projeto. Os workshops de escrita de histórias são organizados para incluir a equipe do projeto: gerente(s) de produto, Desenvolvedor(es), administrador(es), designer(s) de experiências do usuário, usuários e assim por diante. Os participantes pensam para gerar ideias para histórias. À medida que as histórias dos usuários são desenvolvidas, a criatividade de toda a equipe deve ser envolvida. Essas histórias iniciais de usuários não são escritas definitivas. A beleza das histórias dos usuários é que elas incentivam o desenvolvimento iterativo e podem ser refinadas quantas vezes for necessário.

Ao formular histórias de usuários com sua equipe do projeto, não faça nenhuma suposição sobre como as histórias de usuários serão implementadas, como quais componentes ou serviços serão afetados. A equipe de desenvolvimento/implementação toma essas decisões durante as reuniões de planejamento.

Aceitar a necessidade dos critérios

É natural que quando um grupo de projeto é formado, o mesmo problema seja visto de diferentes ângulos. Essas diferentes perspectivas são extremamente necessárias e úteis, mas podem ser frustrantes se não houver um medidor de sucesso estabelecido. Também conhecido como critérios de aceitação. Os critérios de aceitação são um conjunto de declarações, cada uma com um resultado claro de aprovação/reprovação, adicionadas a uma história de usuário. Simplificando, os critérios de aceitação especificam as condições sob as quais uma história de usuário é realizada. Eles devem ser expressos claramente, em linguagem simples, sem ambiguidades sobre o resultado esperado. Critérios de aceitação bem escritos beneficiam várias etapas e partes interessadas de um projeto, incluindo:

Esclarecer o escopo para a equipe do projeto
Auxiliar a equipe de desenvolvimento/implementação
Garantir que os testadores saibam o que deve ser testado

Os critérios de aceitação devem declarar intenção, mas não uma solução. Pense no O quê e não no Como.

Um mau exemplo de critérios de aceitação porque foca na solução: Um gerente distrital pode clicar em um botão Aprovar/Desaprovar para aprovar o preço de um produto com desconto.
Um bom exemplo de critérios de aceitação porque foca na intenção: Um gerente distrital pode aprovar ou desaprovar o preço de um produto com desconto.

Quando o workshop da declaração da história do usuário estiver concluído, será o momento de adicionar os critérios de aceitação. Vamos voltar para a história do usuário da unidade anterior.

Exemplo de história do usuário: Como representante de atendimento ao cliente, quero poder assumir novos casos e me comunicar com os clientes para que eu possa proporcionar experiências altamente personalizadas aos clientes.

Exemplos de critérios de aceitação para esta história de usuário podem ser:

Assumir casos da fila.
Enviar um email aos clientes da página do caso.
Atualizar detalhes do caso: status, assunto, descrição.

Os critérios de aceitação também podem ser formatados como instruções condicionais (se/então). Veja o critério de aceitação acima escrito como uma instrução condicional: Se estiver em uma página de caso, o recurso de email do cliente estará acessível. Independentemente do formato, cada história do usuário deve ter pelo menos um critério de aceitação. Cada critério deve ser testado independentemente e respondido com um verdadeiro ou falso.

Satisfeito com critérios de aceitação? Hora de praticar um pouco. Selecione os critérios de aceitação aplicáveis para o exemplo de história do usuário listado.

Você pode estar pensando, como vou me lembrar de todos esses detalhes ao escrever histórias de usuários e critérios de aceitação? Dica: Hora de Investir na memorização de um acrônimo.

Investir na história do usuário

Se sua lista de tarefas pessoais incluir “saber mais sobre uma nova lista de verificação”, temos boas notícias! Você está prestes a riscar isso da sua lista. Os analistas comerciais da Salesforce podem usar a lista de verificação INVEST (criada por Bill Wake em 2003) para avaliar a qualidade de uma história do usuário. Se a história do usuário não atender a uma das verificações, ela provavelmente precisará ser reescrita.

Uma história de usuário de sucesso é:

Independent (Independente): Uma história de usuário deve ser independente e não se sobrepor em conceito com outra história de usuário.
Negotiable (Negociável): Uma história de usuário não é um contrato. Uma história é um convite para uma conversa. Captura a essência, não os detalhes.
Valuable (Útil): A história do usuário precisa ser útil para o usuário final. Se uma história não tiver valor, ela não deverá ser criada.
Estimável: A linha do tempo de uma história de usuário bem-sucedida pode ser estimada. Não é necessária uma estimativa exata, mas apenas o suficiente para ajudar a priorizar e agendar o desenvolvimento/implementação da história.
Small (Curta): As histórias mais eficazes dos usuários são curtas. As histórias de usuários mais curtas tendem a obter estimativas de linha do tempo mais precisas. Lembre-se, os detalhes podem ser elaborados com conversas.
Testable (Verificável): Uma boa história de usuário pode ser testada. No caso de uma história de sucesso, qualquer pessoa da equipe do projeto pode olhar para a história do usuário e dizer: “Sim, eu entendo essa história do usuário tão bem que posso escrever critérios de aceitação para ela.”

Erros a evitar

Assim como qualquer outro processo que envolva várias etapas, erros podem acontecer e as histórias dos usuários não estão isentas de tais erros. Felizmente, as histórias dos usuários são ajustáveis. Há sempre espaço para iterar. Mas por que não dar o seu melhor para evitar erros desde o início? Veja alguns erros comuns das histórias dos usuários e dicas de como um analista comercial do Salesforce pode se livrar deles.

A equipe do projeto não se reuniu para escrever uma história.

Resultado: A história do usuário não representará as várias perspectivas da equipe do projeto. Reescrever extensivamente a história do usuário é inevitável.
Como evitar: Agende uma sessão de escrita de histórias no início do projeto. Revise e discuta continuamente a história do usuário com os membros da equipe do projeto.

O quem da história do usuário é um usuário indefinido.

Resultado: A equipe de desenvolvimento tentará entender o papel das motivações e necessidades desse usuário uma vez que ele é indefinido. A história do usuário não produzirá o resultado pretendido.
Como evitar: Antes de criar a história de um usuário, crie uma lista de personas de usuários definidos. Essas personas bem definidas podem então ser referenciadas ao criar a história de um usuário, desenvolver/implementar as soluções e testar.

O “por que” na história do usuário é específico do recurso.

Resultado: A história do usuário é excessivamente técnica e focada em detalhes, mais parecida como uma descrição da ferramenta do que uma história. As necessidades do usuário não são atendidas.
Como evitar: Mantenha as necessidades do usuário como prioridade número um. Revise a história do usuário depois de escrita para ver se ela se concentrou demais em detalhes. Receba sempre bem o feedback da equipe do projeto.

Os critérios de aceitação são muito vagos.

Resultado: Sem critérios específicos de aceitação testáveis, não há uma maneira confiável de medir quando a história do usuário é concluída com sucesso.
Como evitar: Certifique-se de que todos os critérios de aceitação são independentes e podem ser respondidos com verdadeiro ou falso. Trabalhe com a equipe do projeto para escrever critérios de aceitação que estejam alinhados com o objetivo do usuário.

A história do usuário foi atribuída à equipe de implementação sem uma discussão em equipe.

Resultado: A probabilidade das histórias dos usuários serem mal interpretadas durante o desenvolvimento é muito maior. O produto final pode estar longe do que se pretendia.
Como evitar: Revise histórias com sua equipe quando atribuí-las. Revise detalhes, destaque a intenção e garanta que a equipe esteja sintonizada.

Como você pode ver, todos esses erros são evitáveis quando o processo da história do usuário é devidamente seguido. Atalhos não devem ser usados. Confie no processo e o resultado final será uma solução focada no sucesso do cliente/usuário final.

A definição óbvia de histórias de usuários sendo histórias sobre usuários não parece tão distante agora, certo? Você aprendeu muito sobre histórias de usuários: propósito, partes, participantes para envolver, como testar, erros a evitar e até um acrônimo para ajudar a avaliar uma história de usuário. Agora use seu novo conhecimento sobre seu novo melhor amigo e escreva algumas histórias sobre usuários.