Nossas reuniões de planejamento de corrida não são apenas divertidas, elas são terrivelmente terríveis.

As reuniões são tediosas, chatas e duram uma eternidade (um dia, mas parece muito mais tempo).
Os desenvolvedores reclamam e temem os próximos planos.

Nossa rotina é bastante padrão (a história do usuário inserida no backlog do sprint por prioridade >> é desmontada para tarefas >> tarefas são estimadas em horas >> repetidas), e não consigo entender o que estamos fazendo de errado.

Como podemos tornar as reuniões mais agradáveis?

...

Mais alguns detalhes, em resposta a pedidos de mais informações:

Por que os itens da lista de pendências não são inseridos e priorizados antes do início do sprint?

As histórias de usuários são realmente priorizadas; não temos idéia de quanto tempo eles levarão até dividi-los em tarefas! Das (excelentes) respostas aqui, vejo que talvez não devamos estimar tarefas, apenas as histórias de usuários. A razão pela qual estimamos tarefas (e não histórias) é porque estamos enganando as estimativas de histórias terrivelmente - mas acho que esse é o assunto de uma questão completamente diferente.

Por que os desenvolvedores estão reclamando?

1. As reuniões são longas.

2. As reuniões são monótonas. História após história, tarefa após tarefa, lutando (sim, lutando) para estimar quanto tempo levará e o que isso envolve.

3. A estimativa de tarefas faz com que a estimativa da história do usuário pareça inútil.

4. Quanto mais longa a reunião, menos foco na sala. Quanto menos focados os colegas, mais tempo leva a reunião. Uma espiral de ódio recursiva se desenvolve. Consideramos dividir a reunião em dois dias para manter as pessoas focadas, mas os desenvolvedores não ouviram falar. Um dia de planejamento já é ruim o suficiente; agora teremos dois ?!

Parte do nosso problema é que entramos em detalhes muito pequenos (para obter estimativas mais precisas). Mas quando estimamos mais ou menos, saímos da moda!

Para resumir a pergunta:

• O que estamos fazendo errado?

• Que maneiras adicionais existem para tornar a reunião geralmente mais agradável?

Facilitar a estimativa

Divida seu planejamento de sprint.

Você precisa estimar as tarefas individuais? Eu fiz o sprint planejando de duas maneiras:

1. As histórias são estimadas em pontos da história e as tarefas são estimadas em horas
2. As histórias são estimadas em pontos da história e as tarefas simplesmente se enquadram nessa, sem estimativa

Dos dois, eu prefiro a segunda opção. Acho que não estimar tarefas dá mais liberdade aos desenvolvedores para lidar com as mudanças. Se uma tarefa não faz mais sentido (quantas vezes você descobriu que uma tarefa não é aplicável ou já foi executada em um sprint anterior), basta jogá-la fora sem nenhuma penalidade ou poderá ser necessário alterar uma tarefa atual para algo novo, possivelmente terminando. Você está realmente sendo redundante se estimar as duas, pois a soma das tarefas deve representar os pontos da história e vice-versa. Que valor você realmente ganha com isso, além de saber quanto tempo as tarefas individuais levarão? Se você se deparar com tamanhos de tarefas que realmente variam o suficiente para fazer a diferença, sugiro dividi-las em pedaços menores e mais homogêneos.

Ao fazer isso, você pode reduzir o tempo gasto no planejamento do sprint . As histórias são estimadas durante o planejamento do sprint e, quando você inicia o sprint, pode anotar todas as tarefas que puder imaginar que compõem essa história. Obviamente, se há pontos que você encontra na estimativa da história que você sabe que precisam ser tratados em uma tarefa, você pode adicioná-la às informações da história e colocá-la como uma tarefa.

Estimativa em unidades ideais

