Imagine esse cenário: você está na rua, observando a cidade à sua frente. Construções, carros, pessoas e outros se distribuem desde você até o horizonte distante. Para descrever o que está vendo, que nível de detalhes você pode utilizar nessa descrição? Agora imagine o seu próximo projeto de desenvolvimento de software. Ao planejá-lo, desde seu início até, digamos, daqui a seis meses, que nível de detalhes você pode utilizar nesse plano?
Na cidade, ao olhar para o que está mais próximo de você, é possível descrever o que vê com um excelente nível de detalhes. Mas, à medida que olha para mais longe, os detalhes que pode utilizar nessa descrição vão gradualmente diminuindo. Se você então tentar descrever o que está mais longe com um alto nível de detalhes, ao caminhar em direção ao horizonte, verá que sua descrição não corresponde inteiramente à realidade. Na verdade, para quanto mais distante você estiver olhando, mais incorreta estará sua descrição se ela for detalhada.
Um planejamento tradicional geralmente busca descrever em detalhes o que será feito durante todo o projeto ou, ao menos, todo o trabalho até a próxima entrega, por exemplo. É muito comum ver esses planos descritos em gráficos de Gantt, que mostram tarefas pequeninas e alocação de “recursos” no tempo. Essa prática pode ser comparada à de se descrever detalhadamente todo o caminho, desde o que está mais próximo de você até o que está lá longe, na linha do horizonte, portanto com muito mais detalhes do que é possível. O resultado dessa prática é um plano com baixíssima chance de acerto. E para que serve um plano assim?
Em um planejamento Ágil, utilizamos apenas o nível de detalhes que podemos “enxergar”. Para planejarmos um trabalho a ser realizado até o próximo dia, por exemplo, podemos utilizar um nível de detalhes bastante alto. Isso é, cada pequena tarefa a ser realizada. Para as próximas duas semanas – um ciclo de desenvolvimento, por exemplo – podemos utilizar um nível de detalhes ainda razoavelmente alto, porém menor do que para apenas um dia. Ao planejarmos uma entrega que acontecerá daqui a dois meses ou mesmo o ano inteiro de projeto, a quantidade de detalhes diminui quanto mais longe olhamos no tempo, de forma que pouquíssimos detalhes podem ser utilizados para planejarmos o que está mais distante.
A lista de necessidades de negócios do Scrum, chamada de Product Backlog, reflete esse planejamento Ágil. O alto do Product Backlog possui itens com uma granularidade mais fina, ou seja, itens menores e que representam mais detalhes. Ao olharmos mais abaixo no Product Backlog, vemos que os itens vão ficando cada vez maiores e com menos detalhes. À medida que o projeto caminha no tempo, os itens do Product Backlog devem ser refinados continuamente com cada vez mais detalhes, refletindo apenas aquilo que conseguimos “enxergar” em cada momento.
