Ao concebermos um novo produto, ou ao pensarmos em um problema a ser resolvido, nos deparamos com diferentes níveis de conhecimento sobre os diversos aspectos a serem abordados. Certamente, algumas características que desejamos para o produto conhecemos bem e conseguimos detalhar. Outras, temos somente uma ideia, uma visão de alto nível do que queremos. Além disso, não faz muito sentido definirmos um produto com uma enorme quantidade de histórias, ou Itens de Backlog (PBI – Product Backlog Item). Fica confuso e difícil de explicar para qualquer um. Assim, é natural que inicialmente populemos o nosso Product Backlog com itens de mais alto nível, que posteriormente serão detalhados/refinados, para permitir o trabalho do time na Sprint.

Costumamos chamar esses itens de alto nível de Épicos. São histórias que dão uma visão geral do pretendido, mas que ainda são muito grandes, no sentido de demandarem muito tempo para sua realização, e contam com poucos detalhes, não possuindo toda a informação necessária para que o time as realize. Um exemplo simples de uma história assim seria O Diretor quer controlar o estoque para otimizar o uso dos recursos financeiros. Essa história é de fácil compreensão ao apresentarmos o novo produto, no entanto demandará muito mais que uma Sprint para ser completada e não possui detalhes suficientes para ser implementada pelo time.

Os épicos precisam ser detalhados com o propósito de permitir o trabalho do time. De uma forma geral, não há a preocupação em trabalharmos como na análise estruturada, guardando o épico e explodindo sucessivamente seus subprodutos. O que fazemos na prática é dividir o épico em histórias menores que cubram todo o desejado no épico, podendo após isso descartá-lo.

Surge então a dúvida mais do que normal: Qual o nível de detalhamento ideal? Que granularidade buscamos? Para responder a isso lançamos mão de um acrônimo proposto por William Wake, INVEST – Independent, Negotiable, Valuable, Estimable, Small e Testable. Vamos olhar sucintamente cada uma dessas características.

Independente

O ideal é que possamos trabalhar em uma história independente das demais. Assim, podemos trabalhar nela a qualquer momento, sem depender de outras. Nem sempre isso é possível, mas deve ser buscado. Ou seja, procuramos minimizar as dependências.

Negociável

Uma história deve poder ser trabalhada em conjunto, pelo cliente e pela equipe. Assim, o conceito deve ser bem definido e os detalhes são resolvidos posteriormente em conjunto. A essência deve ser capturada, deixando os detalhes como parte da implementação.

Valiosa

Uma história tem que prover valor para o cliente. Ao dividir histórias devemos nos preocupar em manter a visão total de sua implementação, de forma que o cliente perceba o seu valor e suporte o desenvolvimento da história. Temos histórias chamadas “técnicas” aonde o cliente tem muitas vezes dificuldade para enxergar valor, mas falaremos sobre isso em outra oportunidade. De uma forma geral, devemos evitá-las, procurando inseri-las como partes de outras histórias onde o cliente perceba valor. Nem sempre isso é possível.

Estimável

Para que o time possa programar o seu trabalho e o cliente possa priorizar a realização das histórias, elas precisam ser estimadas. Quanto maior a história mais impreciso e difícil é estimar.

Pequena

Histórias devem ser pequenas. Devem poder ser feitas com poucos homem-hora, alguns dias de trabalho somente. Adicionalmente, pequenas são estimadas mais facilmente e com maior precisão.

Testáveis

Tudo o que é feito pelo time deve poder ser verificado e validado. Um bom exercício é definir o teste antes de trabalhar na história. Se há dificuldade em definir testes, a história pode não ter sido bem entendida ou estar no nível de abstração incorreto.

É fundamental para todos da equipe Scrum entender que o trabalho é realizado por histórias e, portanto, a qualidade das mesmas definirá a eficácia e a eficiência da equipe. Ainda, o trabalho na definição das histórias, as necessárias discussões e levantamentos, e outras atividades correlatas, servem para a aquisição de conhecimento pelo time, e até pelo próprio cliente.

Voltando ao nosso simples exemplo inicial, poderíamos substituir nosso épico O Diretor quer controlar o estoque para otimizar o uso dos recursos financeiros  por:

  • Diretor deseja registrar a entrada de mercadorias para permitir as vendas e limitar o uso do almoxarifado
  • Vendedor precisa registrar a saída de mercadorias para permitir a reposição do estoque
  • Controlador deseja verificar e ajustar a quantidade de mercadoria existente para efetuar o balanço de material

Histórias menores, que cobrem a necessidade inicial apresentada no épico, e permitem e orientam o trabalho do time. Com histórias assim, atendendo ao INVEST, será mais fácil estimarmos.

No ScrumHalf você pode classificar histórias como Épico. Você consegue dividir suas histórias dessa maneira? Qual a sua maior dificuldade? Conte para a gente. Quem sabe não pensamos em algo juntos…

Nos próximos posts da série falaremos mais sobre estimativas, características/tipos de histórias, e outros assuntos mais avançados. Continue nos acompanhando. Até breve e bom Scrum!