Vale a pena o esforço de identificar tarefas no Iteration Planning?
Vale a pena identificar as tasks?
Ultimamente tenho escrito bastante sobre a identificação de tasks no Iteration Planning. O foco foi ajudar o time a identificar a quantidade e o tamanho certo de tasks.
Para a maioria dos times, a resposta é: Sim.
A lista de tasks em si não acho tão útil assim. Mas o fato de que você precisa pensar para criar essa lista – isso sim é extremamente útil.
Um exemplo de uma boa lista de tasks
Imagine que você está planejando uma viagem de fim de semana e quer fazer a mala. Você cria uma lista do que levar ou simplesmente começa a jogar roupas na mala. Você pensa um pouco sobre o que vai precisar. Mas também sabe que, se esquecer algo, pode comprar no destino se precisar.
Seria diferente se você estivesse planejando uma expedição ao Monte Everest. Nesse caso, você pensaria com muito mais cuidado sobre o que vai precisar. A mais de 8.800 m de altitude, fica difícil comprar algo que você esqueceu. Por isso, você certamente faria uma lista e provavelmente a conferiria duas ou três vezes.
Mas essa lista ainda seria útil durante a escalada do Monte Everest?
De jeito nenhum.
Mas o fato de você ter pensado intensamente sobre isso – isso sim.
O verdadeiro valor de identificar tasks
O mesmo vale para identificar tasks no Iteration Planning. Apenas pensar sobre essas tasks já é o valor agregado – e não necessariamente a lista em si.
Tudo na lista de tasks poderia teoricamente ter sido identificado em tempo real, diariamente durante a iteration. Porém, identificar tasks tão tarde pode levar a problemas de coordenação e atrasos. Se eu sei que vou precisar de algo de alguém na próxima semana, essa pessoa pode planejar quando vai fazer essa tarefa. Se eu preciso de algo de alguém imediatamente e não posso continuar antes dessa tarefa ser concluída, a pessoa não tem o luxo de decidir quando vai fazer. Ela precisa trabalhar nisso agora, porque eu estou esperando.
Seu time deveria identificar tasks no Iteration Planning ou não?
Em princípio: Sim. Acredito que um time pode parar de identificar tasks assim que dominar o seguinte:
Colaboração durante a iteration para trabalhar nos itens recém-descobertos.
Saber quantos (e quais) Product Backlog Items devem incluir na iteration.
Na minha opinião, times deveriam identificar tasks até atingirem esse ponto. Mas lembre-se de identificar apenas cerca de dois terços de todas as tasks da iteration. Esse é um bom parâmetro para pensar no que precisa ser feito, sem pensar demais.
É como planejar a expedição ao Monte Everest e saber que pelo menos alguns últimos suprimentos ainda podem ser comprados em Katmandu.
A problemática da identificação de tarefas
Existem dois problemas quando as equipes querem identificar cada tarefa individual no Iteration Planning:
É praticamente impossível querer identificar tudo, exceto as coisas mais óbvias. Não importa quanto esforço a sua equipe faça, nunca conseguirá pensar em tudo antecipadamente.
Dá muito trabalho.
O propósito do Iteration Planning é selecionar os Product Backlog Items certos – exatamente a quantidade de itens mais importantes para a entrega.
Uma equipe pode fazer tudo isso sem precisar pensar em cada detalhe que precisa ser feito nessa iteração. Desde que os membros da equipe reflitam sobre as coisas mais importantes, eles também conseguem selecionar a quantidade certa dos Product Backlog Items certos.
Ao fazer isso, os membros da equipe precisam considerar o seguinte:
Tarefas grandes
Tarefas que exigem muita coordenação – seja entre os membros da equipe ou entre membros da equipe e pessoas de fora
Tarefas que provavelmente fazem parte do caminho crítico
As tarefas originais ou principais dos itens do Product Backlog, onde ainda há muita incerteza
Além desses pontos, não é realmente necessário pensar em mais nada. Isso seria apenas uma grande perda de tempo e faria com que os membros da equipe não quisessem mais participar das reuniões mais importantes, já que estariam de saco cheio.
O que um bom Scrum Master ou Agile Coach pode fazer
Durante algumas iterações, não se deve fazer nenhuma alteração, exceto contar as tasks identificadas no Iteration Planning. Depois, conta-se as tasks que existem no final da iteração. Devem ser contadas todas as tasks, incluindo as que ainda não foram concluídas ou iniciadas.
Depois de fazer isso durante uma ou duas iterações, calcula-se a percentagem de tasks que foram identificadas pela equipa no Planning Meeting.
Um exemplo:
Vamos supor que uma equipa completou três iterações. Na primeira iteração, a equipa identificou 50 tasks no Planning Meeting e no final da iteração havia um total de 60 tasks no Iteration Backlog. Isso significa que 10 tasks foram adicionadas durante a iteração.
Na segunda iteração, a equipa identificou 45 de 60 tasks no Planning Meeting. E na última iteração, 55 de um total de 70 tasks.
Isso significa que a equipa identificou 50 + 45 + 55 de um total de 60 + 60 + 70 tasks nos Planning Meetings. São 150 de um total de 180 tasks. A equipa identificou, portanto, 83% de todas as tasks durante os três Planning Meetings.
Isso é demais.
Pela minha experiência e depois de realizar esta medição com muitas equipas, posso dizer que equipas ágeis bem-sucedidas identificam aproximadamente dois terços de todas as tasks no Planning.
Se a tua equipa identificar mais do que esses dois terços nas reuniões (como a equipa no exemplo acima), então a tua equipa provavelmente está a passar tempo demais no Iteration Planning Meeting.
Explica isso à tua equipa no próximo Iteration Planning Meeting e felicita os membros da equipa pelo esforço dedicado ao Planning. Depois diz-lhes que vais reduzir o tempo em 30 minutos.
No entanto, se a percentagem da tua equipa estiver abaixo de 67%, partilha também esta informação com os membros da equipa e diz-lhes que tanto a equipa como tu próprio irão beneficiar de uma abordagem mais aprofundada no Planning. Depois adiciona 30 minutos ao tempo de planeamento.
Repete isto até que a tua equipa identifique aproximadamente dois terços de todas as tasks no Planning Meeting. E mais uma vez, não estou a dizer que se deve simplesmente interromper a discussão quando se atinge um limite mágico. Usa isto simplesmente como uma orientação prática para dedicar a quantidade certa de tempo nos Iteration Planning Meetings.
Quero salientar novamente que estou a falar de dois terços das tasks de uma equipa. Isso será certamente mais do que dois terços do tempo planeado de um Iteration Planning Meeting. As tasks que não são identificadas no Planning Meeting são geralmente as tasks mais pequenas.
Aprende mais sobre o apoio no Planning ou Refinement no nosso treinamento certificado de Scrum Master. Se ajudares a tua equipa a identificar apenas cerca de dois terços das tasks de uma iteração, estarás a ajudar a tua equipa a ter sucesso com Agile.