Os pontos da história devem estar em unidades ideais , como horas de trabalho ideais ou dias de trabalho ideais. Isso significa que, dado o dia perfeito todos os dias, em que você não teve interrupções, reuniões e tudo correu conforme o planejado, você poderia realizar a tarefa em X dias. Agora todo mundo sabe que isso simplesmente não é verdade, mas o mais maravilhoso das estatísticas é que elas não precisam ser assim.

O que quero dizer com isso é que, depois de um tempo estimado em dias ideais, você percebe que talvez demore 25% a mais do tempo estimado em média para concluir uma história. Digamos que você tenha estimado 4 dias úteis de trabalho e, em vez disso, levou 5. Com o tempo, você acompanha e depois tem uma idéia aproximada da conversão de dias ideais para dias reais. Seu primeiro instinto seria tentar compensar isso superestimando, e você provavelmente estaria errado. A principal coisa aqui é permanecer consistente. Dessa forma, sua média de longo prazo permanece a mesma. Certamente, às vezes, fica abaixo e às vezes acaba, mas quanto mais você estima, melhor fica. Se você achar que ainda não é possível obter uma estimativa decente, talvez isso signifique que você não conhece o suficiente sobre a história para estimar adequadamente.

Fale sobre as histórias

Quando você estima, todos devem ter uma idéia aproximada do que precisará ser feito, do início ao fim, do que será necessário para que essa história seja concluída. Você não precisa conhecer todos os detalhes, mas o suficiente para pensar que poderia empreender a história. Se você não tem esse nível de confiança, provavelmente não deveria estar estimando-o. Se você disser "Bem, essa história é muito grande para que possamos conhecer a maioria dos detalhes", isso é uma indicação de que a história é muito grande e deve ser detalhada. As histórias, pelo menos na minha experiência, foram pequenas o suficiente para que uma pessoa, se necessário, pudesse trabalhar sozinha e realizá-la dentro de uma semana ou duas.

Isso também ajudará a resolver seu segundo ponto na edição, que é uma estimativa demais . Em vez de estimar cada tarefa para cada história, basta estimar a história como um todo, o que deve ajudar a remover muitas estimativas. Quanto a tornar as reuniões menos monótonas, sugiro planejar o poker, sobre o qual você pode ver mais informações acima.

Tornar o planejamento mais envolvente

Faça uma estimativa usando o Planning Poker

Quanto a tornar a estimativa mais divertida, você já tentou planejar o poker ? É o jeito que eu sempre planejei todos os meus sprints em várias equipes, e é uma boa maneira de manter todos envolvidos, pois cada pessoa precisa pelo menos escolher ALGO. Também há muita diversão envolvida quando todos na equipe escolhem 3, e alguém coloca um 20 e precisa se explicar, ou quando todos no time colocam um 5, mas o gerente coloca um 8 (quem vai discutir com o chefe quando ele quiser lhe dar mais tempo!).

Para fazer isso, tudo o que você precisa é de um planejamento de cartas de pôquer , o que geralmente fazemos no verso das fichas de índice ou o uso de cartas de jogar normais com valores associados às cartas de face. Nada extravagante, e mantém todos focados. Lembre-se de que tentar realizar qualquer tarefa durante um dia inteiro (incluindo planejar o poker) afeta a produtividade. Muitos conjuntos de cartões vêm com um cartão de café por um motivo; se alguém estiver se sentindo esgotado, dê um tempo para a equipe recarregar e pegue quando todos estiverem novos!

Como alternativa aos cartões físicos , você também pode procurar cartões eletrônicos . Os benefícios reais aqui são rastreamento automatizado de resultados, rastreamento de histórias de usuários a serem estimadas e permite que todos mostrem seus cartões de uma vez para evitar "trapaceiros" (onde uma pessoa estima que é influenciada por outra devido à capacidade de ver seu cartão). Obviamente, isso exige que todos tenham um computador e a capacidade de se concentrar na tarefa em questão, portanto, use-o a seu critério.

