Preparo da história de usuário

O primeiro passo é documentar dois elementos importantes em uma história de usuário. Os elementos fornecem clareza sobre o que deve ser desenvolvido e quais critérios devem ser atendidos para a história de usuário ser considerada completa.   

Os dois elementos são:

• Descrição da história de usuário
• Critérios de aceitação 

Também é possível adicionar elementos opcionais a cada história de usuário para esclarecer os detalhes do requisito com anexos e notas técnicas. 

Todas as histórias têm um tamanho e status para ajudar no gerenciamento de histórias de usuário. A atualização é realizada à medida que a história de usuário avança em seu ciclo de vida, desde a forma inicial até sua conclusão.

O objetivo da descrição da história de usuário é resumir os requisitos de negócios do cliente. A descrição da história de usuário assegura que você capture quem precisa do recurso ou função, o que é necessário e por que é necessário. Precisa ser curta, escrito em linguagem de negócios que seja fácil de entender e identifique claramente o valor do negócio.  

A formulação típica de uma história de usuário segue um formato de frase simples.

• Como um... [Quem? - Insira o usuário]  
• Eu quero... [O quê? - Insira o que eles querem fazer]    
• para que... [Por quê? - Insira o valor do negócio].

A preparação e as discussões das histórias de usuários são extremamente importantes.  Só é possível chegar ao entendimento coletivo por meio do diálogo. Resista à tentação de converter o entendimento coletivo em uma documentação complexa. Concentre-se na essência da história de usuário e complete os detalhes com anexos.

No exemplo abaixo, a descrição está escrita em termos de negócios que indicam de maneira clara o usuário, a necessidade e o valor de negócio da implementação da história de usuário. Veja também que a descrição é curta.

Os critérios de aceitação refinam a história de usuário para que os desenvolvedores entendam o que o aplicativo deve fazer e os testadores tenham clareza sobre o que precisa ser testado. O Product Owner deve definir a experiência de negócio esperada da história de usuário e aprovar os critérios de aceitação. Os critérios de aceitação da história de usuário são escritos em termos claros e fáceis de entender para a empresa (e para os membros não técnicos da equipe). 

Os critérios de aceitação são escritos em termos de resultados e não como instruções técnicas para a equipe de desenvolvimento. Eles são intencionalmente negociáveis, permitindo que a equipe de desenvolvimento trabalhe com a empresa de forma a alcançar a solução. Os critérios de aceitação, embora sejam negociáveis, também devem ser específicos o suficiente para serem testados. 

No exemplo abaixo, os critérios de aceitação são escritos como resultados específicos e testáveis.

A história de usuário utilizada como exemplo ilustra uma abordagem de afirmação para formular seus critérios de aceitação. Há vários outros estilos para documentar os critérios de aceitação, como capturar critérios baseados em cenários. Por exemplo, sua equipe pode optar por utilizar a abordagem Dado, Quando, Então (Given, When, Then) da seguinte forma:

• Given...{pré-condição}: Exemplo: "Um membro premium se qualifica para promoções de ofertas gratuitas..."
• Quando...{algo é feito}. Exemplo: "... selecionaram suas categorias de ofertas preferidas e completaram o processo de cadastro..."
• Então...{resultado esperado} Exemplo: "... o sistema adiciona automaticamente o membro às promoções selecionadas."

No início do projeto, sua equipe estabelece o que se entende por definição de pronto (Definition of Ready, DoR). A equipe estabelece a DoR durante a fase de Preparo, para definir a referência para as verificações de qualidade das histórias de usuários. Cada projeto chega a esse acordo com os stakeholders técnicos e de negócios relevantes da equipe. A DoR lista os critérios que devem ser atendidos para que uma história de usuário esteja pronta para a criação. Assim que a sua história de usuário estiver pronta de acordo com a DoR, é possível marcá-la como qualificada para o planejamento do sprint.

Normalmente, a DoR é uma lista de verificação de critérios. Os critérios definem o conteúdo que deve estar presente na história, o processo de revisão ou as aprovações que devem ter ocorrido, além dos artefatos que precisam ser coletados ou anexados. A planilha abaixo mostra uma história de usuário com 12 critérios de exemplo a serem atendidos.

