Prontidão da história de usuário

Uma história de usuário (user story) descreve como um usuário final utiliza um aplicativo para alcançar um resultado específico. É uma forma humana de documentar um requisito de negócios em um formato simples e conciso. Uma história de usuário representa a menor unidade de trabalho a ser desenvolvida no aplicativo.  

O objetivo primário das histórias de usuário como artefatos do projeto é ajudar a equipe de desenvolvimento a acompanhar (dentro do backlog do projeto) todos os recursos que precisam construir e implementar para o cliente. As histórias de usuários descrevem o que é necessário para que os recursos possam ser projetados de forma a satisfazer o Proprietário do Produto e, em última análise, o usuário de negócio final. Uma equipe cria uma história de usuário com o conhecimento e a experiência coletiva da equipe. 

Os principais recursos de uma história de usuário:

• Centrado nos seres humanos
• Fácil de entender
• Reflete o valor de negócio que o cliente recebe de maneira clara
• Pode ser testada

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 desejo… [O quê? - Insira o que ele deseja fazer]   
• para que… [Por quê? – Insira o valor de negócio]

A preparação e as discussões por trás das histórias de usuários são extremamente importantes.  Só é possível obter esse entendimento coletivo por meio do diálogo.Resista à tentação de traduzir 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. Você também verá que a descrição é curta.

Os critérios de aceitação (acceptance criteria) 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 proprietário do produto 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 que sejam 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:

• Dado...{pré-condição}: Exemplo: "Quando um membro premium se inscreve..."
• Quando...{algo é feito}. Exemplo: "eles são inscritos automaticamente nas promoções seguintes..."
• Então…{resultado esperado} Exemplo: “...e eles recebem um e-mail”

No início do projeto, sua equipe define o que se entende por definição de pronto (Definition of Ready, DoR). A equipe concorda com a DoR durante a fase Preparação (Prepare) para definir a linha de base 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 antes que uma história de usuário esteja pronta para ser criada. 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 com sucesso 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 pelo DCO para assegurar a colaboração com todos os stakeholders relevantes. O DCO é utilizado em todo o processo de refinamento para assegurar que cada história de usuário tenha todas as informações incluídas nele, de todos os pontos de vista. 

O refinamento da história de usuário começa com um rascunho da história, que pode incluir 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 arquiteto de negócios, o proprietário do produto 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 de forma apropriada. 

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 funcionalidades 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.  Como alternativa, seu trabalho durante o refinamento pode expor uma lacuna nos requisitos e gerar 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 proprietário do produto 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.

Como parte do 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 decidir criar uma história técnica que inclua apenas elementos técnicos.  

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

• 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 esforço associado à 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 proprietário do projeto na próxima sessão de planejamento do sprint. 

Uma das perguntas mais comuns em um projeto Agile é: "Como é uma boa história de usuário?" Não existe um modelo único para todos os modelos de uma história de usuário; o modelo é diferente para cada equipe. Diversas experiências e contextos do setor influenciam os requisitos coletivos da história de usuário.   

O exemplo abaixo reflete como seria uma boa história após ela ser totalmente elaborada, refinada com a equipe técnica, analisada em relação à definição de conclusão e declarada como pronta para criar. 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
• Informações complementares 

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