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?

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.

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.

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

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.

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.