1. Por que os itens da lista de pendências não são inseridos e priorizados antes do início do sprint? Perder tempo dos desenvolvedores não é divertido. Deixe seus líderes de equipe trabalharem com o proprietário do produto e o gerente de projetos alguns dias antes para priorizar as coisas. Isso vale para o planejamento de quem também está em cada equipe de sprint.

2. Por que está demorando um dia para dividir as coisas em tarefas? Se você tiver uma equipe de tamanho razoável (2 a 4 desenvolvedores, 0,5 a 1,5 pessoas de controle de qualidade por desenvolvedor, 1 a 2 misc), deverá ter 2 a 4 histórias de usuário neste sprint. Passe cerca de 30 minutos com o proprietário do produto esclarecendo os requisitos e, em seguida, mais ou menos 30 minutos para tarefas de aproximadamente 8 horas. Não insira as tarefas durante a reunião. Apenas concorde em equipe quais são as tarefas suficientes para que as pessoas sãs as entendam, quem é responsável por elas e quanto tempo elas devem levar. Concorde que "quanto tempo eles devem levar (incluindo testes)" se encaixa confortavelmente no sprint.

3. Se não é apenas dividir as coisas em tarefas, o que mais você está fazendo? Claro, as retrospectivas podem levar de 30 a 60 minutos, mas serão mais curtas quando as equipes entrarem em um ritmo.

Então, em resumo - pare de desperdiçar o tempo das pessoas e elas terão pavor das reuniões um pouco menos. Além disso, diversão e comunicação na equipe não são algo que você pode abordar nas reuniões. Vá almoçar juntos, brinque, misture as pessoas para se adaptarem melhor à personalidade, participe de concursos de crescimento de bigodes ... assim que o moral acabar, as pessoas naturalmente tornarão as reuniões de planejamento de corrida mais leves.

O planejamento é uma área do scrum em que as equipes têm muita flexibilidade. Tente algo novo a cada corrida até encontrar algo que funcione para sua equipe.

Algumas idéias bem-sucedidas que eu tentei pessoalmente ou ouvi de outras equipes:

• Crie a criação e priorização de histórias de usuários sem a equipe inteira. O proprietário do produto e / ou o mestre do scrum podem lidar com muito do trabalho ocupado e deixar a equipe ajustá-lo.
• Faça seu backlog significativamente mais longo que um único sprint. Pode levar algum tempo para desenvolvê-lo, mas se sua carteira de pedidos for longa o suficiente, as reuniões de planejamento serão reduzidas a fazer pequenos ajustes ou abordar desenvolvimentos comerciais recentes.
• Faça reuniões de estimativa separadas do planejamento do sprint. Se as pessoas pensam que as reuniões são longas demais, não há razão para não separá-las.
• Planeje especificamente quebras na agenda. Isso é útil se você estiver perdendo tempo esperando um ou dois membros da equipe retornar.
• Entre no meio da reunião e designe todos para elaborar uma ou duas histórias de usuário, depois se reúnam para relatar e obter consenso.
• Verifique se a sua reunião de planejamento é sobre o que fazer, não como fazê-lo. Os engenheiros se enquadram muito facilmente nesse último. Se necessário, organize reuniões de design separadas nas quais discuta o como.
• Separe suas histórias em investigação e implementação. As reuniões de planejamento costumam demorar demais quando os membros da equipe sabem muito pouco sobre o que irão trabalhar e tentam descobrir isso durante a reunião.
  Por exemplo, digamos que você precise se integrar a uma API com a qual sua equipe não tem experiência. Em vez de tentar criar estimativas e tarefas durante a reunião de planejamento sobre algo que você não tem noção, crie uma história de investigação para aprender a API, faça um aplicativo simples "olá mundo" e ensine-o à equipe. Então você estará equipado para planejar o trabalho real.
• Acompanhe durante as suas reuniões questões específicas. Não apenas "o planejamento é chato", mas um nível de detalhe como "passamos muito tempo conversando sobre requisitos pouco claros e ninguém parece saber a resposta certa". Em seguida, discuta esses problemas específicos em suas retrospectivas e faça brainstorm para soluções específicas. Quebre seu problema até que as peças fiquem fáceis de resolver.