Uma DoR predefinida assegura que todos os membros da equipe tenham clareza sobre os requisitos mínimos de uma história de usuário. Ela confirma que as histórias de usuário colocadas em um sprint passaram por uma verificação de qualidade e podem ser entregues dentro do sprint.

O objetivo de refinar uma história de usuário é assegurar que sua equipe tenha um entendimento completo da intenção e do escopo. O refinamento da história é um processo sucessivo que amadurece o conteúdo da história para atender à definição de pronto. A abordagem de entrega do Pega Express^™ promove a captura direta de objetivos (DCO) para assegurar a colaboração com todos os stakeholders relevantes. A DCO é utilizada em todo o processo de refinamento para assegurar que cada história de usuário tenha todas as informações, de todos os pontos de vista. 

O refinamento da história de usuário começa com um rascunho da história, que pode ser pouco mais do que uma descrição curta. O refinamento acaba com a entrega da história de usuário à equipe técnica para dimensionamento.

Rascunho de histórias de usuários

O Business Architect, o Product Owner e outros stakeholders relevantes discutem a história de usuário para que os objetivos de negócios e os requisitos do usuário fiquem claros. Uma vez feito isso, os stakeholders compartilham a história de usuário com a equipe técnica para refinamento complementar.

Refinamento

As equipes técnicas e de negócios trabalham juntas. Essa colaboração inclui o proprietário do produto (product owner), especialistas nos assuntos (subject matter experts, SMEs), especialistas em design de UX (UX design specialists), especialistas em testes, arquitetos de negócios (business architects), arquitetos de sistemas (system architects) e especialistas em TI (IT specialists). As equipes revisam a história de usuário e elucidam os detalhes. O refinamento da história de usuário pode levar várias sessões de DCO até que a equipe concorde que a história foi discutida em detalhes e documentada a contento. 

Dependendo da natureza da história de usuário, pode ser necessário adicionar artefatos como: 

• E-mails de aprovação da história de usuário
• Wireframes de IU
• Mapas de processos, regras de negócios
• Diagramas de lógica de decisão

Como parte das sessões de refinamento, a equipe técnica interpreta os critérios de aceitação e traduz os resultados em componentes que precisam ser configurados no aplicativo. A equipe técnica também identifica as dependências que a história pode ter em outras histórias de usuários e os impactos que a história pode ter em recursos existentes e áreas de complexidade específica.

A equipe técnica talvez precise considerar requisitos não funcionais, como requisitos específicos de acessibilidade do usuário. Esses requisitos podem ser perdidos se não forem documentados na história de usuário. Durante o refinamento, a equipe documenta esses detalhes na história de usuário por meio de anexos complementares ou critérios de aceitação específicos. 

Ao refinar a história de usuário, é possível perceber que ela é grande ou complexa demais. Nesse caso, divida-a em mais de uma história de usuário.  Também é possível que seu trabalho durante o refinamento exponha uma lacuna nos requisitos e gere a necessidade de adicionar histórias de usuário complementares ao seu backlog.

Quando as histórias estiverem refinadas

O processo de refinamento termina quando:

• A equipe concorda no entendimento da história de usuário
• Todas as informações de apoio complementares são adicionadas à história de usuário
• O Product Owner aprova os critérios de aceitação  

Após estar refinada, a equipe técnica está em condições de dimensionar a história de usuário. O dimensionamento da história encerra o refinamento.

Durante o processo de refinamento, a equipe técnica identifica tarefas técnicas a serem concluídas que atendem aos critérios de aceitação de uma história de usuário. Algumas configurações técnicas merecem atenção especial. A equipe pode separar essas tarefas do esforço de configuração. Para facilitar a alocação de trabalho no Scrum e assegurar que os componentes reutilizáveis sejam construídos com os critérios de aceitação apropriados, a equipe do scrum pode criar uma história técnica somente com elementos técnicos.

