Como quebrar user stories
Com a adoção cada vez maior de metodologias ágeis por parte das empresas, em especial o SCRUM, surgem novas questões decorrentes da implementação desses frameworks, que tem na figura do PO, ou product owner, um dos seus mais importantes papéis.
O product owner é responsável por definir junto aos usuários e ao time os itens do product backlog. As demandas do backlog, por sua vez, tem seus requisitos detalhados através de histórias de usuário.
As histórias de usuário, ou user stories, são um conceito herdado do XP, ou Extreme Programming, e são praticamente o padrão para descrição de requisitos nos frameworks ágeis.
No artigo User Stories, Mike Cohn as define como sendo “short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system”. Ou seja, é uma narrativa curta, objetiva e com foco na perspectiva do usuário que solicitou a funcionalidade.
Considerando essas características, o product owner (PO) ou product manager precisa propor para o time de desenvolvimento histórias que possibilitem a sua implementação dentro de um período pré-determinado, normalmente uma sprint. Mas o que fazer quando essa história fica muito grande e pode demorar a gerar valor para o cliente? Como fazemos para dividir essa história em pedaços menores?
Para responder a essa pergunta, vale lembrar do conceito INVEST, elaborado por Bill Wake em 2003:
· I — Independent
· N — Negotiable
· V — Valuable
·E — Estimable
·S — Small
· T — Testable
Cada item desse acrônimo representa uma característica desejável que boas histórias devem ter, mas podemos destacar algumas que podem ajudar a responder ao questionamento:
- Independent (independente): A narrativa da história deve fazer sentido por si só, sem depender de um contexto maior para ter coerência.
- Estimable (estimável): o PO deve ser capaz de determinar a sua prioridade a partir do seu tamanho, seja determinada em story points, Bcp,s, dias, etc.
- Small (pequena): a narrativa deve permitir a implementação em poucos dias, trazendo valor rapidamente.
Perceba que o valor, por mais importante que seja, é apenas um dos itens necessários para determinar a priorização de uma história. Muitas vezes esse requisito pode não trazer valor diretamente para o cliente, mas proporciona um ganho para o contexto como um todo. Issues técnicas, como APIs, collections, etc. se encaixam nessa definição, e por isso devem ser igualmente analisadas para identificar possíveis quebras visando diminuir a complexidade do desenvolvimento.
Além das etapas do acrônimo INVEST, seguem dicas extras para auxiliar na quebra das histórias:
- Se coloque sempre no lugar dos clientes A proposta de quebra da história faz sentido para o produto e para o negócio?
- Tente diminuir a complexidade da Regra de Negócio. Por exemplo, a regra de negócio de cadastro de tabelas de frete de transporte pode se tornar diversas regras menores, facilitando a estimativa, o desenvolvimento e os testes:
Como Operador de Transportes
Eu Quero Cadastrar Tabelas de Frete de Transporte
Como Operador de Transportes
Eu Quero Cadastrar Tabelas de Frete de Transporte por Região
Como Operador de Transportes
Eu Quero Cadastrar Tabelas de Frete de Transporte por Rota
Como Operador de Transportes
Eu Quero Cadastrar Tabelas de Frete de Transporte por Município
- Elabore o fluxo funcional do processo e identifique suas etapas principais. Refaça o fluxo de cada sub-processo identificado até que não consiga mais “descer” o nível de detalhamento. Identifique os pontos de maior esforço para resolução, verificando se é possível implementar a solução de forma incremental.
- Apresente sua história para o time e/ou outros product owners. Muitas vezes, uma visão isenta de vícios do processo pode ajudar a compreender minúcias não percebidas anteriormente.
- A complexidade pode estar nas interfaces com o usuário e não nas regras de negócio. Se houver um time de UX envolvido, verifique a possibilidade de apresentar uma interface gráfica simplificada e, posteriormente, apresente as demais funcionalidades.
- Requisitos não-funcionais como regras de segurança de acesso, mensagens de aviso, logs, etc. normalmente são negociáveis com os usuários para que possam ser implementadas futuramente, principalmente se o produto for utilizado de forma controlada e/ou restrita.
- O mesmo se aplica para regras de exceção ou tratativas de fluxos alternativos, como cancelamento, estorno, etc. Verifique se há outras formas de atender ao requisito, minimizando o impacto da sua ausência, ou negocie a sua implementação em um segundo momento.
- Explore soluções alternativas.
- Se possível (e for rápido) execute uma PoC para validar a história quebrada, confirmando assim se está seguindo o caminho correto.
Por fim, perceba que invariavelmente a quebra das histórias acabará gerando um aumento do backlog, o que pode causar algum mal estar junto aos usuários. Por isso é importante deixar claro os benefícios e os objetivos que se pretende atingir com esse fatiamento, garantindo assim apoio para que a sua proposta tenha sucesso.
Seguir as sugestões acima o ajudará a atingir esses objetivos e adquirir bons hábitos na hora de escrever histórias e definir o product backlog, o que proporcionará aumento de produtividade do time a satisfação do seu cliente final.
- -
Autor
Denis Gonzaga da Silva — Coordenador de Produtos de Tecnologia
