Como lidar com o planejamento de sprint em execução por muito tempo?

14

Eu levei mais de 5 horas no planejamento da sprint para uma sprint longa semana. Isso parece demais.

Discutimos as coisas detalhadamente no planejamento de sprint, já que a maioria dos membros da equipe não é sênior. Se não, isso levará a erros durante a implementação e redesenho durante o sprint.

Como lidamos com isso?

Quanto detalhe devo discutir durante o planejamento para ajustá-lo a apenas 2 horas de duração por semana?

    
por b.ben 10.08.2018 / 17:19
fonte

5 respostas

20

Você está certo - 5 horas no Sprint Planning para uma Sprint de 1 semana parece ser um longo tempo. As caixas de tempo do Scrum Guide Sprint Planning para 8 horas para Sprints de 1 mês e diz que "para sprints mais curtos, o evento geralmente é mais curto". Se você considerar a proporção, um bom alvo pode ser 2 horas de Sprint Planning para uma Sprint de 1 semana, mas não há timebox fixo.

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

Como Scrum Master, eu tomaria as seguintes etapas:

Primeiro, eu trabalharia com o Product Owner para garantir que o Backlog do produto seja solicitado corretamente. É essencial o Backlog Refinement e o Sprint Planning para garantir que o trabalho mais importante e suas dependências estejam no topo do Backlog do Produto, de modo que o Time Scrum possa concentrar suas energias na definição, refinamento e preparação do trabalho certo.

Segundo, eu me certificaria de que a equipe esteja gastando tempo suficiente no Backlog Refinement. O Guia do Scrum indica que as atividades de refinamento geralmente não levam mais que 10% da capacidade de uma Equipe de Desenvolvimento. Como exemplo, uma Equipe de Desenvolvimento de 4 trabalhando uma semana padrão de 40 horas deve planejar cerca de 16 horas de Refinamento do Backlog. Isso pode ser feito individualmente, em pequenos grupos ou em equipe. Descobri que ter uma sessão de refinamento do Backlog planejada para a equipe e, em seguida, sair para fazer qualquer pesquisa ou investigação ou planejamento tende a funcionar da melhor maneira possível.

Em terceiro lugar, certifique-se de que a equipe perceba que não precisa obter todos os detalhes corretamente no Planejamento da Sprint. O objetivo do Planejamento da Sprint é produzir um plano para completar as Metas da Sprint. Não tente fazer um projeto grande na frente 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 fazer o design, a implementação e os testes necessários para entregar o trabalho.

Mais etapas podem ser eliminadas, mas isso seria um bom ponto de partida.

    
por 10.08.2018 / 17:36
fonte
5

Eu ouço você. Isso é muito tempo para gastar! Espero que sua equipe esteja 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 passa para a esquerda ou direita ao redor da tabela para revisão, seguida de uma revisão do grupo do plano para cada ticket. Nem todo mundo gostou disso, mas forçou nossos juniores a experimentá-lo. Alguns indivíduos em equipes são muito felizes apenas deixando os outros pensarem e eles apenas seguem as instruções. Então, do lado positivo, nosso experimento forçou todos a confrontar suas lacunas de conhecimento, proporcionou 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. Os projetos em pares foram tentados. Grupos de dois ou três dividiriam um ticket em tarefas. Toda a equipe analisaria os planos resultantes. Foi muito mais rápido, mas alguns mini-pods tinham o mesmo problema de uma pessoa andando enquanto o outro fazia o trabalho no design.

  3. Ignora a divisão da tarefa. Decidimos que nossos pontos de história tinham uma média, 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 foi algo que nossos pares tiveram que fazer por si mesmos quando começaram um ingresso. Se os juniores estiverem trabalhando em um ingresso, espere que eles precisem de ajuda para superar essa etapa. Se você tentar isso, aceitou menos histórias no sprint até se sentir confortável com isso. Além disso, certifique-se de que é "seguro" para seus companheiros de equipe pedir ajuda quando eles não souberem de algo.

