05 Desenvolvendo Epic(s)
No Scrum, os times que completam o trabalho, atribuem estimativas de esforço para cada User Story. Claro, pode-se assumir que um time pode chegar a um consenso sobre uma estimativa apropriada. O que acontece quando um story inclui tantas incognitas que se torna difícil estimar seu tamanho? Por outro lado, e se os requisitos da Story são conhecidos mas requerem um grande esforço para serem completos numa só sprint? Chamamos essas stories de “epics” (épicos). Enquanto um time deve conseguir lidar com uma story típica entre quatro e dezesseis horas, uma epic é uma story que poderia requerer doze ou muito mais horas para ser cumprida. A maioria dos experts do Scrum sugerem que qualquer tarefa que requeira doze horas ou mais deve ser decomposta em várias tarefas pequenas. Essas stories não só serão menores em seu escopo, mas previstas de forma mais definida. Dividir os Epics ajuda o time de desenvolvimento a traduzir o trabalho em pedaços que possam ser completos em um só dia.
Existe algum perigo em estimar uma epic? Muito simples, a resposta é sim. Estimar as epics pode ser prejudicial porque isto causa um falso senso de certeza para o Product Owner, que começa a acreditar que os requisitos, tarefas e esforços da epic são conhecidos. Quando um Time estima uma epic, esta estimativa é apenas isto – uma estimativa – isso raramente continua sendo o melhor palpite. Essa estimativa é usada na maior parte do tempo para previsões, as quais, por sua vez se tornam a base para um orçamento. Quando isso acontece, essa estimativa torna-se uma projeção inflexível que vincula o time a uma quantidade de trabalho desconhecida enquanto respeita um orçamento estabelecido.
Quando se coloca uma User Stories em um Backlog do Produto (ou lista de funcionalidades), não se deve ter a obrigação de quebrar tudo em funcionalidades até que os recursos estejam próximos ao desenvolvimento. Mais abaixo no Backlog do Produto, é normal que os itens estejam confusos. Também é normal que os itens abaixo no backlog sejam projetos inteiros – itens grandes e de alto nível que não se parecem tanto com User Stories, mas com Epics!
À medida que um item se aproxima do desenvolvimento, ele deve ser dividido ainda mais. Além disso, à medida que se chega ao desenvolvimento, o item do backlog deve ser definido em detalhes suficientes para que o time possa estimar razoavelmente seu tamanho e quebrá-lo em tarefas. Até esse momento, no entanto, ele é apenas um lugar reservado, uma lembrança para priorização e estimativa de alto nível. E só.
Para algumas pessoas, particularmente para aqueles que usam uma abordagem de projeto mais tradicional, que estão acostumados com especificações detalhadas logo de início, isto pode soar bem desconfortável. Mas não deveria. A lógica é simples: existe um pequeno ponto definindo uma funcionalidade (ou um conjunto delas) em detalhes que pode ser que nunca chegue ao topo das prioridades. Um outro aspecto dessa lógica é que você tende a saber mais sobre requisitos, limitações, etc, à medida que o tempo passa. Ademais, as coisas mudam. As pessoas vêm e vão. As vezes o time muda de forma tão significante desde que os requisitos originais emergiram que as informações podem se perder se capturadas muito cedo. Portanto, faz sentido para os negócios adiar detalhes até que eles sejam necessários.