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.
Perguntas frequentes
Por que detalhar todo o planejamento de um projeto desde o início não funciona?
Planejar todo o projeto com alto nível de detalhes é ineficiente porque quanto mais distante o horizonte de tempo, menor é a capacidade de prever a realidade. Tentar detalhar entregas futuras gera planos com baixíssima chance de acerto, pois as descrições minuciosas não correspondem ao que realmente acontecerá conforme o projeto avança.
Como funciona a variação de detalhes no planejamento ágil?
No planejamento ágil, o nível de detalhamento varia conforme a proximidade do trabalho. Atividades para o dia seguinte exigem alto detalhe. Para ciclos de duas semanas, utiliza-se detalhamento razoável. Já para entregas futuras, de meses ou um ano, o plano contém pouquíssimos detalhes, ajustando-se à medida que o tempo avança.
Como os itens são organizados dentro de um Product Backlog no Scrum?
Os itens no topo do Product Backlog possuem granularidade fina, sendo menores e mais detalhados por estarem próximos da execução. Conforme se avança para a parte inferior do backlog, os itens tornam-se progressivamente maiores e com menor nível de detalhamento, refletindo necessidades de negócios mais distantes no tempo.
Por que o Product Backlog precisa ser refinado continuamente?
O refinamento contínuo do Product Backlog serve para adicionar detalhes aos itens à medida que o tempo passa e eles se aproximam da execução. Esse processo garante que o planejamento reflita apenas o que é possível enxergar a cada momento, adaptando o detalhamento do trabalho conforme a evolução natural do projeto.
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