Especificação de requisitos em projetos ágeis além da User Story

Com o objetivo de melhorar as especificações, tentando encontrar maneiras que facilitassem a vida do Product Owner e/ou do Business Analyst para refinar e apresentar ao time de delivery requisitos mais claros e com valor, encontrei, compilei e adequei alguns conceitos e materiais, que espero que possam ajudar você, tanto quanto está me ajudando.

Falando em Métodos Ágeis, sempre que pensamos em especificação de requisitos e backlog, a primeira palavra que vem em mente é User Story (US). Mas talvez não seja a única opção, e podemos usar outros tipos de histórias que atendam de uma melhor forma o objetivo do requisito.

Não estou falando que não devemos utilizar US, ao contrário, devemos sim, mas também podemos utilizar outros tipos de histórias que se encaixem melhor no cenário ou situação que está sendo tratada. Quantas vezes você se deparou com uma situação onde o usuário não era o foco da narrativa e ficou tão difícil encaixar no formato. Então é justamente pensando nessas situações que podemos utilizar outros tipos de histórias para compor o backlog. Não irei deixar de falar e explicar User Story, pois ela é fundamental e em projetos é a maioria, então vamos lá.

US – User Story

As US’s têm como foco o usuário, onde se tem a perspectiva do negócio, ou seja, o que deve ser ser feito e não como, sempre mostrando o objetivo que se deseja alcançar e o valor que irá ser entregue ao desenvolver a história. A User Story se encaixa perfeitamente em projetos que estão iniciando ou novos requisitos.

Se existe uma estrutura padrão? Talvez! Mas o que mais importa é conter informações fundamentais para que a US atinja um nível de excelência, que são elas:

• Para quem? A funcionalidade é destinada para quem.
• O que? O que deve ser feito, de forma resumida.
• Por que? O valor que irá entregar, o motivo de estar sendo feito.

Tendo em vista isso, sugiro a seguinte estrutura:

• SENDO <tipo de usuário>
• EU QUERO <objetivo ou ação>
• PARA <motivo e o valor/resultado>

Dica

Para ter uma US mais efetiva e completa, utilize o método INVEST.

Independent – Independente
Negotiable – Negociável
Valuable – Agregar valor
Estimable – Estimável
Small – Pequena
Testable – Testavel

IS – Improvement Story

As histórias de melhorias são uma alternativa supereficaz para quando você deseja descrever algo que deve ser melhorado em uma funcionalidade e esta é relativamente pequena e óbvia, focando na solução que deve ser implementada.

Esse tipo de história faz com que o tempo seja otimizado, pois, às vezes, colocar uma melhoria simples e óbvia em uma US acaba demandando mais tempo que o próprio desenvolvimento, devido as informações que ela exige.

A utilização de IS é indicada para produtos e/ou sistemas que estejam em produção, com uma maturidade maior, onde o MVP já foi entregue a bastante tempo.

O formato sugerido é:

• Nós temos <Situação atual>,
• Nós queremos ter <Situação futura>,
• Para que <Porque/Resultado>

Dica

Quando não se sabe se é um bug ou melhoria (situação muito comum que ocorre no time), IS’s podem ser utilizadas, pois o objetivo do time é contornar aquela situação o mais rápido possível e não ficar perdendo tempo em discussões que não agregarão valor.

JS – Job Story

As JS’s também se apresentam como alternativa as US’s, pois o foco não é o usuário, e sim, a situação que irá disparar uma ação. Isso poderá facilitar a construção da história, situações em que identificar um usuário específico se torna uma tarefa um tanto exaustiva.

O formato sugerido é:

• Quando <Situação>
• Eu quero <Motivação>
• Para que eu possa <Resultado>

Dica

Tente utilizar este formato em projetos mais curtos, com tempo e orçamento limitados, onde escrever US’s com critérios de aceitação longos demandam tanto tempo que não irá agregar valor e justificar o esforço.

TS – Technical Story

As TS’s, como o próprio nome diz, são técnicas. Elas podem causar um certo ‘desconforto’, pois perdem a questão da narrativa, por contar uma história de forma técnica, mas podem auxiliar bastante em situações que precisam de atenção e que ocupem um certo tempo do time.

Este tipo de história se encaixa muito bem para descrever spikes, requisitos técnicos e não funcionais. O objetivo é deixar de forma clara no backlog que o time está trabalhando e que irá ocupar tempo dentro da sprint, mas que não irá ter um entregável para o cliente ao final.

As histórias técnicas não estarão sozinhas no backlog, ou seja, elas são filhas de uma história de negócio, podendo ser de uma US ou de uma IS. Sendo assim, ela sempre será priorizada a frente da história mãe e quando for concluída, a história que a originou entrará no próximo ciclo obrigatoriamente, pois o time terá subsídios suficientes para que ela possa ser desenvolvida.

O formato sugerido é:

• A fim de OU Para <Atingir um objetivo>,
• <Um sistema ou persona> precisa < ‘Fazer’ alguma ação>
• Resultado esperado: <Relatório da investigação> OU <Lista de ações que serão incorporadas no backlog>

Dica

Sempre traga a Technical Story em uma sprint e a User Story ou Improvement Story original para a sprint subsequente, assim você irá remover os impedimentos que a necessidade pedida pelo negócio seja feita e entregue.

Critérios de Aceitação

Em todos os tipos de histórias não podemos esquecer dos critérios de aceitação, que são parte fundamental. Para isso sugiro dois métodos, que poderão ser aplicados dependendo do caso e da complexidade.

1 – BDD (Behavior Driven Development – de Dan North)

• Dado que (indica o cenário atual, o pré-requisito)
• Quando (qual ação deve ser feita)
• Então (o resultado esperado)

Indicado para cenários complexos e também quando precisamos de uma especificação mais completa, ajudando e orientando o time de desenvolvimento na construção dos testes.

2 – Checklist

Para implementações simples e pequenas, onde o projeto tem seu tempo e orçamento limitados, os critérios de aceitação podem ser mais objetivos, assim uma lista de resultados esperados pode ser bastante eficaz, desta forma a qualidade não é deixada de lado.

Uma alteração simples na estrutura da história e você perceberá que não irá afetar em nada o valor que ela irá entregar, ao contrário poderá ajudar a compreender e facilitar tanto a vida de quem descreve, quanto a de quem irá implementar a solução. Além de contribuir para um backlog mais transparente, podendo segmentar e priorizar as atividades de uma forma mais efetiva.

Nunca esqueça que entregar valor deve ser o seu maior e principal objetivo!

Créditos e Referências

5 Maneiras de Descrever Requisitos de Software (Leandro Bodo)
Histórias de Usuário (Rafael Helm e Daniel Wildt)
Análise e Gestão de Requisitos de Software (Felipe Machado)