Exemplos típicos de histórias técnicas:

• A configuração dos conectores de interface
• Testes automatizados
• Um repositório de DevOps
• Novos ambientes
• Outros elementos técnicos necessários para oferecer suporte a várias histórias de usuários

Durante o refinamento, a história técnica é listada como uma dependência para as histórias de usuário que exigem esses componentes técnicos genéricos. As histórias técnicas permitem que os membros da equipe trabalhem em paralelo para entregar histórias de usuários relacionadas no mesmo sprint. A equipe também separa o trabalho da criação de ativos técnicos da criação de soluções de negócios.

As histórias técnicas estão sujeitas às mesmas regras que as histórias de usuário na medida em que:

• Devem atender à definição de pronto para serem alocadas em um sprint
• São dimensionadas da mesma forma que as histórias de usuário não técnicas

Existem várias maneiras de refletir o tamanho de uma história. A pontuação das histórias (atribuir pontos a cada história) é uma atividade realizada no final da discussão de refinamento. O objetivo da atividade é dimensionar a complexidade da história. Quanto maior o número, maior é a complexidade da história e maior é o esforço para configurar, testar e implementar a história. Uma abordagem comum é utilizar a sequência numérica de Fibonacci. Essa sequência permite que a equipe classifique as histórias em termos de complexidade relativa.

A seguinte escala de Fibonacci determina os pontos da história:

• 1 ponto de história = história muito pequena
• 2 pontos de história = pequena
• 3 pontos de história = média
• 5 pontos de história = média a grande
• 8 pontos de história = grande
• 13 pontos de história = história muito grande
• mais de 21 pontos de história = a história precisa ser considerada um ÉPICO e dividida em partes menores.

Estimativa com grupos de complexidade

Alcançar uma avaliação consistente da complexidade da história pode ser um desafio, pois cada membro da equipe pode ver a complexidade de maneira diferente. É possível estimar a complexidade da história utilizando os grupos de complexidade para dar à sua equipe uma maneira de dimensionar histórias de forma consistente, discutindo cada história em grupos predefinidos de complexidade antes de escolher os pontos finais.   

Durante a fase Preparação (Prepare), a equipe deve concordar com os critérios mais apropriados para avaliar a complexidade da história. Cada critério se torna um grupo de complexidade. Dentro de cada grupo, a equipe deve concordar com uma classificação de complexidade de Leve, Médio e Alto ou Complexo. Por exemplo, os desenvolvedores devem considerar as implicações da história de usuário na interface do usuário, a quantidade de testes, configuração, número de regras de negócio e integrações de dados à medida que decidem sobre o número do dimensionamento. Para cada nível de complexidade, você atribui um valor em pontos. 

Os grupos de complexidade habituais podem incluir:

• Interface de usuário
• Lógica de negócio 
• Dados
• Aspectos de integração
• Testes   

Durante a sessão de dimensionamento, a equipe analisa cada história em relação a todos os critérios e calcula o total de pontos da história, tendo como base a classificação de complexidade de cada categoria. Em seguida, o valor total é combinado com o número de Fibonacci apropriado. Se os números não corresponderem exatamente e ficarem entre os números de Fibonacci, a equipe deve concordar qual dos números de Fibonacci em cada lado do total representa melhor a complexidade e atribuir esse valor à história.

Após a estimativa, a história de usuário está pronta para ser considerada pelo Project Owner na próxima sessão de planejamento do sprint. 

Uma das perguntas mais comuns em um projeto Ágil é: "O que é uma boa história de usuário?" Não existe um modelo único de história de usuário; o modelo varia conforme a equipe. Diversas experiências e contextos do setor influenciam os requisitos coletivos da história de usuário.

O exemplo abaixo mostra uma boa história já totalmente elaborada, refinada com a equipe técnica, analisada em relação à definição de pronto e declarada como pronta para a criação. No exemplo, procure os seguintes elementos:

• Nome da história
• Descrição 
• Critérios de aceitação
• Tamanho da história  
• Status da história
• Outras informações 

Verifique seus conhecimentos com a interação a seguir.