INVEST User Story

Em metodologias ágeis, pensamos em requisitos na forma de estórias do usuário. É fácil confundir o cartão de estória com a “estória toda”. Estórias em Extreme Programming têm três componentes: Cartões (seu meio físico), a conversa (a discussão em torno deles) e Confirmação (testes que verificam eles). Existe um língua chamada Pidgin, que é uma linguagem simplificada, geralmente usada para o comércio, que permite que as pessoas que não podem se comunicar em seu idioma nativo possam trabalhar juntos. Estórias de usuário funciona assim. Não é esperado que os clientes ou usuários visualizam o sistema da mesma forma que os programadores; estórias agem como uma língua pidgin onde ambos os lados podem concordar suficiente para trabalhar em conjunto de forma eficaz.

É essencial para o projeto a concepção de boas estórias, que capturam o valor do negócio solicitado pelo Product Owner. INVEST é uma abordagem amplamente utilizada para escrever estórias. Ao criar estórias, é muito importante fazer estórias de acordo com a abordagem INVEST. O acrônimo INVEST: I (Independent) – N (Negotiable) – V (Valuable) – E (Estimable) – S (Small) – T (Testable). Esse acrônimo ajuda a lembrar de um conjunto de critérios, ou lista de verificação, para avaliar a qualidade de uma estória de usuário. Se a estória não cumprir um destes critérios, a equipe deve reformular, ou mesmo considerar uma reescrita, que se traduz no ato físico de rasgar o cartão (post-it) da velha estória e escrever um novo. Abaixo estão os resumos respectivo a cada sigla.

Independent	Estórias devem ser independentes uma das outras sempre que possível, é dificilmente não será possível. Em outras palavras, as estórias podem ser trabalhadas em qualquer ordem. Por que isso é importante? Ela permite a priorização individual de cada estória e um product backlog como um todo. Quando um product backlog tem suas estórias dependentes, poderá não ser possível implementar uma estória valiosa sem implementar outras histórias muito menos valiosas, comprometendo o tamanho ou objetivo da sprint.
Negotiable	A estória não é um contrato, mas um convite para uma conversa. A estória capta a essência do que é desejado. O resultado real precisa ser um resultado negociável de forma colaborativa entre o cliente e o time agile. O objetivo é atender às necessidades dos clientes, não desenvolver alguma coisa de uma estória qualquer que não seja o suficiente! Lembre-se, você sempre pode fazer a pergunta mágica para ajudar a conduzir a conversa.
Valuable	Se uma estória não tem valor perceptível não deve ser feita. Esperamos que as estórias sejam priorizadas de acordo com o valor do negócio, por isso ter um valor é óbvio. Algumas pessoas dizem que cada estória deve ser valiosa para o cliente ou usuário final. Na verdade isso vai além, porque o valor do negócio abrange mais do que apenas um cliente ou valor aparente ao um usuário. Inclui valor interno que é útil para coisas que são normalmente chamadas de “não-funcionais”, valor ao produto, coerência perante ao mercado ou algo similar. É melhor pensarmos que a estória tem valor para o “usuário” na estória do usuário. Desta forma, é claro que deve ser satisfeito. Finalmente, lembre-se do “para que”, cláusula presente na estória do usuário. Ele está lá por um motivo – é o valor exato que estamos tentando entregar ao completar a estória!
Estimable	Toda estória tem de ser possível estimar ou dimensionar de modo que possa ser convenientemente priorizada. Um valor elevado pode ocorrer, mas o tempo de desenvolvimento extremamente custoso não pode ser o ponto base para elevar a prioridade, só porque simplesmente o período de tempo para o seu desenvolvimento é alto. O que acontece se uma estória não pode ser estimada? Você pode dividir a estória e talvez ganhar mais clareza. Às vezes, uma estória particionada não ajuda. Se essa situação ocorrer, deve-se realizar pesquisas sobre a estória primeiro. Pausa para pesquisa e melhor entendimento! Se você não fizer isso, vai privar o produto de algo que poderia ter sido feito em algum momento adequado e oportuno.
Small	Obviamente estórias são pequenos pedaços de trabalho, mas quão pequenos deveriam ser? A resposta depende da equipe e da metodologia a ser utilizada. Recomendações agilistas é iterações quinzenais que permitem estórias de usuários de até 03 a 04 dias de trabalho, no máximo! Isto inclui todo o trabalho envolvido para começar a estória e passar para um status de “Pronto”. Não seja um goldplate das estórias de usuários, você deve fazer a coisa mais simples e funcional.
Testable	Toda estória precisa ser testada. Precisamos compreender que critérios de aceitação testáveis devem ser escrito imediatamente. Pensando desta forma incentiva a colaboração, aplica-se qualidade, movendo-se no processo de controle de qualidade, e permite fácil aplicação do conceito ATDD – Desenvolvimento guiado por testes de aceitação. Como o item Negotiable ​​acima, fazendo a pergunta mágica que pode ajudar a garantir a estória do usuário de forma testável também. Estórias não-funcionais também devem ser testadas. Exemplo: “O sistema deverá estar 99% do tempo no ar”, de forma chula para exemplificar, tire o cabo de energia de um dos servidores e veja se tudo continua funcionando.

Se os product owners e suas equipes trabalharem em conjunto para investir em boas estórias com um product backlog coerente e eficaz, a curva de aprendizado do trabalho em conjunto será muito mais curto. O acrônimo INVEST estimula bons hábitos que eliminam alguns dos maiores problemas de estórias do usuário, como dependências, conteúdo muito grande, dificuldade de teste e etc. Aproveite o tempo para investir em boas estórias e ver a mudança dramática de como o planejamento se tornará eficaz, assim como como produtivo o time também irá se tornar.