A User Story possui três aspectos críticos, chamados de “os três C’s”: o Cartão, as Conversas e a Confirmação. Veremos em seguida o que cada um desses aspectos significa (Cohn, 2004).
Experimente ouvir este conteúdo. Dê o play!
Cartão
O Cartão é a descrição da necessidade do usuário, ou seja, a própria User Story. Essa descrição é concisa, e assim suficiente para apenas identificar qual é e de que se trata essa necessidade. O nome “Cartão” é dado porque frequentemente as User Stories são escritas em cartões de índice ou fichas.
Os padrões mais utilizados para se escrever o Cartão da User Story estabelece três parâmetros da necessidade do usuário: “QUEM”, “O QUÊ” e “POR QUÊ”.
“QUEM” define quem é o usuário que tem a necessidade. Pode ser representado por um tipo de usuário do produto (como “Comprador de Livros” ou “Administrador do Sistema”, por exemplo), por uma persona ou até mesmo por um usuário específico.
“QUEM” ajuda a criar no leitor da User Story uma imagem mental desse usuário. User Stories que começam “Eu, enquanto um usuário…” ou “Eu, enquanto um cliente…”, portanto, não atingem esse objetivo e devem ser evitadas.
Personas são frequentemente utilizadas com esse propósito. Uma persona é um usuário imaginário que representa um grupo distinto de usuários do produto, que tem necessidades e comportamentos específicos. A persona possui um nome, que pode ser inventado ou ser emprestado de alguma personalidade conhecida, e uma descrição. Pode também possuir uma foto. Na figura abaixo, descrevemos “Sara Sensível”, uma persona de um site de relacionamentos.
Exemplo de persona
Personas são frequentemente utilizadas com esse propósito. Uma persona é um usuário imaginário que representa um grupo distinto de usuários do produto, que tem necessidades e comportamentos específicos. A persona possui um nome, que pode ser inventado ou ser emprestado de alguma personalidade conhecida, e uma descrição. Pode também possuir uma foto. Na figura abaixo, descrevemos “Sara Sensível”, uma persona de um site de relacionamentos.
Uma User Story para essa persona poderia ser algo assim: “Para encontrar alguém com interesses parecidos com os meus, enquanto Sara Sensível, eu quero comparar os interesses de diferentes candidatos”.
“O QUÊ” define qual é a necessidade do usuário. Tradicionalmente, os requisitos do produto são representados apenas por essa parte.
“POR QUÊ” define qual o benefício do usuário ao ter a funcionalidade desenvolvida para atender a essa necessidade. Em outras palavras, qual o valor direto obtido pelo usuário.
Ponto de vista do usuário
O ponto de vista do usuário é o de quem tem um problema (necessidade) ou uma solução? Um problema. Vejamos, a seguir, uma User Story:
“Eu, enquanto Comprador de Livros, quero buscar livros por nome para escolher o que vou comprar.”
Essa é a forma mais comum de se escreverem User Stories e é perfeitamente aceitável. No entanto, buscar livros por nome é um problema ou uma solução? É uma funcionalidade e, portanto, uma solução. Então essa User Story não está realmente expressa sob a perspectiva do usuário. Qual seria o problema do usuário então? Se a reescrevermos da seguinte forma:
“Eu, enquanto Comprador de Livros, quero encontrar um livro cujo nome sei para escolher comprá-lo.”
O problema do usuário nesse caso é encontrar um livro cujo nome conhece, e uma das possíveis soluções é buscar livros por nome. Outra seria mostrar simplesmente uma lista de todos os livros para que ele possa encontrar o que precisa. Não que uma lista seja melhor que uma busca, mas essa alternativa poderia, por exemplo, ser mais adequada para uma versão inicial do sistema devido a seu custo mais baixo.
Expressar a User Story a partir do problema e não de uma solução particular abre espaço para discussões sobre as possíveis soluções para o mesmo problema. Assim, pode fazer com que soluções mais adequadas sejam encontradas.
Na figura abaixo, vemos o padrão mais comum para escrita de User Stories:
Exemplo de padrão para User Stories
Esse formato, embora largamente utilizado, não é obrigatório. Podemos ver na figura abaixo uma outra forma de dizer o mesmo, mas com ênfase no benefício do usuário.
Outro padrão de escrita de uma User Story
Outra forma simples de se escrever a User Story é: “Um pode para ”. Por exemplo, se imaginarmos como produto um aplicativo móvel para viagens, uma de suas User Stories poderia ser: “Um Viajante de Turismo quer mostrar sua viagem para seus amigos para lhes causar inveja”.
Ao escrever uma User Story em algum desses formatos, o Product Owner realiza uma profunda reflexão para estabelecer quem é o usuário da funcionalidade a ser desenvolvida e qual o benefício que esse usuário obtém, o que lhe permite manter os itens do Product Backlog alinhados à Visão do Produto. Ao mesmo tempo, a User Story ajuda o Time de Desenvolvimento a manter seu foco no usuário e em qual benefício é esperado que ele obtenha.
Conversas
São conversas sobre a User Story, por onde a solução de negócios e os detalhes dessa solução são discutidos, negociados, definidos e então documentados na forma de Critérios e Testes de Aceitação. Elas geram uma compreensão compartilhada sobre o que é necessário para que a funcionalidade gere valor de negócio e retorno ao investimento. As conversas são imprescindíveis para o trabalho do Time de Desenvolvimento, uma vez que o Cartão não possui detalhes que permitam que o item seja desenvolvido.
Em geral, participam dessas conversas o Product Owner, membros do Time de Desenvolvimento e outras pessoas de negócios envolvidas, caso haja, mas qualquer pessoa que possa contribuir com detalhes pode participar.
Tomemos como exemplo a User Story do exemplo anterior, “Um Viajante de Turismo quer mostrar sua viagem para seus amigos para lhes causar inveja”. O Time de Desenvolvimento e Product Owner, por meio de conversas, podem concluir que permitir o compartilhamento de fotos e vídeos na rede social do momento diretamente do aplicativo é a solução de negócios desejada, e a partir daí escrevem os Critérios de Aceitação, que serão transformados em Testes de Aceitação automatizados no decorrer do Sprint.
As conversas, que podem ocorrer em qualquer momento, são geralmente parte das sessões de Refinamento do Product Backlog (veja “[ref-label refinamento]. Refinamento do Product Backlog”).
Confirmação
São critérios e testes deles derivados que documentam os detalhes da User Story, definindo seus limites. Ou seja, são regras que estabelecem como a funcionalidade deve se comportar uma vez implementada. Esses critérios são chamados de Critérios de Aceitação e os testes, de Testes de Aceitação.
Enquanto todas as User Stories devem satisfazer à mesma Definição de Pronto, cada User Story possui seu próprio conjunto de Critérios e Testes de Aceitação.
Critérios de Aceitação são expressos por enunciados pequenos e de fácil entendimento. São utilizados para determinar quando a funcionalidade produzida pelo Time de Desenvolvimento está completa e, assim, nada mais deve ser adicionado a ela.
Os Critérios de Aceitação ajudam o Product Owner a determinar para o Time de Desenvolvimento o que ele precisa para que essa funcionalidade propicie valor. A partir desses critérios, o Time de Desenvolvimento gera os Testes de Aceitação.
Os Critérios de Aceitação são negociados e definidos antes do desenvolvimento da funcionalidade, geralmente em sessões de Refinamento do Product Backlog.
Como exemplo, vamos imaginar que a seguinte User Story é forte candidata a ser desenvolvida no próximo Sprint:
Eu, enquanto Comprador de Livros, quero utilizar meu cartão de crédito no pagamento dos livros escolhidos, para ter praticidade e segurança no pagamento.
Assim, em uma das sessões de Refinamento do Product Backlog, os seguintes Critérios de Aceitação podem ser definidos para a User Story, entre outros:
Critério #1: somente podemos aceitar cartões de crédito com bandeiras com que temos convênio.
Critério #2: somente podemos aceitar cartões de crédito com data de expiração no futuro.
Testes de Aceitação são criados a partir de aplicações de exemplos aos Critérios de Aceitação, onde se verificam se dadas entradas estão produzindo os resultados esperados. Eles servem para verificar se a funcionalidade está se comportando conforme esperado, sob um ponto de vista de negócios.
Ao se trabalhar com Testes de Aceitação automatizados e executados frequentemente, reduzem-se os riscos de que mudanças no produto, muito comuns em projetos Ágeis, gerem erros que passem desapercebidos. Existem inúmeras ferramentas para fazer essa automatização, e diversas permitem sua escrita em linguagem humana.
A seguir, vemos a aplicação de exemplos de dados aos Critérios de Aceitação definidos anteriormente. Para efeitos didáticos, os Testes de Aceitação estão descritos aqui de forma textual. Para a User Story e os Critérios do exemplo anterior:
Critério #1: somente podemos aceitar cartões de crédito com bandeiras com que temos convênio.
Testes de aceitação:
- Comprador de Livros utiliza cartão de crédito Visa
- Aceitou = correto.
- Recusou = errado, deve ser corrigido!
- Comprador de Livros utiliza cartão de crédito MasterCard
- Aceitou = correto.
- Recusou = errado, deve ser corrigido!
- Comprador de Livros utiliza cartão de crédito Amex
- Recusou = correto.
- Aceitou = errado, deve ser corrigido!
Critério #2: somente podemos aceitar cartões de crédito com data de expiração no futuro.
Testes de aceitação:
- Comprador de Livros utiliza cartão de crédito com expiração em 01/01/2020
- Aceitou = correto.
- Recusou = errado, deve ser corrigido!
- Comprador de Livros utilizou cartão de crédito com expiração em 01/01/2000
- Recusou = correto.
- Aceitou = errado, deve ser corrigido!
Nos exemplos acima, pode-se ver claramente que as bandeiras de cartão aceitas são Visa e MasterCard, enquanto que Amex não.
Para alguns Critérios de Aceitação, como por exemplo “o botão deve ser azul”, não é possível gerar Testes de Aceitação e, assim, não podem ser automatizados. Por meio de testes exploratórios, os membros do Time de Desenvolvimento realizam a verificação desses critérios.
Os Critérios e Testes de Aceitação cobrem cada aspecto de negócios da User Story e, assim, geralmente são suficientes para documentá-las.
