Agile INVEST – 6 Grandes Diretrizes para Histórias de Usuários

Ágilusa histórias de usuários para expressar os problemas que um produto ou sistema deveria resolver. A diretriz Agile INVEST é um conjunto de recomendações compiladas por Bill Wake para ajudar a testar e criar histórias de usuários de alta qualidade (ou, mais geralmente, Itens de Backlog do Produto) que suportam a gestão ágil eficazgestão ágil de projetos.

De acordo com aAgile INVESTdiretriz, histórias de usuários de alta qualidade são fáceis de:

• Entender
• Implementar
• Testar
• Demonstrar ao cliente
• Ser independente

Mas vamos analisar o que o acrônimo INVEST realmente significa.

Agile INVEST – Independente

Isso significa que a história pode existir como um Item de Backlog do Produto (PBI) com sua própria prioridade, ser estimada de forma independente e não depender de outras histórias.

A prioridade atribuída a uma história de usuário deve ser o único fator que determina quando a equipe a implementa. Se sua prioridade for menor, a história fica mais baixa no backlog e é implementada posteriormente; se for maior, a equipe a move para cima no backlog para entrega mais rápida. Quando as histórias de usuário são interdependentes, a dependência — e não a prioridade — determina quando a equipe as implementa.

Agile INVEST – Negociável

Uma boa história de usuário captura a essência da necessidade do cliente. Se houver dúvidas, a equipe discute com o cliente para determinar o valor correto da história. A equipe de desenvolvimento pode negociar com o Product Owner e os interessados. Dessa forma, a colaboração entre a equipe do projeto (fornecedor e cliente) cria um produto ou serviço excepcional.

Uma equipe ágil não tem nada para perguntar porque tudo está documentado na história de usuário ágil? Então, um analista de negócios escreveu os requisitos.

Haverá alguns itens não negociáveis (muitas vezes não funcionais), como:

• Políticas de segurança relacionadas às contas de usuário
• Requisitos de desempenho, como o número de usuários simultâneos que o sistema deve suportar

Isso está bem — desde que os detalhes da funcionalidade em si permaneçam abertos e convidem à conversa.

Agile INVEST – Valioso

Referindo-se aos princípios ágeis, “valioso” significa que podemos demonstrar ao cliente o recurso ou funcionalidade solicitada durante a reunião de revisão do Sprint.

Ao dividir histórias de usuários, as equipes devem dividir verticalmente (também representando a letra “V”) em vez de horizontalmente. Isso entrega funcionalidade completa ao final do Sprint e aumenta o incremento potencialmente entregável do produto.

As equipes podem achar mais interessante implementar PBIs técnicos, mas eles nem sempre entregam valor direto ao cliente — o que contradiz um dosprincípios ágeis: satisfazer o cliente por meio da entrega precoce e contínua de software valioso.

Agile INVEST – Estimável

Uma boa história de usuário deve ser estimável. No ágil, a estimativa é relativa — comparada às outras histórias de usuário na lista de prioridades. Métodos populares incluem a sequência de Fibonacci, Tamanho de camiseta (P, M, G, etc.), e mais.

A discussão em torno da estimativa ajuda toda a equipe a alcançar consenso sobre as condições necessárias para concluir a história. Às vezes, uma história não é estimável, o que é normal se a história for muito grande ou contiver múltiplas funcionalidades no mesmo item. Nesses casos, divida a história em múltiplas histórias menores. Em outras situações, há muitas incertezas que exigem pesquisa.

Agile INVEST – Pequeno

As histórias devem levar de algumas horas até um máximo de um período completo de Sprint. Caso contrário, surgem diferentes problemas — como velocidade (como a equipe se responsabiliza pelos pontos de entrega), dificuldade em estimativas precisas, entre outros.

Agile INVEST – Testável

Neste contexto, ‘testável’ refere-se aos critérios de aceitação definidos durante a análise.

Não podemos considerar uma história de usuário como ‘Concluída’ a menos que atenda aos critérios de aceitação. A única maneira de sabermos que eles foram atendidos é por meio de testes e verificação.

Os critérios de aceitação não são casos de teste. Eles respondem à pergunta: ‘Como sei quando terminei esta história de usuário?’

Os casos de teste descrevem os passos necessários para testar a funcionalidade.

O cliente pode informar como é o ambiente de teste e as condições de teste sob as quais a equipe considera que uma história de usuário está CONCLUÍDA.