No final, tudo se resume à maturidade da equipe. As pessoas precisam entender as habilidades e preferências de cada um e ter confiança de que os colegas de equipe irão pedir informações quando precisarem. Corrija os primeiros, se você não os tiver. Em seguida, resolver o problema de reuniões ineficientes fica mais fácil.

    
por 10.08.2018 / 21:30
fonte
3

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

A programação em pares ajudaria (1) ensinando alguns de seus programadores juniores a escrever um código melhor e (2) em programação em pares, nem sempre é necessário 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 feitas "espontaneamente" com os benefícios da programação de pares adicionais.

Se você puder ajudar seus programadores júnior a aprender mais rápido 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á motivo para que você não seja capaz de reduzir o tempo você gasta no futuro Planejamento da Sprint

    
por 11.08.2018 / 00:25
fonte
1

Eu não sou um aficionado por scrum e só tenho cerca de um ano de experiência prática. Então, o seguinte deve ser lido com um grão de sal.

Eu vejo várias bandeiras vermelhas no que você escreve:

5 horas de planejamento da sprint

Isso é muito longo para uma corrida de uma semana.

O objetivo do planejamento do sprint é o AFAIR para

  • permite 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 items , o backlog precisa estar em boa forma.

Na fase de planejamento concreto, os Product Backlog items são transformados em Sprint Backlog items .

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

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

Discuta muito detalhadamente no planejamento da sprint

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

Por outro lado: o planejamento do Sprint espera um comportamento profissional de cada participante. Isso inclui evitar discussões de bikeshedding .

Talvez as coisas estejam claras, mas alguém começa uma discussão bikeshedding .

Mais: evite discussões sobre detalhes de implementação . Embora todas as ideias acabem em código em algum momento, não é o ponto do planejamento do sprint discutir se um array simples fará o truque, ou será melhor usar uma lista vinculada.

As most of team members are not senior

No scrum não há distinção entre senior e junior . Ambos são apenas desenvolvedores. E este é um bom ponto de partida, o que ajuda você a manter sua discussão focada em uma solução viável apoiada pelos melhores argumentos e não pelo contracheque.

Erros de implementação e redesenho durante o sprint

Parece haver um problema fundamental na coleta de requisitos, seguido por um backlog de produto muito vago.

Como eu disse acima: Enquanto o Product Backlog estiver em boa forma, será difícil perder o ponto.

Eu não consigo imaginar uma situação como:

»Como usuário, quero ver um punhado de clientes!«

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

OTOH: O que, nesse contexto, redesenhar significa? Se um desenvolvedor escolheu um algoritmo de execução lento , então a próxima meta é clara: escolha um melhor desempenho. Mas isso não é "redesenho", isso é uma otimização.

Para suas principais perguntas:

How to deal with this?

É trivial mencionar, mas eu faço de qualquer maneira: Não se esqueça, que você está lidando com humanos .

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

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

Um efeito colateral da iteração é que os números de certas tarefas irão aumentar (porque a equipe tem uma compreensão de suas capacidades e das complexidades ocultas). Depois, há a chance de dividir o item em vários itens menos complexos, com menor complexidade.

How much detail should I discuss during planning to fit 2 hours long per a week sprint?

Resposta salomônica: O menos possível e o quanto for 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

  • Melhore a coleta de requisitos

  • Melhorar o registro posterior

  • Aumente a confiança dos membros da equipe em seus recursos individuais, bem como suas capacidades como equipe

  • Evite o uso de bicicletas

  • Melhore a disciplina pessoal

  • Talvez use timeboxes fixas para cada item para discutir

  • Fortalecer a posição do scrum master para moderar de forma eficaz.

por 10.08.2018 / 18:41
fonte
-2

Conseguimos reduzir muito o tempo de reunião de planejamento, fazendo um total de três horas em sprints de duas semanas. Nós dividimos o aliciamento em quatro sessões. fazemos 30 minutos na segunda e 1 hora na quarta 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 entrada para o planejamento, o que o torna mais curto. Nosso melhor recorde 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. Ainda é tempo de caixa de qualquer maneira, mas o planejamento foi feito muito cedo.

    
por 22.11.2018 / 23:04
fonte