Como lidar com o planejamento do sprint por muito tempo?


14

Levei mais de 5 horas no planejamento do sprint por um sprint de uma semana. Isso parece demais.

Discutimos as coisas em detalhes no planejamento do sprint, pois a maioria dos membros da equipe não é sênior. Caso contrário, isso levará a erros durante a implementação e o reprojeto durante o sprint.

Como nós lidamos com isto?

Quantos detalhes devo discutir durante o planejamento para ajustá-lo a apenas 2 horas por sprint semanal?


2
O que exatamente você está fazendo no Sprint Planning? Você está dividindo histórias, refinando requisitos, fazendo design, estimando?
Liath

1
Obrigado, esqueci de contar. Passamos a maior parte do tempo fazendo design.
precisa saber é

1
Você está cuidando da lista de pendências em uma reunião separada? Normalmente, fazemos o registro de pedidos em atraso de 1 hora por sprint e o planejamento de sprints em 1 hora por sprint. Isso tem funcionado bem nos nossos sprints de duas semanas.
Berin Loritsch

4
@ b.ben mas "design" não faz parte do planejamento do sprint.
Thomas Junk

2
er espere, por que você está falando sobre implementação durante o planejamento do sprint? Planejamento do sprint é sobre o que não como .
Candied_orange 11/0818

Respostas:


20

Você está certo - 5 horas no Sprint Planejamento para uma semana O Sprint parece demorar muito. O Guia do Scrum leva o Sprint para 8 horas por 1 mês e diz que "para Sprints mais curtos, o evento geralmente é mais curto". Se você considerar a proporção, uma boa meta pode ser 2 horas de Sprint Planning para uma Sprint de 1 semana, mas não há uma caixa de tempo fixa.

Então, como você pode abordar um longo Sprint Planning?

Como Scrum Master, eu daria os seguintes passos:

Primeiro, eu trabalhava com o Dono do produto para garantir que o Backlog do produto seja pedido corretamente. É essencial um refinamento eficaz do backlog e um planejamento de sprint para garantir que o trabalho mais importante e suas dependências estejam no topo do backlog do produto, para que a equipe do Scrum possa concentrar suas energias na definição, refinamento e preparação do trabalho correto.

Segundo, garantiria que a equipe estivesse gastando tempo suficiente no refinamento de backlog. O Guia Scrum indica que as atividades de aprimoramento geralmente não ocupam mais de 10% da capacidade de uma equipe de desenvolvimento. Como exemplo, uma equipe de desenvolvimento de 4 pessoas trabalhando uma semana padrão de 40 horas deve planejar cerca de 16 horas de refinamento de backlog. Isso pode ser feito individualmente, em pequenos grupos ou em equipe. Descobri que ter uma sessão planejada de refinamento de lista de pendências para a equipe e depois iniciar qualquer pesquisa ou investigação ou planejamento tende a funcionar melhor.

Terceiro, verifique se a equipe percebe que não precisa acertar todos os detalhes no Sprint Planning. O objetivo do Sprint Planning é produzir um plano para a conclusão dos Objetivos da Sprint. Não tente fazer um design grande antecipadamente em uma sessão de planejamento da Sprint. Entenda como diferentes trabalhos se encaixam, dependências e objetivos e use o tempo fora das sessões de Planejamento da Sprint com as pessoas certas para executar o design, a implementação e os testes necessários para a entrega do trabalho.

Podem ocorrer mais etapas, mas esse seria um bom ponto de partida.


3
Basicamente, a equipe ainda passará o mesmo número de horas em reuniões. Nós apenas os chamamos de reuniões diferentes. :) É preciso o suficiente para quebrar as coisas o suficiente para que a equipe se sinta à vontade em estimar o trabalho e seja independente na hora de fazer o trabalho.
Greg Burghardt

5
@ GregBurghardt: O OP escreve que eles passam a maior parte do tempo fazendo design. Assim, toda a equipe trabalha no design de cada história. Se você dividir isso para que apenas parte da equipe trabalhe em cada história, reduz o tempo total gasto nas reuniões.
Michael Borgwardt

Re: "certifique-se de que a equipe perceba que não precisa acertar todos os detalhes no Sprint Planning": E, mais importante, verifique se é realmente verdade que eles não precisam acertar todos os detalhes no panning de sprint .
Ruakh

@GregBurghardt Maybe. Mas há uma diferença entre a equipe inteira estar em uma sala por 5 horas e diferentes combinações de pessoas que estão fora do trabalho de design por 3 horas após uma sessão de planejamento de 2 horas.
Thomas Owens

5