Mantemos nosso planejamento e retrospectiva de sprint ao mesmo tempo e quase sempre são realizados em 90 minutos, mas somos uma das equipes mais rápidas. Fazemos um grande planejamento de longo prazo para toda a empresa, a cada 5 sprints, que leva de 4 a 6 horas. Cada equipe é diferente, é claro, mas se você passa um dia inteiro a cada corrida, há muito espaço para melhorias.

Suas sessões de planejamento são longas demais!

Com base na minha experiência, uma reunião de planejamento de sprint não deve demorar mais de 2 horas por semana sendo planejada (por exemplo, um sprint de 2 semanas deve levar no máximo 1/2 dia), mas as bem-sucedidas devem ser mais curtas que isso (metade).

No seu caso particular: por que você está estimando tarefas? Você deve estimar apenas histórias durante o planejamento. As tarefas podem ser estimadas posteriormente pelos proprietários de tarefas específicas .

Uma maneira que funcionou para mim:

• Introdução rápida ao sprint pelo PO
• Estimativa da capacidade de sprint
• Histórias acabam e planejam pôquer (com caixa de tempo de 5/10 minutos por história) até que haja material suficiente estimado para cobrir o sprint
• Compromisso / previsão oficial da equipe

Em seguida, em paralelo / pares / auto-organizado em nossas mesas, tarefas e estimativa de tarefas.

No meu trabalho anterior, o primeiro dia inteiro de cada sprint (nós os chamamos de iterações lá) foi tratado com:

• Retrospectivo. Começamos fazendo isso na tarde do último dia, mas frequentemente nos vimos retrospectivamente sobre o sprint e depois voltamos ao trabalho amarrando as últimas pontas soltas do trabalho desse sprint, então achamos que seria melhor garantir que o sprint o trabalho ficou para trás antes de analisá-lo. Também parecia lógico consolidar todas as despesas gerais da reunião do processo Scrum, para que os outros dias pudessem ser planejados e gastos em termos mais ideais. Isso normalmente leva 2 horas.
• Planejamento de Sprint. A lista de pendências foi estimada durante uma Reunião de Planejamento por Marcos (que poderia ser um dia inteiro para os Devs e POs) e tinha sido priorizada pelas POs antes do início de cada sprint. Descobrimos quantos dias de desenvolvedor tínhamos disponíveis (contabilizando feriados, vacas, etc.), pegamos o trabalho que pensávamos que poderíamos fazer do topo da pilha e revisamos rapidamente os requisitos do usuário (previamente examinados por nossos BAs) para tenha uma noção mais completa do que o trabalho envolveu do que obtivemos com a simples visão geral durante o MPM. Isso normalmente levava mais 2 horas.
• Planejamento de tarefas. Conhecendo as histórias e os critérios de aceitação, dividimos cada história em tarefas mínimas estimadas em horas ideais (uma hora gasta focada apenas em concluir a tarefa sem distrações ou obstáculos). Da maneira como nossa escala de pontos acabou sendo calibrada, um 5 era um sprint de desenvolvedor, então um 1 poderia ser qualquer coisa, incluindo até dois dias de desenvolvedor. Por esse motivo, praticamente tudo teve que ser dividido para que os membros da equipe pudessem mostrar progresso no quadro de scrum. Este foi outro bloco de duas horas, com algumas sugestões entre este e o próximo item.
• AAT Outlining. Nossos POs e BAs não eram programadores e não codificavam. As OPs se ocultaram atrás de um contrato estipulando que entregariam requisitos na forma de um modelo do Word e trabalhariam com as BAs para refiná-las dessa forma. Os BAs entendiam o código, mas seu tempo era puramente análise e teste final (que exigia a existência do sistema, para que eles pudessem gravar suas macros no Selenium). Portanto, para verificar se nosso código atenderia aos critérios de aceitação, tivemos que escrever nossos próprios AATs modelando as ações do teste de aceitação "em papel". Normalmente, fizemos isso na mesma estrutura do NUnit que usamos para testes de unidade e integração (experimentamos o FitNesse e não conseguimos desistir com rapidez suficiente). Este foi o resto do nosso primeiro dia de cada corrida e continuou no segundo.

