Quanto tempo deve durar uma reunião de planejamento de sprint?
16
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.
8 horas por um sprint de 10 dias definitivamente parece demais para mim. Discussões que não exijam toda a equipe devem ser realizadas em sessões separadas, apenas para os membros envolvidos.
Péter Török
1
Então você planeja outras reuniões em vez de discutir tudo no planejamento. Ponto anotado.
wleao 13/09/11
As discussões devem acontecer sobre as próximas idéias e planos, para que a maioria dos membros da equipe tenha algum entendimento básico e compartilhado sobre eles. O critério é o seguinte: durante a reunião de planejamento, ninguém deve se surpreender por ouvir uma certa coisa pela primeira vez. Sempre que essa "surpresa" acontecer, ajuste-a aumentando a quantidade de comunicação que ocorre antes da próxima reunião de planejamento. (As exceções a esta são verdadeiramente inovador anúncios provenientes de proprietários do projeto.)
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.
Esse é provavelmente um bom ponto de partida, mas também é preciso observar que você precisa adaptar o processo ao seu projeto, equipe e organização para que funcione para você. Só porque outras pessoas tiveram sorte com isso, não significa que funcione para você imediatamente.
Thomas Owens
6
No entanto, se você quiser experimentar o Scrum, provavelmente deve experimentá-lo com base nas diretrizes definidas primeiro. Então, se algo não estiver funcionando, refine-o. Se você mudar as regras antes mesmo de começar, estará desconsiderando as evidências empíricas que levaram as pessoas que criaram o Scrum a recomendar o que recomendavam - sem nenhuma evidência empírica para mostrar que isso é errado para você.
Matthew Flynn
@MatthewFlynn good point
HA
Na minha equipe de 3, geralmente tínhamos apenas meia hora de sprints e, quando a equipe tinha 7 anos, geralmente eram apenas uma hora para duas semanas de sprints.
Zymus 12/03
27
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.
Uma hora parece um pouco curta para 3 desenvolvedores / 1 semana de corrida. Então, novamente, acabei de terminar um projeto relativamente pequeno, onde fizemos um planejamento semanal de 5 minutos. Depende do projeto e das cartas, porque às vezes é necessária mais (ou menos) discussão durante o planejamento do sprint.
configurator
2
Uma das idéias principais do Scrum, como uma estrutura Agile, é que você <i> cronometra atividades </i>, como o sprint, a reunião de planejamento do sprint e o stand-up / scrum diário. O objetivo é manter as coisas focadas. Time boxing não significa que você não pode levar menos tempo do que o designado. Só que você não deve demorar mais, pois isso tende a fazer as pessoas perderem o foco e também reduz a quantidade de tempo que a equipe tem para realizar o trabalho.
Matthew Flynn
7
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ê.
Por que não iniciar o processo como projetado e adaptar a partir daí? Se você decidir usar práticas ágeis e não moldou seus negócios nessa direção, você já está com problemas.
JeffO 18/03/16
3
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.
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.
@GottliebNotschnabel: Obrigado, isso é novo. Mudei o link para um que não requer login.
Hugo
2
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.
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.
Respostas:
De acordo com o Guia Scrum :
Isso geralmente funciona para mim.
fonte
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.
fonte
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ê.
fonte
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 ):
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.
fonte
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.
fonte
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.
fonte
De acordo com o Guia Scrum :
fonte