Quanto tempo deve durar uma reunião de planejamento de sprint?

Na sua experiência, quanto tempo deve durar uma reunião do Sprint Planning (Scrum)? 8 horas? Ou deve ser mais curto (sucinto) e discussões adicionais devem ser planejadas como parte do sprint? Nossos Sprints duram 10 dias.

De acordo com o Guia Scrum :

A Reunião de Planejamento da Sprint tem um prazo de oito horas para uma Sprint de um mês. Para Sprints mais curtos, o evento é proporcionalmente mais curto. Por exemplo, as Sprints de duas semanas têm reuniões de planejamento da Sprint de quatro horas.

Isso geralmente funciona para mim.

Contanto que ele precise durar, nem menos e nem mais. Qualquer outra coisa não é ágil.

Se você tem uma equipe de 2 a 3 desenvolvedores e está fazendo sprints de 1 semana, qualquer coisa superior a uma hora provavelmente é contraproducente.

Se você tem uma equipe de 15 pessoas e sprints de 2 semanas, está procurando o dia todo, menos que isso não seja detalhado o suficiente.

É preciso experiência para acertar na maioria das vezes, e é para isso que servem as retrospectivas, a equipe decide o que é muito longo ou muito curto.

Não se preocupe em aperfeiçoar ou seguir o que alguns livros dizem, tente algo e refine-o.

O SCRUM é sobre refinar o processo nas iterações, assim como é sobre refinar o seu código nas iterações.

Não modele seus negócios em torno do processo. O processo suporta seus negócios. No momento em que você está processando por si só, é hora do processo pegar o machado. Para esse fim, não há um caminho "certo". As reuniões devem durar apenas enquanto você estiver realizando algo nelas. Se você demorar 30 minutos ou 4 horas, contanto que funcione, siga em frente. Ignore o que algum livro / blog / coach diz e faça o que é certo para você.

Demore o tempo necessário para selecionar o suficiente para que sua equipe considere que eles podem alcançar razoavelmente no sprint. Mas você deve passar um tempo durante o sprint (anterior) refinando a lista de pendências: estimando e refinando histórias.

Do Scrum Primer ( PDF ):

Refinamento do backlog do produto

Uma das diretrizes menos conhecidas, mas valiosas, no Scrum é que cinco ou dez por cento de cada Sprint devem ser dedicados pela Equipe a refinar (ou "preparar") o Backlog do Produto. Isso inclui análise detalhada de requisitos, dividindo itens grandes em itens menores, estimativa de novos itens e re-estimativa de itens existentes. O Scrum não fala sobre como esse trabalho é realizado, mas uma técnica usada com frequência é um workshop focado próximo ao final do Sprint, para que o time e o proprietário do produto possam se dedicar a esse trabalho sem interrupção. Para uma Sprint de duas semanas, cinco por cento da duração implica que cada Sprint exista um workshop de Refinamento de Backlog de Produtos por meio dia. Esta atividade de refinamento não é para itens selecionados para o Sprint atual; é para itens para o futuro, provavelmente nos próximos um ou dois Sprints. Com essa prática, o Sprint Planning se torna relativamente simples porque o Product Owner e a Scrum Team iniciam o planejamento com um conjunto de itens claro, bem analisado e cuidadosamente estimado. Um sinal de que este workshop de aprimoramento não está sendo realizado (ou não está sendo realizado bem) é que o Planejamento da Sprint envolve perguntas significativas, descobertas ou confusão e parece incompleto; o trabalho de planejamento geralmente se espalha pelo próprio Sprint, o que normalmente não é desejável.

Fazer isso significa que você pode se concentrar no planejamento durante o planejamento, e isso não leva o dia todo e a equipe começa a perder o foco e a ficar entediada.

