Você pode escrever os itens do seu backlog de produto de diversas formas. Uma das mais populares é utilizando o formato de História de Usuário. Para entender sobre o que elas são e como construí-las veja esses dois artigos: O que é a User Story?, Como é a User Story?.
História de Usuário (User Story)
Resumindo aqui, a História de Usuário é um formato sucinto para escrita dos requisitos necessários para a construção de um produto. Ela deve ser compreensível para o clientes e consumidores.
A extensa lista de documentos de requisitos é ineficiente e por isso a história de usuário é muito enxuta. Estimulamos a comunicação face a face ao invés de e-mails e ferramentas de gestão de documentos.
Na Agilidade queremos melhor a comunicação, aumentar a colaboração e criar times realmente multidisciplinares. Isso dá um resultado muito melhor do que passar a documentação de um lado para o outro sem interação alguma entre as partes.
Formato de História de Usuário
O formato que se popularizou foi:
Eu, enquanto <Usuário / Persona / Cliente>, desejo <benefício> para / pois / porque <propósito>.
Exemplo: Eu, enquanto deficiente visual, desejo que os locais que eu tenho que ir sejam acessíveis para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais onde quero ir.
Esse não é o único formato possível para uma história de usuário, mas ele tem algumas vantagens. Ele responde a três perguntas importantíssimas: Quem? O que? Por que?
Neste artigo falaremos especificamente de algumas disfunções comuns quando as pessoas estão começando a utilizar a prática riquíssima da história de usuário.
Partindo direto para a solução
Erro comum quando estamos começando na agilidade. A história de usuário utilizada no exemplo acima ficaria assim: Eu, enquanto deficiente visual, desejo que as placas indicativas do prédio estivessem escritas em Braile para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais onde quero ir.
Perceba que escrever em Braile na placa já ancora o time a uma solução. Todos imaginarão como escrever as placas em Braile. Perdemos uma rica discussão sobre outras formas de resolver o problema.
Por exemplo: Placas que falem o local quando algum botão é pressionado; placas que falam o local acionadas com sensor de presença; redesenho das salas para tornar o ambiente mais acessível; etc.
“Tequinês”
Uma pequena variação da anterior. Essa acontece normalmente quando o Product Owner vem da área técnica. É muito comum que ele utilize parte do jargão da área.
Exemplo: Eu, enquanto deficiente visual, desejo seja instalado um módulo de sensor de movimento 2 metros com alto falante 80 Watts WRMS para quando eu passar perto da porta o local seja falado.
O deficiente visual quer realmente deseja seja instalado um módulo de sensor de movimento 2 metros com alto falante 80 Watts WRMS? Sem sombra de dúvida é uma possível solução, mas com certeza não é a única. Dependendo dos jargões utilizados, a conversa fica inviável.
Sem Conversa
Alguns times esquecem que para que a História de Usuário funcione é necessário que ela siga a regra dos 3Cs (Cartão, Conversa e Confirmação). Cartão é a própria história. Ela apresenta um problema que o consumidor do meu produto sofre. Sem a conversa não há como discutir quais as soluções possíveis.
Além disso, as histórias são sucintas. É praticamente impossível começar a construir qualquer coisa sem a discussão entre o time de desenvolvimento e pessoal de negócio.
Sem Confirmação
O último C é Confirmação de que todos envolvidos na criação do produto entenderam a solução que será construída. Uma boa prática é escrever esses combinados como critérios de aceitação. Há outro formato de critério de aceitação que é bastante comum: Dado que <Situação>, quando <ação>, então <resultado esperado>.
Exemplo: Dado que o deficiente visual se aproximou de uma placa indicativa de local quando ele a passar pela placa, então a placa falará o nome do local.
Os critérios de aceitação evitam surpresas no final da construção. Imagina se saíssemos da reunião sem a confirmação. Poderíamos ter pessoas que pensando que as placas teriam escritas em Braile, outras imaginando uma placa falando com botão, etc.
Consumidor genérico
Eu, enquanto EMPRESA desejo… A empresa é muita gente. Quem será poderemos chamar para obter feedbacks? Serve qualquer um do presidente ao estagiário?
Eu, enquanto CLIENTE desejo… Todos os clientes têm a mesma necessidade? Posso chamar qualquer um aleatoriamente?
Ao escrever uma história de usuário, seja o mais específico possível. Quem é a pessoa que sofre do problema que estamos tentando resolver? Será ela que chamaremos para obter feedbacks.
História Técnica
Muito, muito, muito, muito cuidado mesmo com isso!
Quando falamos de entregas em times ágeis, estamos falando de times multidisciplinares que conseguem entregar de ponta a ponta. Uma fatia de cada vez.
Não é uma boa prática criar uma história de usuário para fazer uma tarefa técnica. Por exemplo: Eu, enquanto Administrador do Banco de Dados desejo criar um índice na tabela para tornar as consultas mais rápidas. Se o índice for criado e as consultas permanecerem lentas. O que faremos?
Melhor seria: Eu enquanto, Consumidor XPTO desejo que o relatório XYZ seja mais rápido, pois estou perdendo muito tempo para realizar o meu trabalho. Perceba que podemos ter várias tarefas técnicas dentro dessa história. Inclusive a criação de índice.
As histórias de usuário demasiadamente técnicas acabam fazendo que o time ao invés de entregar uma fatia com valor para o consumidor, acabe entregando apenas tarefas técnicas que nada agregam no nosso negócio. São exemplos comuns: História de Back-end, História de Front-end, História de UX, História de Banco de Dados, História de Arquitetura, etc.
Normalmente elas aparecem quando não temos um time multidisciplinar, não focamos na entrega de ponta a ponta ou temos pessoas que ficam em tempo parcial no projeto.
Nunca se esqueça que o nome completo da história é História de USUÁRIO. Deve prover algo de valor para o consumidor.
Spikes
É possível fugir dessa regra quando temos a necessidade de estudar alguma tecnologia que o time desconhece. Nesse caso utilizamos o Spike. Ele se parece com uma história, porém não provê valor para o usuário. Seu esforço deve ser estimado, ele deve se tornar visível em um quadro de tarefas e também deve possuir um prazo limite, por exemplo, uma Sprint.
Dívida Técnica
Outro motivo que pode fugir à regra é quando criamos as famosas gambiarras (soluções técnicas de qualidade interna duvidosa). Quem olha por fora acha o produto lindo, mas não sabe o balaio de gato que está sustentando o funcionamento dele. Isso é algo que cria uma dívida técnica. Se não pagarmos pelo menos uma parte da dívida, será inviável incrementar o produto nas próximas iterações.
Podemos ter Pagamento de Dívidas técnicas. O comportamento é similar ao da história ou do spike. O esforço deve ser estimado, ela deve ir para o quadro de tarefas e tem um limite de tempo para acabar.
A dívida não vem só da gambiarra. Ela também pode ter sido gerada por obsolescência ou a descoberta de algo novo e melhor que pode substituir a implementação atual.
História sem propósito
Exemplo: Eu, enquanto deficiente visual, desejo que os locais que eu tenho que ir sejam acessíveis.
Se a história de usuário não tem um PARA, eu não sei o porquê de fazê-la. Qual o problema estamos resolvendo. Utilizando o exemplo acima. Se eu instalar uma rampa de acesso resolvo o problema? Um chão tátil resolve? Não sei porque o problema não está claro.
É muito comum aparecer histórias sem propósito quando alguém de negócio ou gestores tem uma funcionalidade de estimação (pet feature). Algo que não trará retorno algum, mas a pessoa quer porque quer. Muitas das vezes, ela vai utilizar seu poder hierárquico para que a história seja feita.
Fato é que quando há muita dificuldade em achar o propósito da história de usuário, temos um forte sinal de que ela não é necessária. Portanto, deve ser descartada. Na pior das hipóteses, mova ela para o final do backlog.
Conclusão
Evitar essas disfunções não é fácil, mas com a prática conseguimos. Ficou com alguma dúvida? Achou que faltou alguma disfunção? Deixe aqui nos comentários.
Aproveito para convidá-lo para participar do nosso treinamento de Certified Scrum Product Owner (CSPO) e já aprender na prática como criar boas histórias de usuário.
Veja também o nosso blog mais artigos sobre o papel do Product Owner.