No meu trabalho atual, ainda estamos adotando o processo Scrum, não tínhamos um planejamento de metas para toda a equipe e muito do que estamos trabalhando não possui critérios rígidos de aceitação. Portanto, nosso planejamento de sprint é uma explicação do que cada história implica e do que chamaremos de feito, além de ser um compromisso de aproveitar as X horas ideais de trabalho. Nós nos damos bem com isso - pelo menos por enquanto - porque somos uma equipe interna e cada um de nós trabalha pessoalmente com os usuários finais de nosso software para reunir requisitos e projetar soluções. Mesmo assim, o planejamento do sprint é realizado durante toda a manhã toda segunda-feira, e a tarde é gasta limpando todos os obstáculos pessoais para poder iniciar o desenvolvimento de verdade na terça-feira.

Para realmente responder à pergunta do OP em vez de contrastar com outros comentários / respostas dizendo que não deve demorar tanto, existem maneiras de abordar a estimativa ágil, o planejamento de sprints e as retrospectivas um pouco mais interessantes do que você pode estar usando.

Abordando especificamente suas preocupações:

• As reuniões são longas - cronometre-as. Cada reunião, seja uma retrospectiva, planejamento de sprint, divisão de tarefas, etc., deve ter um objetivo e um tópico definidos de discussão e deve ser limitada, tanto quanto possível, a um determinado período de tempo. O trabalho do Scrum Master é manter essas reuniões no tópico e avançar para cumprir as metas de tempo.

• As reuniões são monótonas - haverá algumas delas; você está trabalhando em pedaços pequenos, um de cada vez, para fazer a mesma coisa repetidamente. Manter a equipe focada e direcionar para a realização do objetivo da reunião ajudará.

  Outra coisa que ouvi é que talvez suas reuniões de planejamento de sprint estejam tentando realizar demais. Na minha última empresa, a estimativa da história foi feita em "reuniões de planejamento de marcos", que aconteciam cerca de uma vez por trimestre e duravam o dia todo. Nessas reuniões, tudo o que havia acumulado na lista de pendências que não tínhamos estimado era estimado em pontos. Se você estiver fazendo uma estimativa de histórias em pontos e depois uma estimativa de tarefas em horas, não deseja fazer as duas coisas ao mesmo tempo (talvez no mesmo dia).

• Estimar histórias em pontos e tarefas em horas parece redundante - elas têm dois propósitos diferentes. O objetivo da estimativa de história é fornecer uma estimativa aproximada da complexidade, que você pode usar para preencher o backlog do sprint com base na velocidade passada e na largura de banda esperada. O objetivo da estimativa de tarefas é dividir as histórias em itens que demoram um dia para o desenvolvedor ou menos (e, portanto, podem ser atribuídos a um único indivíduo que se espera que tudo seja feito a tempo) e garantir que você não tenha calculou erroneamente a complexidade de qualquer história e não mais do que você pode mastigar no sprint.

  Se todas as suas histórias durarem um dia ou menos, será redundante, mas nem todas as escalas de pontos são calibradas igualmente; no meu último trabalho, cinco eram duas semanas de desenvolvedor (porque, no início, tínhamos muitos épicos para estimar), o que em uma escala linear fazia sentido até 2 dias de desenvolvedor. Dado esse tipo de escala, praticamente tudo deve ser dividido em tarefas. Na minha nova empresa, um ponto está mais próximo da metade de um dia de desenvolvedor, então um 1 ou mesmo um 2 é definitivamente sua própria tarefa, e 3-8 é nebuloso em relação a forçar a equipe a dividi-lo em tarefas.