No Scrum, ao trabalhar com sprints de 2 semanas, o planejamento do sprint é realizado em 4 horas, tornando-o um evento de meio dia. Uma razão para a quantidade relativamente grande de tempo é que a equipe de desenvolvimento deve poder concordar com confiança que todos os itens inseridos no backlog do sprint podem ser entregues, o que significa que precisam conhecer os detalhes. Não é incomum, como parte do planejamento do sprint, que as equipes se separem do espaço da reunião por períodos de tempo, a fim de investigar mais os itens e garantir que eles estejam "prontos" para entrar no backlog do sprint. (Pode ajudar a pensar no planejamento do sprint como um evento, e não como uma reunião.)

Use sua "Definição de Pronto" e o período de tempo que o evento de planejamento do sprint permite para garantir que todos os itens de backlog que entram no sprint estejam viáveis e prontos . ou seja, eles podem ser feitos (completamente, conforme a "Definição de Concluído") dentro do sprint, e há informações suficientes para que a equipe possa executá-las agora.
É claro que você provavelmente não deseja fazer isso para TODOS os itens durante o planejamento do sprint, pois isso pode consumir muito tempo. Tente fazer uma limpeza regular da lista de pendências (com planejamento de sprint), onde você pode detalhar itens da lista de pendências e estimar itens ainda não estimados usando o planejamento de pôquer, por exemplo. (Descobri que essa pode ser uma atividade eficaz para um jantar de trabalho com a equipe de desenvolvimento, caso você tenha o luxo da disponibilidade da sua equipe na hora do jantar!)

Itens de alta prioridade geralmente podem ser adicionados ao backlog do produto pelo proprietário do produto imediatamente antes do planejamento do sprint e, embora a rotina de limpeza do backlog possa, e normalmente deva ser feita antes do evento de planejamento do sprint, sempre haverá novos itens como este onde a equipe precisa dedicar algum tempo trabalhando nos detalhes e estimando a complexidade durante o evento de planejamento do sprint, daí o motivo pelo qual pode se estender para 4 horas por 10 dias / 2 semanas.

Se você precisar prolongar discussões deste evento, poderá ter um item de lista de pendências na lista de pendências do sprint para "ter tal e tal discussão para estabelecer x", mas evite incluir itens de sprint para fazer o que quiser determine as necessidades feitas durante essa discussão, pois esses itens não estão "prontos" para pendurar no sprint.

Como as pessoas disseram, há razões pelas quais você pode querer mudar a maneira como executa o Scrum, se o processo não estiver funcionando efetivamente para você. No entanto, o Scrum é uma estrutura muito bem pensada e testada, para garantir que o seu raciocínio seja justificado antes de alterar o processo.

Na reunião de planejamento da Sprint, a equipe precisa determinar dois conjuntos de coisas:

A) O que será desenvolvido pela equipe durante este Sprint

B) Como será desenvolvido

Esta reunião deve ter o tempo definido, até duas horas para cada semana do Sprint, dividida igualmente para cada parte (parte A e Parte B) da reunião.

Portanto, por um Sprint de 4 semanas, essa reunião não deve exceder 8 horas, até 4 horas para a parte A e até 4 horas para a parte B.

Durante a parte A, a equipe de desenvolvimento deve estimar a velocidade da equipe que eles consideram ter durante este Sprint. Eles também precisam estimar as histórias de usuários com prioridade máxima e escolher um número suficiente dessas histórias (já estimadas) para concluir de acordo com a velocidade estimada da equipe.

Na parte B, a equipe de desenvolvimento discutirá como desenvolver as histórias de usuário mais desafiadoras já selecionadas para serem desenvolvidas. Provavelmente, a equipe de desenvolvimento não terá tempo suficiente para discutir como desenvolver todas as histórias de usuário selecionadas; portanto, a equipe deve escolher as histórias de usuário mais desafiadoras.

Durante o Sprint, a equipe de desenvolvimento tem tempo suficiente para concluir esta discussão.

De acordo com o Guia Scrum :

Eventos Scrum

Eventos prescritos são usados ​​no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são de tempo definido, de modo que cada evento tenha uma duração máxima. Depois que um Sprint começa, sua duração é fixa e não pode ser reduzida ou prolongada. Os eventos restantes podem terminar sempre que o objetivo do evento for alcançado, garantindo uma quantidade adequada de tempo gasto sem permitir desperdício no processo.