Porque e como — mapear e refinar seu backlog
Compartilho aqui algumas práticas que temos aplicado no time, bem como algumas referências de leitura, livros e estudos que tenho feito.
Por que Mapear e Refinar?
A qualidade de software começa na especificação.
Além de transmitir O QUE deve ser feito, queremos deixar claro o POR QUE fazer. Todos os envolvidos no projeto merecem ter essa visão. O contexto é importantíssimo para o desenvolvimento do produto. Identificar oportunidades de melhoria e antecipação de problemas podem surgir durante o mapeamento e refinamento do backlog.
Pense também no cenário de revisitar seu backlog alguns meses à frente. Você, ou qualquer pessoa deve ser capaz de responder: Por que isso foi feito? O que foi feito?
Artefatos de um backlog
Aqui podemos ter várias configurações diferentes, mas escrevo aqui o formato que temos usado atualmente.
- Epic: Um marco ou um objetivo do negócio.
- Feature: Entregável de software ou funcionalidade que apoia um epic
- User Story (ou Product Backlog Item): Itens menores ou passos de uma Feature
Independente da forma ou dos termos que podemos usar, o intuito aqui é deixar um exemplo de quebra do nosso backlog.
Mas por que não ter um Backlog “Flat”?
Quebrar o backlog em níveis menores (epic, feature, user stories ou qualquer que seja a quebra):
- Facilita a visualizar pela ótica do usuário.
- Nos ajudam a ver o quadro todo.
- Nos ajudam a priorizar. Qual feature entrega mais valor ao usuário agora?
Mapping (Mapeamento)
Foque no problema antes de pensar na solução
No Livro Product Backlog Building do Fábio Aguiar e Paulo Caroli, eles trazem uma reflexão interessante de que devemos pensar como um médico e não como um garçom.
A primeira coisa que um garçom faz é oferecer um cardápio e não questiona o pedido que é feito. Já um médico, ouve o paciente, conversa com ele, pede exames, para só depois pensar em um tratamento ou remédios para solução do problema.
Qual o ponto?
Antes de pensarmos em como vamos resolver o problema, sem nos prender a uma solução, precisamos entender o contexto do usuário, quais as dores dele, que valor iremos entregar.
Isso pode nos levar a diversas formas possíveis de solução de um problema. As quais talvez não enxergaríamos se já começássemos com uma solução em mente.
Questionamento, comentários e ideias
Quebre a funcionalidade em passos e para cada passo abra espaço para questionamentos, comentários e ideias.
- Questionamento: pode eliminar um passo desnecessário
- Comentário: pode melhorar um passo útil
- Idéia: pode fazer nascer um passo novo
Escreva em cartões de cores diferentes para questionamentos, comentários e ideias. Facilita a identificação
Refining (Refinamento)
Por que refinar?
Com base nos passos, entre em detalhes e responda as perguntas abaixo:
PARA QUEM está sendo desenvolvido? Queremos ter claro quem irá realizar aquele passo ou etapa. Ao invés de “um usuário”, queremos saber exatamente quem é esse usuário. Dependendo de quem é o ator, temos um tipo específico de necessidade, um contexto e uma “dor” diferente.
POR QUE está sendo desenvolvido? Novamente o contexto e a necessidade do ator precisam estar claros. Por que a Persona se importa? Qual problema existe atualmente que precisa ser resolvido?
O QUE precisa ser desenvolvido? Aqui podemos entrar nos detalhes de implementação. Mas se lembre que equilíbrio é a palavra aqui. Não queremos sobrecarregar de detalhes a ponto de termos uma documentação extensa e que possa se tornar obsoleto ou não faça sentido após algum tempo. Antes, podemos colocar detalhes técnicos, visuais ou qualquer coisa que apoie no desenvolvimento, mas foque no que é essencial.
COMO pode ser validado? Deixe claro como podemos saber que essa etapa obteve sucesso e entregou valor ao usuário. Qual a expectativa dele ou dela ao fim dessa etapa?
Como escrever?
Existem vários formatos possíveis, mas aqui listo 3 dos quais temos utilizado:
ARO — Action, Result, Object
Exemplo:
Action: Calcular Total
Result: Total
Object: de vendas por mês
User Story
Eu, como… | Aqui, evite usar a persona de uma maneira muito abrangente. Qual o papel daquela persona? O que ela faz?
Quero… | Evite suposições não validadas. O que ela realmente espera nessa etapa ou momento?
Para que eu possa… | O retorno que a persona espera. O que o usuário está tentando fazer? Não utilize aqui a funcionalidade — por exemplo, se a funcionalidade é “listar a tabela de clientes”, não coloque como “Para que eu possa… ver a tabela de clientes”. Qual a expectativa do usuário em ver a tabela de clientes? Por que ele/ela quer ver a tabela de clientes? Um exemplo de motivação nesse caso poderia ser: “quero visualizar o telefone do cliente para efetuar uma venda”. Esses tipos de detalhes podem nos contextualizar do que a persona realmente está realizando naquele momento e porque aquilo gera valor a ela.
Exemplo:
Eu como gerente de estoque do supermercado
Quero visualizar o número de produtos no estoque
Para que eu possa fazer um novo pedido se necessário
Job Story
A job story foca no trabalho (job) que o usuário está realizando ao invés de quem é o usuário. Ao invés de assumir de que dependendo de quem é o usuário o contexto dela será diferente.
Quando estou… | Qual a situação/contexto do usuário?
Quero… | Qual o retorno que a persona espera? O que o usuário está tentando fazer?
Para que eu possa… |Qual objetivo final da persona?
Exemplo:
Quando estou realizando os pedidos aos fornecedores
Quero visualizar o número de produtos no estoque
Para que eu possa fazer um novo pedido se necessário
User Story x Job Story
Refinamento Contínuo
No livro do PBB, o trabalho de refinamento é comparado a fazer uma trilha - e não um trilho. O trilho é algo fixo, o trem segue o caminho até o fim. Já na trilha, conforme caminhamos, vamos verificando se precisamos ajustar nosso caminho, verificamos o plano, caminhamos mais um pouco e esse ciclo se repete mais a frente.
Os itens do backlog são documentos vivos. Devem ser constantemente revisitados e refletem o progresso do entendimento do time.
Como medir a qualidade?
- Definition of Ready — A definição de preparado deve ser atendida
- Definition of Done — A definição de pronto estabelecida pelo time deve estar clara e ser possível de atender pelo item
- INVEST
Independente: uma história não deve depender de outra história
Negociável: não é um contrato fechado.
Valiosa: deve entregar valor ao usuário
Estimável: fornece informações suficientes para estimada em alto nível
Sob medida: Deve caber em uma iteração
Testável: deve ser clara o suficiente para que testes sejam criados
- BDD — Behavior Driven Development
Given (Dado) — Contexto
When (Quando) — Uma ação é realizada
Then (Então) — Um resultado é obtido
Exemplo:
Dado gerente de estoque logado no sistema
Quando consulta os últimos pedidos realizados
Então visualiza os pedidos realizados nos últimos 30 dias
Conclusão
Os melhores documentos em métodos ágeis ajudam a recordar nossas conversas, e não a substitui-las.
Livro Product Backlog Building.
Como já dito, mais do que seguir um formato, nossa documentação deve ser viva, pertinente e que ajude a todo o time ter uma visão do problema atual do usuário e porque e como procuramos entregar valor a ele.
Referências
The New User Story Backlog is a Map
Livro: Histórias de Usuário — Rafael Helm e Daniel Wildt — [eBook] Histórias de Usuário: Por que e como escrever requisitos de forma ágil? — Wildtech Cursos e Consultoria