• Há um ciclo vicioso que leva mais tempo, tornando as pessoas menos focadas, por isso leva mais tempo - Time-box seu tempo Faça pausas, como você deve fazer ao codificar. A cada 30 minutos, dedique 5 minutos para esticar as pernas, reagrupar etc. Você pode fazer dez minutos a cada hora, mas não force demais o tempo de reunião. Seu pessoal pode estar com fome, ou precisar de mais café, ou de um banheiro, etc. Não os negue; se você fazê-los chupar, verá as mentes deles vagando. Além disso, manter as discussões curtas, doces e objetivas também ajudará, como mencionado anteriormente.

A reunião de planejamento da Sprint possui 2 partes:

1. Decida o que a equipe fará
2. Decida como a equipe fará isso.

A primeira parte é relativamente direta - com base no número de pontos da história que a equipe acha que pode assumir, o compromisso de concluir muitas histórias de usuários em sua ordem de prioridade. Feito.

A segunda parte é do que os desenvolvedores realmente devem gostar - elaboração da história e design da solução. As tarefas caem fora disso. Portanto, peça ao proprietário do produto ou a qualquer PME que ele forneça que explique a história escolhida. Em seguida, peça ao desenvolvedor que deseje assumir a liderança da discussão sobre design. Use um quadro branco. Rejeite idéias. Diverta-se.

É isso mesmo. Se as reuniões de design não são divertidas, então há algo errado.

Sim, eu sei que essa é uma pergunta antiga, mas tenho uma nova resposta. : P

Divida a reunião.

Dividimos nossa reunião de planejamento da Sprint em três mini-reuniões separadas

• Preparação da lista de pendências
• Seleção de história
• Divisão de tarefas

Fazemos cada um em um dia diferente, logo após o Scrum diário - assim que o diário é concluído, entramos diretamente na atividade de planejamento e, depois, ficamos livres de reuniões (planejadas regularmente) pelo resto do dia.

Então sim, nós planejamos nosso planejamento: -O

Entrarei em mais detalhes sobre o que está envolvido em cada sessão em um segundo, mas deixe-me explicar como chegamos a isso.

Nós, como você, tivemos um problema com reuniões de planejamento realmente pavorosas da Sprint. Tínhamos todos os elementos certos, mas tudo levou uma eternidade e foi realmente desgastante mental e emocionalmente.

Depois, tive essa ideia depois de ler este artigo do Business Insider no diário de cinco minutos da Pivotal sobre dividir nossas reuniões em sessões mais curtas e fazê-las no início de cada dia.

Eu falei com a equipe em uma retrospectiva. Alguns membros da equipe gostaram imediatamente, outros ficaram um pouco apreensivos, mas nosso estagiário mencionou um estudo que ele leu sobre a técnica de pomodoro e começou a falar sobre ela, o que realmente ajudou a idéia a ganhar força.

Então, decidimos tentar.
Dividimos nossa reunião de duas horas em três sessões de 25 minutos. (sim, isso é matemática confusa, mas todo mundo achou que nossas reuniões eram longas demais e só queriam fazer isso se economizássemos tempo).

E funcionou! Estamos fazendo isso há cerca de 6 semanas em dois projetos separados (6 corridas de duas semanas no total) e isso fez muita diferença.
Nós somos mais produtivos. Economizamos muito tempo.
Temos melhores resultados. E não temos mais medo de nossas reuniões de planejamento.

E, honestamente, nosso tempo de 25 minutos é bastante flexível - algumas sessões são muito rápidas, como 5 a 10 minutos em algumas de nossas sessões de preparação e outras demoram muito, como quando acabamos identificando novas histórias ou precisando desmembrar histórias e reestimar durante a negociação. No geral, no entanto, geralmente fica em média não mais de 1,5 horas para toda a conversa, e acho que é por isso que funciona tão bem.

Para os detalhes .....

Preparação da lista de pendências

