Qual é a forma mais rápida de uma equipe Scrum eficiente perder o rumo? Simples: esquecer que a metodologia ágil e a estrutura Scrum visam economizar tempo.
Todos, desde os iniciantes em gestão de projetos até o mais experiente Scrum master, estão propensos a cometer esse erro.
Felizmente, há um sinal de alerta claro. O problema começa quando o cronograma deixa de ser respeitado. Estabelecer um cronograma para as reuniões de planejamento de sprint é mais do que uma formalidade. O Scrum não seria Scrum sem prazos definidos. Mas e se você não conseguir fazer tudo dentro do prazo pré-determinado? Bem, essa é a parte complicada. E a razão pela qual nem todo mundo consegue usar a estrutura Scrum corretamente.
Mas não se preocupe: neste artigo vamos explicar exatamente como aproveitar ao máximo o período de planejamento do sprint.
Quando você deve fazer o planejamento de sprint?
Uma breve recapitulação: a estrutura Scrum divide os projetos em pequenas seções chamadas sprints, geralmente com duração de 1 a 4 semanas. Cada sprint começa com uma reunião de planejamento de sprint.
Durante o planejamento de sprint, a equipe do projeto analisa o trabalho contido no backlog do produto e decide quais elementos da lista serão abordados no próximo sprint. Ao final de cada sprint, a equipe faz uma retrospectiva para discutir o que deu certo e o que poderia ter sido melhor.
Então, o sprint seguinte começa e, com ele, a próxima sessão de planejamento de sprint. Toda a equipe Scrum deve estar envolvida nesse planejamento, juntamente com o Scrum master e o product owner. O ideal é que a sessão seja realizada no início da semana, para que ela conduza a 4 dias ininterruptos de produtividade. Mas esse não é um detalhe essencial.
Por enquanto, lembre-se de que o planejamento de sprint começa no início de cada sprint.
Comece a usar o monday devO que é feito no planejamento de sprint?
A sessão de planejamento de sprint define o que acontecerá durante o sprint com base no que a equipe Scrum é capaz de realizar. Ela também serve para que toda a equipe permaneça alinhada com o mesmo plano de sprint.
Uma reunião de planejamento de sprint geralmente começa com o product owner anunciando a meta do sprint. Esse é o profissional responsável por garantir que tudo em que a equipe trabalha agregue valor ao produto.
Por exemplo, se o seu projeto for criar um app SaaS, o product owner poderá definir como meta o lançamento de um painel de usuário até o final do sprint. Ele usará isso para demonstrar o valor do app às partes interessadas. A equipe utiliza a meta do sprint como uma diretriz para determinar em quais elementos do backlog do produto trabalhará durante o sprint.
O backlog do produto reúne as metas de desenvolvimento para todo o projeto. Mas se a equipe tentar trabalhar em todos os elementos do backlog em um único sprint, não chegará a lugar algum. A meta do sprint ajuda, assim, a priorizar.
Em sua essência, o planejamento de sprint é uma negociação. O product owner faz uma oferta inicial. Em seguida, a equipe Scrum responde com uma oferta de quanto pode ser feito.
Isso se repete até que ambas as partes estejam satisfeitas (pelo menos, o máximo possível). O product owner consegue recursos suficientes para agregar valor, e a equipe do projeto tem um volume de trabalho pequeno o suficiente para que possa dedicar tempo à execução correta.
O template de planejamento de sprint da monday.com é um bom exemplo visual.
À medida que as conversas de planejamento de sprint progridem, o líder da equipe Scrum e o product owner podem mover elementos pelo painel, representando o que todos decidiram.
No entanto, ainda no nosso exemplo, a equipe de desenvolvimento sabe que criar e preencher o painel levará mais de duas semanas. Por isso, ela convence o product owner a apresentar um painel vazio, que ainda pode ser mostrado aos acionistas e demonstrar valor.
É um equilíbrio delicado, mas com algumas dicas, você pode criar uma sessão de planejamento de sprint que funcione para todos.
Leia também: Metas de projeto: como definir (e alcançar) o sucesso
Como fazer um bom planejamento de sprint?
Os itens abaixo fazem parte das nossas práticas recomendadas de planejamento de sprint. Chegamos a todas elas com muito trabalho… e muitas falhas.
No decorrer da lista, também apresentaremos alguns componentes do Work OS da monday.com que facilitam muito o planejamento de sprint.
1. Organize seu backlog
Uma das melhores maneiras de garantir uma reunião de planejamento de sprint eficiente é fazer uma outra reunião com antecedência. Isso pode parecer um tanto contraditório. Reuniões para planejar outras reuniões soam como o exato oposto da gestão ágil de projetos.
Mas há alguns motivos importantes pelos quais as reuniões prévias fazem sentido. Em primeiro lugar, elas não precisam envolver toda a equipe Scrum. Uma pré-reunião pode ser composta apenas pelo gerente de projeto (ou Scrum master) e pelo product owner. Além disso, ela pode prever situações de risco que prejudicariam o planejamento do sprint se surgissem inesperadamente.
Imagine que você está no meio do planejamento de sprint e alguns membros da equipe do projeto discordam sobre o significado de uma determinada história (ou story) no backlog. Ou, talvez, eles descubram que estavam completamente errados sobre onde aquela história se encaixava no épico.
Pode ter certeza de que essa sessão de planejamento de sprint ultrapassaria o tempo previsto.
Por isso, muitas equipes de projetos ágeis adotaram uma prática chamada backlog grooming (ou preparação de backlog), backlog refinement ou story time para ajudar a evitar essa espiral descendente.
Em sessões privadas de preparação do backlog, os líderes de equipe podem reorganizar o backlog para que ele reflita as prioridades estratégicas mais recentes. Eles também podem acrescentar contexto esclarecedor a qualquer história vaga ou ambígua.
Às vezes, você pode optar por convidar sua equipe para uma sessão de preparação do backlog. Nesse caso, a sessão dá aos membros a chance de fazer perguntas sobre uma história antes de incluí-la em um plano de sprint. No entanto, se não quiser consumir o tempo produtivo da sua equipe, temos outra sugestão: o template de backlog de recursos da monday.com.
Durante uma pequena sessão de preparação do backlog, o líder de equipe e o product owner podem atualizar o template. Qualquer membro da equipe pode fazer login e ver imediatamente as alterações que foram feitas.
É uma maneira rápida e visualmente interessante de manter todos alinhados no planejamento de sprint. Como gerente de projeto, esteja aberto a todas as perguntas que sua equipe possa fazer a respeito.
2. Agende a retrospectiva separadamente
Sim, nós sabemos: estamos pedindo que você faça ainda mais reuniões. Isso está começando a parecer uma história em quadrinhos do Dilbert.
No entanto, não achamos que o problema seja o número de reuniões. O problema são as reuniões ineficientes. Reuniões, stand-ups ou sessões individuais devem ser rigorosamente controlados e alocados onde terão o máximo impacto.
É por isso que você nunca deve fazer a retrospectiva do sprint na mesma reunião que o planejamento de sprint.
Muitas vezes, os gerentes de projeto acham que estão economizando tempo ao fazer isso: “Um sprint começa exatamente onde outro termina. Não há necessidade de ter um espaço vazio entre eles”. Mas essa abordagem comete dois erros.
Primeiro, ela dobra a duração da reunião, aumentando o risco de lapsos de atenção logo no início do importante trabalho de planejamento. Em segundo lugar, o intervalo não é exatamente um espaço vazio. O tempo entre a retrospectiva e o planejamento é, na verdade, um tempo de processamento fundamental.
Os membros da sua equipe podem, sozinhos, assimilar as lições do sprint anterior e experimentar maneiras de agir de acordo com essas lições.
Durante a retrospectiva, use o template de retrospectiva de sprint da monday.com para organizar as reflexões de todos.
Recomendamos deixar passar pelo menos uma hora de almoço entre as duas reuniões. Melhor ainda, encerre a semana do sprint com uma retrospectiva na sexta-feira à tarde e comece a nova semana – e sprint – com uma sessão de planejamento na segunda-feira de manhã.
Depois de apresentar claramente as lições do último sprint no template, basta um pouco de tempo para que elas sejam absorvidas.
3. Atribua valor a cada elemento do backlog
Depois que o product owner define uma meta de sprint, a equipe determina quanto dela pode entregar.
Para essa parte do plano, há alguns termos que você deve conhecer.
A velocidade é um aspecto fundamental do planejamento do sprint. Ela mede o quanto sua equipe pode fazer durante um sprint médio. Todos na sua equipe devem ter uma boa noção da própria velocidade.
Os story points são um método popular de gamificar o planejamento do sprint. O valor do ponto (point) de uma tarefa, ou história (story), é uma medida relativa de quanto esforço será necessário para concluí-la.
Os story points (SPs) são ótimos para ajudar a medir o esforço de um trabalho, mesmo quando é muito difícil fornecer estimativas de tempo específicas para as tarefas.
O Scrum Poker, ou pôquer de planejamento, é um processo usado para atribuir story points. Para jogar, siga estas etapas:
- Dê a cada membro da equipe cartões com os números de 1 a 10 impressos em um lado.
- Pegue todos os elementos do backlog que você determinou como parte da meta do sprint e anuncie-os, um de cada vez.
- Para cada elemento, os membros da equipe colocam um cartão virado para baixo com sua estimativa para o story point.
- O líder da equipe embaralha os cartões e os vira. Se todas as estimativas forem relativamente próximas – por exemplo, todos 3, 4 e 5 – faça a média dos números para obter a estimativa final.
- Se não forem próximas (por exemplo, um 2 e um 9 para a mesma tarefa), todos os que colocaram um número fora do padrão o reivindicam e argumentam por que deram essa estimativa.
- Repita as etapas 3 a 5 até chegar a um consenso.
- Passe para o próximo elemento até que você tenha analisado todas as tarefas do backlog que se encaixam na meta do sprint atual.
O pôquer do Scrum é uma ótima maneira de chegar a um consenso e, ao mesmo tempo, fazer com que todos se sintam ouvidos. Se parecer muito complicado neste momento, recomendamos o template de planejamento Scrum da monday.com.
É muito fácil personalizá-lo para que fique como um pôquer de planejamento ou qualquer outra forma de atribuição de story points.
Depois de atribuir story points a cada tarefa, chegar a um escopo final para o sprint é aritmética simples. Então, é só distribuir as tarefas para a sua equipe e começar.
Leia também: Story points: o guia das equipes ágeis
4. Colete dados ao longo do tempo
Um sprint não é uma ilha. Cada sprint é uma iteração do anterior. Com cada sprint, você tem informações mais precisas sobre a velocidade da sua equipe.
Quanto maior a compreensão da velocidade anterior, mais precisas serão as projeções futuras. Por exemplo, nossa equipe de P&D na monday.com usa uma abordagem em que 1 story point equivale a aproximadamente 1 dia de trabalho para 1 desenvolvedor. Para um sprint de 10 dias, atribuímos a cada desenvolvedor 9 story points de trabalho, deixando 1 dia livre para lidar com bugs ou atrasos inesperados.
Se os membros da sua equipe fizerem essa atualização regularmente no final de cada dia, você logo terá dados suficientes sobre a velocidade de todos.
O que deve ser feito após o planejamento de sprint?
Após uma reunião de planejamento de sprint, registre diligentemente todas as decisões tomadas pela equipe. Não deixe de atualizar o escopo do sprint, as tarefas individuais de cada um, todas as alterações no backlog e tudo o mais que surgir.
Parece muito trabalhoso? Pois é. A organização pós-sessão pode tomar o dia inteiro de um líder de equipe. Felizmente, nós podemos ajudar com automações avançadas de fluxo de trabalho no Work OS da monday.com – uma plataforma criada por gerentes de projeto para ajudar outros gerentes de projeto a criar as ferramentas necessárias para economizar tempo.
Imagine se cada estimativa de story point fosse automaticamente atualizada no roteiro geral do projeto. Ou se cada tarefa reivindicada por um membro da equipe aparecesse diretamente em seu rastreador de tarefas diárias.
Em um Work OS, os templates vinculados se atualizam mutuamente, de modo que todos os registros do progresso do seu projeto permanecem sempre atualizados.
Leia também: O ciclo de vida da gestão de projetos
Considerações finais sobre o planejamento de sprint
A dica mais importante para um planejamento de sprint eficiente? Começar antes da reunião e ir para ela já com um plano. A segunda mais importante? Concentrar-se nos membros reais da equipe, e não em um Scrum ideal e perfeito.
Ao coletar dados suficientes para realmente conhecer a sua equipe, você pode garantir que os planos do sprint sejam seguidos. Isso aumenta a confiança para o próximo, em um ciclo de feedback positivo.
Confira os templates da monday.com hoje mesmo para criar as ferramentas que o ajudarão a chegar lá.
Com o Work OS da monday.com
Comece já