Product Backlog, planejamento contínuo e a analogia do horizonte

Compartilhe

Product Backlog, planejamento contínuo e a analogia do horizonte

15/07/14 - 2 minutos de leitura

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?

A Analogia do Horizonte

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.

Compartilhe

Escrito por

Rafael Sabbagh

Co-fundador e Trainer na K21


Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

    Receba mais conteúdos K21

    Deixe seu nome e email que nós te deixamos por dentro de tudo que rola por aqui.

    Ao informar meus dados, eu concordo com a Política de Privacidade.