Muito simples - analisamos as histórias de maior prioridade, falamos sobre o que elas envolvem e garantimos que nossas estimativas sejam boas.

Reestimaremos as histórias, se necessário - como, por exemplo, estimamos algo há alguns meses e, depois de percebermos o que uma história semelhante realmente levou, podemos concordar em reestimar. ( a propósito, usamos pontos de história sem unidade e não estimamos tarefas ).

Além disso, se o PO tiver adicionado novas histórias que julgar serem de alta prioridade, este é o momento de calculá-las.

Como não fazemos a seleção de matérias até o dia seguinte, esse processo dá ao OP um tempo extra para fazer um julgamento final sobre o que é mais importante a ser feito na próxima iteração - e isso se mostrou muito útil.

Essa reunião tende a ficar curta com algumas organizações de produtores e longa com outras. (pessoalmente, acho que é um ótimo indicador de cheiro de como está seu PO)

Seleção de História

Coloque seu Chris Voss , é hora de negociar.

Nesta reunião, pegamos as principais histórias de prioridade e definimos um Departamento de Defesa para cada uma. Negociamos o que cada um deles implicará - dividindo e combinando histórias, conforme necessário - até que todos possamos concordar com nossos objetivos da Sprint.

Nós nos beneficiamos muito de ter uma mente renovada e aquela energia de bom dia para esta reunião - e saber que faremos tarefas outro dia nos permite gastar o tempo necessário para realmente negociar bem e entender nossos compromissos.

Tarefas

Ok, então eu vou ser o primeiro a dizer, tarefas era meu MENOS parte favorita do planejamento em nossas antigas reuniões de um dia.

Nós nunca chegamos a esse ponto. Tentamos salvar tarefas até o final da reunião - mas estávamos todos esgotados até então e foi realmente improdutivo. Tentamos definir tarefas ao mesmo tempo que o nosso Departamento de Defesa durante a negociação, mas achamos isso muito perturbador e complicado - nos queimaríamos antes de selecionar todas as histórias. Além disso, era realmente difícil continuar alternando o foco / pensamento entre estimativa, negociação, seleção de histórias e geração de tarefas. Nós lutamos, e isso foi péssimo, e isso tornou nossas reuniões terríveis.

Mas agora, definindo o Departamento de Defesa em um dia, e não realizando tarefas até o dia seguinte, não nos cansamos, estamos sempre no estado mental certo, e isso nos dá um dia inteiro para refletir sobre a história e realmente pense e compreenda todas as tarefas antes de começarmos.

Isso por si só, IMHO, é um divisor de águas total.

Juntando tudo.

Então, aqui está como é o nosso calendário de cerimônias da Sprint agora:

• Segunda-feira - Daily scrum -> Sprint review
• Terça - Scrum diário -> Preparação de pedidos em atraso
• Quarta-feira - Daily scrum -> Seleção de matérias
• Quinta - Scrum diário -> Tarefas
• Sexta-feira - Scrum diário -> Retrospectiva

Funcionou muito bem para nós. Se você tentar, eu adoraria ouvir o que você pensa.

Estamos fazendo um sprint semanal com uma reunião de uma hora, na qual discutimos o sprint anterior, o que resta fazer e depois prosseguimos para o planejamento da próxima semana. Tudo dentro de uma hora.

Isso é claro, porque descobrimos que, no nosso caso, seguir o scrum de maneira muito rigorosa apenas desperdiçaria muito tempo. Isso ocorre porque a maioria das histórias já é discutida com os membros da nossa equipe quando o solicitante cria a história do usuário.

Só estou dizendo que se sua equipe tem medo de planejar reuniões, você provavelmente deve deixar de lado algumas das "regras" do scrum.

Esta pergunta foi respondida de forma abrangente, mas apenas uma coisa é necessária para fazê-la funcionar e ser divertida.

Dê poder à equipe. - ou seja, torná-los trabalhar em coisas que eles acham que são o mais importante.