A divisão de Épicos

Um Scrum Trainer me perguntou recentemente sobre alguns bons exemplos de como dividir User Stories grandes (Epics) em Stories menores. Gostaria de compartilhar esses exemplos com você.

Epic 1: Encontrar a campanha de marketing certa

O primeiro exemplo é de uma empresa que vende software para grandes redes de varejo (WalMart etc.). O diretor de marketing precisava decidir como investir o orçamento de publicidade. Por isso, a User Story (Epic) foi escrita da perspectiva dele. Seu primeiro grande objetivo era:

Como diretor do departamento de marketing, quero poder visualizar as campanhas publicitárias anteriores para identificar e repetir campanhas lucrativas.

Os membros da equipe disseram que isso era claramente um Epic. Então pedi que criassem várias histórias menores a partir disso:
1a: Como diretor do departamento de marketing, quero poder selecionar um período de tempo do qual as campanhas publicitárias a serem analisadas devem vir, para que…
2a: Como diretor do departamento de marketing, quero poder escolher quais campanhas (mala direta, TV, e-mail, rádio etc.) devem ser incluídas na análise, para que….

(Observe que numerei as stories de forma que seja possível identificar de qual story original elas derivam. Em um projeto real, eu não faria isso necessariamente – a não ser que tivesse uma ferramenta onde isso acontecesse automaticamente.)

Eu não sabia exatamente qual era o tamanho dessas duas stories e se deveriam ser divididas novamente. Então perguntei ao time: "Se vocês tivessem que estimar essas stories, qual unidade viria primeiro à mente? Horas, dias, semanas, meses ou anos?" Para a 1a foram dias, então a story ficou como estava. Para a 1b foram semanas e por isso dividimos a story novamente:

• 1b1: Como diretor do departamento de marketing, quero poder visualizar informações sobre mala direta de campanhas anteriores, para que…

• 1b2: Como diretor do departamento de marketing, quero poder visualizar informações sobre publicidade em TV de campanhas anteriores, para que…

• 1b3: Como diretor do departamento de marketing, quero poder visualizar informações de campanhas anteriores com publicidade por e-mail, para que…

• etc.

Cada uma dessas histórias tinha um bom tamanho ("estimaríamos essa história em dias"). No entanto, ainda precisavam de certas informações – as chamadas "Conditions of Satisfaction", que são basicamente testes de aceitação de alto nível. Para 1b2, os membros da equipe escreveram o seguinte no verso do cartão:

• Quantos espectadores de cada faixa etária havia?

• Quantos espectadores de cada faixa de renda havia?

Exemplo 2: Maximização de receita de um hotel

Neste exemplo, trata-se de um hotel onde a receita deveria ser maximizada, ou seja, o operador queria encontrar o preço mais alto possível para os quartos do hotel. Os preços foram calculados com base em alguns fatores. Por exemplo, preços de quartos de hotéis comparáveis, a época do ano, grandes eventos nas proximidades (quando o Super Bowl ou uma Copa do Mundo é realizada em uma cidade, os preços sobem) etc.

Esta era a User Story original (Epic):

1: Como hoteleiro, quero encontrar o preço ideal para os quartos do meu hotel.
Para simplificar, vamos assumir que o hotel tem apenas uma categoria de quartos. Como já mencionado, muitos fatores podem influenciar o preço de um quarto de hotel. A fórmula básica para calcular o preço do quarto é a seguinte:

Preço do quarto = f (a,b,c…)

Esta função depende de vários fatores. Para cada um deles existe uma Story:
1a: Como hoteleiro, quero definir o preço ideal para os quartos do meu hotel com base nos preços do ano passado.
1b: Como hoteleiro, quero definir o preço ideal para os quartos do meu hotel com base nos preços de hotéis comparáveis.

A Story 1a diz apenas que os preços do ano anterior são considerados na função. A Story 1b diz que os preços que outros hotéis cobram também são incluídos no cálculo.

Cada uma das Stories era relativamente grande (um Epic) e naturalmente havia mais do que as duas Stories mencionadas acima. Por isso, seria impossível colocar todas em um único Sprint. As Stories foram implementadas gradualmente e assim a fórmula mencionada resultou em um preço incorreto, pois foi construída da seguinte forma:

Preço do quarto = f (a)

depois

Preço do quarto = f (a,b)

depois

Preço do quarto = f (a,b,c)

etc.

Após o primeiro Sprint, o cálculo seria Preço do quarto = f (a) e você obteria um preço incorreto (que não pode ser repassado ao cliente). O cálculo em si é basicamente correto. Talvez os valores para (b) e (c) estejam codificados de forma fixa ou sejam simplesmente ignorados. Mas desta forma, algoritmos complexos podem ser construídos incrementalmente.

Como a Story 1b ainda era muito grande, ela foi subdividida novamente:

• 1b1: Como hoteleiro, posso definir um certo número de hotéis comparáveis. (Para isso, o termo "Comparable Set" foi usado nesta empresa.)
• 1b2: Como hoteleiro, posso adicionar hotéis ao Comparable Set.
• 1b3: Como hoteleiro, posso remover hotéis do Comparable Set.
• 1b4: Como hoteleiro, posso excluir um Comparable Set completo que não preciso mais.
• 1b5: Como hoteleiro, me oriento pelos preços dos quartos dos hotéis em um determinado Comparable Set para determinar os preços dos meus quartos.

Estas são duas Stories adicionais:

• 1c: Como hoteleiro, quero ajustar o preço ideal dos quartos do meu hotel à ocupação prevista.
• 1d: Como hoteleiro, posso definir parâmetros que influenciam o preço ideal, como a taxa de ocupação desejada, a ocupação mínima e a ocupação máxima (pode ser superior a 100%).

Conclusão sobre a divisão de Epics

Quase todas as equipes têm dificuldades no início para dividir User Stories corretamente. Pela experiência, em algum momento dentro do primeiro ano acontece um "clique" e então os membros da equipe sabem como dividir as Stories especificamente para sua área de especialização e seus projetos. Se você ainda não está tão familiarizado com Agile ou User Stories, continue firme – com o tempo fica mais fácil!