Eu te escuto. É muito tempo para gastar! Felizmente, sua equipe está discutindo isso em suas retrospectivas. Tentamos várias experiências com resultados mistos:

  1. Todo mundo faz um design de alto nível em um único ticket e o passa para a esquerda ou direita ao redor da mesa para revisão, seguido de uma revisão em grupo do plano de cada ticket. Nem todo mundo gostou disso, mas forçou nossos juniores a experimentá-lo. Alguns indivíduos das equipes ficam muito felizes em deixar os outros pensarem e seguirem as instruções. Portanto, do lado positivo, nosso experimento obrigou todos a enfrentar suas lacunas de conhecimento, que constituiu um desafio de crescimento para os juniores. Do lado negativo, nem todo mundo gosta de ser colocado no local e isso não reduz necessariamente o tempo na reunião. Próximo!

  2. Projetos emparelhados foram tentados. Grupos de dois ou três dividiriam um ticket em tarefas. A equipe inteira revisaria os planos resultantes. Foi muito mais rápido, mas alguns mini-pods tiveram o mesmo problema de uma pessoa andar enquanto a outra fazia o trabalho no design.

  3. Ignore a divisão da tarefa. Decidimos que a média de nossa história era calculada, então estávamos perdendo tempo tentando envolver toda a equipe em tudo. Como resultado, tivemos reuniões de planejamento muito mais curtas, mas o trabalho de design era algo que nossos pares tinham que fazer por si mesmos quando iniciavam um ticket. Se os juniores estiverem trabalhando em um ingresso, espere que eles precisem de ajuda para superar essa etapa. Se você tentar isso, aceite menos histórias no sprint até se sentir confortável com ele. Além disso, verifique se é "seguro" que seus colegas de equipe peçam ajuda quando não souberem algo.

No final, tudo se resume à maturidade da equipe. As pessoas precisam entender as habilidades e preferências umas das outras e ter confiança de que os colegas de equipe pedirão sugestões quando precisarem. Corrija-os primeiro, se você não os tiver. Então, resolver o problema de reuniões ineficientes fica mais fácil.


4
A opção 3 cria equipes que dependem de uma única pessoa ou de um pequeno grupo de pessoas. Se essa pessoa ou pessoas não estiverem por perto, a velocidade da equipe vai direto ao banheiro. Eu costumava fazer isso com a nossa equipe, e toda vez que essa pessoa entrava em caos nas férias se seguia. Nada foi feito. Em seguida, o líder da equipe passou 3 semanas tentando acalmar o gerenciamento de projetos. Se você estiver trabalhando em uma equipe com juniores ou não especialistas, eu definitivamente não recomendaria o # 3. Se você tem todos os especialistas (e eles são realmente especialistas), o nº 3 pode economizar tempo.
Greg Burghardt

Se essa pessoa está apenas fazendo a tarefa de projetar para todos, com certeza, eu concordo. Mas e se essa pessoa estivesse ajudando as pessoas a melhorarem elas mesmas?
Jason Zinschlag

2
Tem sido minha experiência que eles não melhoram com alguém que os guia através das coisas. Acontece que as pessoas experientes fazem isso pelos menos experientes, porque os menos experientes demoram mais tempo em ordens de magnitude. Tivemos melhor sorte em sentar todos na sala e executar tarefas de desenvolvimento. Mesmo passando pelo código - mas não durante o planejamento do sprint. Chamamos isso de "escrever tarefas de desenvolvimento" porque é disso que nossa equipe precisa. Então eles começaram a se tornar independentes e começaram a se tornar cada vez melhores e mais rápidos na criação de tarefas de desenvolvimento.
Greg Burghardt

Que bom que sua equipe encontrou um caminho. Você acha que seus colegas de equipe experientes estavam seguindo o caminho mais fácil? Ensinar as pessoas é uma dor de cabeça, eu sei. Mas paga grandes dividendos. A maioria das pessoas não tem paciência para isso, e vejo exatamente o que você está descrevendo - pessoas experientes podem facilmente perder a paciência com o processo e "fazer elas mesmas". Além disso, os juniores precisam ser bons alunos.
Jason Zinschlag

@GregBurghardt Eu acho que fizemos algo como "escrever tarefas de desenvolvimento" durante o planejamento do sprint. E não tenho certeza se está tudo bem?
precisa saber é

3

Gosto da resposta que você recebeu de @ Thomas-Owens, mas também adicionarei mais um item. Você já pensou em fazer programação em pares como parte de sua implementação Agile?

A programação em pares ajudaria (1) a ensinar alguns de seus programadores juniores como escrever um código melhor e (2) na programação em pares, você nem sempre precisa ter todos os recursos de design definidos para você no planejamento de sprint. Com o par trabalhando em conjunto, algumas dessas decisões de design podem ser tomadas "espontaneamente" com os benefícios adicionais de programação do par.

Se você pode ajudar seus programadores juniores a aprender mais rapidamente e você sabe que os itens de design que você não abordou no Sprint Planning serão decididos por duas pessoas, não há razão para que você não consiga reduzir o tempo gasto em Planejamento futuro da Sprint


Sim, era o que eu queria. Mas nossa equipe não tem senior suficiente para fazer isso. Eu tenho uma ideia que permitirá que todos os membros da equipe escrevam as abstrações e interfaces, antes de iniciar a implementação, vamos fazer uma reunião para concordar entre todos os desenvolvedores. O que você acha?
precisa saber é

