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? É assim que vamos iniciar nossa reflexão sobre Product Backlog!
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.
Quer aprender mais sobre isso, dê uma olhada no nosso treinamento de Certified ScrumMaster® (CSM).
Veja como isso pode ser utilizado para planejar todo o portfólio.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21