1
@ b.ben Mas sua equipe nunca terá idosos suficientes até que você faça isso. Isso faz parte do poder da programação em pares. Você deve se comprometer com isso.
Unknown Coder

1

Não sou aficionado por scrum e tenho apenas um ano de experiência prática. Portanto, o seguinte deve ser lido com um grão de sal.

Vejo várias bandeiras vermelhas no que você escreve:

5 horas de planejamento de sprint

Isso é muito longo para uma corrida de uma semana.

O objetivo do planejamento do sprint é AFAIR

  • permitir que a equipe saiba quais são as prioridades atuais e
  • para desenvolver um plano de batalha para o próximo sprint.

Para fazer isso de forma eficaz, cada lado precisa entender o Product Backlog items.

Para entender o Product Backlog itemsbacklog, deve estar em boa forma.

Na fase de planejamento concreto, eles Product Backlog itemssão transformados em Sprint Backlog items.

Uma causa possível é que esses itens não são esclarecidos / refinados o suficiente.

Outra causa possível é que os itens são muito complexos e deixam espaço para muita interpretação.

Discutir muito detalhado no planejamento de sprint

Como dito acima, a fase de discussão será mais curta, quando os itens forem mais concretos.

Por outro lado: o planejamento da Sprint espera um comportamento profissional de todos os participantes. Isso inclui evitar discussões sobre ciclismo .

Talvez as coisas estejam claras, mas alguém inicia uma discussão sobre ciclismo .

Mais: evite discussões sobre detalhes de implementação . Embora toda idéia acabe no código em algum momento, não é o objetivo do planejamento do sprint discutir se uma matriz simples fará o truque ou será melhor usar uma lista vinculada.

Como a maioria dos membros da equipe não é sênior

No scrum, não há distinção entre senior e junior . Ambos são apenas desenvolvedores. E esse é um bom ponto de partida, o que ajuda a manter sua discussão focada em uma solução viável, apoiada nos melhores argumentos e não no salário.

Erros de implementação e reprojeto durante o sprint

Parece haver um problema fundamental na coleta de requisitos, seguido por um estoque muito vago de produtos.

Como eu disse acima: Desde que Product Backlogesteja em boa forma, deve ser difícil não entender.

Não consigo imaginar uma situação como:

»Como usuário, quero ver alguns clientes!«

»Oh, você não quis dizer todos os nossos 2 milhões de clientes?«

OTOH: O que significa, neste contexto, redesenho ? Se um desenvolvedor escolheu um algoritmo de desempenho lento , existe o próximo objetivo claro: escolha um algoritmo de melhor desempenho. Mas isso não é "redesign", é uma otimização.


Para suas principais perguntas:

Como lidar com isso?

É trivial mencionar, mas eu faço assim mesmo: não esqueça que você está lidando com humanos .

É muito difícil ter um grupo de mentes diferentes, capazes de compartilhar conceitos comuns (como em Rashomon ). Para lidar efetivamente com isso, use o máximo de redundância possível em sua comunicação: por exemplo, explique o contexto do item extensivamente, mesmo que todos "saibam" o que fazer. Faça perguntas, se todos entendem qual é o tópico de um determinado item.

Se você está jogando no planejamento de pôquer, um bom indicador, se o entendimento é bom o suficiente, é que as tarefas são classificadas como baixas. Baixo significa baixa complexidade, fácil de entender e difícil de perder.

Um efeito colateral da iteração é que os números de determinadas tarefas aumentam (porque a equipe tem um entendimento de seus recursos e das complexidades ocultas). Depois, há a chance de dividir o item em vários itens menos complexos e com menor complexidade.

Quantos detalhes devo discutir durante o planejamento para caber 2 horas de duração por uma semana de corrida?

Resposta salomônica: o menos possível e o necessário, mas não mais.

tl; dr

  • Escolha um idioma fácil (se ajudar, use inglês simples ou ELI5) para evitar mal-entendidos

  • Melhorar a coleta de requisitos

  • Melhorar lista de pendências

  • Aumentar a confiança dos membros da equipe em suas capacidades individuais, bem como em suas habilidades como equipe

  • Evite ciclismo

  • Melhore a disciplina pessoal

  • Talvez use caixas de tempo fixas para cada item para discutir

  • Reforçar a posição do scrum mastermoderar de forma eficaz.


-2

Conseguimos reduzir muito o tempo de reunião de planejamento, fazendo a limpeza do total de três horas em duas semanas de corrida. Dividimos a preparação em quatro sessões. fazemos 30 minutos de limpeza na segunda-feira e 1 hora na quarta-feira toda semana. Nossos sprints começam na segunda-feira e terminam na sexta-feira. Como resultado, temos boas informações de reuniões de preparação que contribuem como insumo para o planejamento, que o torna mais curto. Nosso melhor registro foi uma reunião de planejamento de 30 minutos em um de nossos sprints. Na maioria das vezes, não leva mais de uma hora a uma hora e 30 minutos. De qualquer forma, ainda é tempo, mas o planejamento foi feito muito cedo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.