Pergunta

Não são apenas nossas reuniões de planejamento de sprint não divertidas, elas são francamente terríveis.

As reuniões são tediosas e chatas, e levam para sempre (um dia, mas parece muito mais).
Os desenvolvedores reclamam sobre isso, e temia os próximos plannings.

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

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

...

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

por que os itens do backlog não estão inseridos e priorizados antes do Sprint Showoff?

As histórias de usuários são de fato priorizadas; Não temos ideia de quanto tempo eles levarão até que os quebramos em tarefas! Das respostas (excelentes) aqui, vejo que talvez não devemos estimar tarefas, apenas as histórias do usuário. A razão pela qual estimamos tarefas (e não histórias) é porque estamos recebendo estimativas de história terrivelmente erradas - mas acho que é o assunto para uma pergunta 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 envolve.

  3. As tarefas estimativas tornam a estimativa da história do usuário parecem inúteis.

  4. Quanto mais a reunião, menos foco na sala. Os colegas menos focados são, quanto maior a reunião leva. Uma espiral de ódio recursiva se desenvolve. Consideramos dividir a reunião em dois dias, a fim de manter as pessoas focadas, mas os desenvolvedores não ouviram falar disso. Um dia de planejamento é ruim o suficiente; Agora vamos ter dois !

    5. Parte do nosso problema é que entramos em detalhes muito pequenos (a fim de obter estimativas mais precisas). Mas quando estimamos aproximadamente, ficamos fora da marca!

    para resumir a pergunta:

    • O que estamos fazendo errado?

    • Quais formas adicionais existem para tornar a reunião geralmente mais agradável?

Foi útil?

Solução

Tornar a estimativa mais fácil

.

quebrar o seu sprint planejando.

Você precisa para estimar as tarefas individuais? Eu fiz Sprint Planejando duas maneiras:

    .
  1. Histórias são estimadas em pontos de história e, em seguida, as tarefas são estimadas em horas
  2. histórias são estimadas em pontos de histórias e tarefas simplesmente caem sob isso sem estimativa

    3. Dos dois, prefiro a segunda opção. Eu acho que não estimar as tarefas dá mais liberdade para os desenvolvedores para lidar com as alterações. Se uma tarefa já não fizer sentido (quantas vezes você descobriu que uma tarefa não é aplicável ou já foi feita em Um sprint anterior) Você simplesmente joga fora sem qualquer penalidade, ou você pode ter que alterar uma tarefa atual em algo novo, possivelmente quebrá-lo. Você está realmente sendo redundante se estimar tanto, como a soma das tarefas deve representar os pontos da história e vice-versa. Qual valor você realmente ganha por isso, além de saber quanto tempo as tarefas individuais tomarão? Se você se encontrar com tamanhos de tarefas que realmente variam o suficiente para fazer a diferença, eu sugeriria quebrar essas tarefas em pedaços menores e mais homogêneos.

    Ao fazer isso, você pode reduzido no momento em que você gastar em Sprint Planning . As histórias são estimadas durante o planejamento da Sprint, e quando você inicia o sprint, pode abaixar todas as tarefas que você pode pensar que compõem essa história. Obviamente, se houver pontos que você se deparar na estimativa da história que você sabe terá que ser tratado em uma tarefa, você pode adicionar isso nas informações da história e colocá-la como uma tarefa. .

    Estimativa em unidades ideais

    Pontos de história destinam-se a ser Ideal unidades tais como horas ideais ou dias úteis de trabalho. Estes são destinados a significar que, dado o dia perfeito todos os dias, onde você não tinha interrupções, sem reuniões, e tudo corria de acordo com o plano, você poderia realizar a tarefa em dias x. Agora todo mundo sabe que isso simplesmente não é verdade, mas a coisa maravilhosa sobre as estatísticas é que não precisa ser.

    O que quero dizer com isso é que, depois de um tempo para estimar estes em dias ideais, você percebe que talvez seja necessário 25% do tempo que estimam em média para completar uma história. Vamos dizer que você estimou 4 dias de trabalho ideais e, em vez disso, levou você 5. Com o tempo, você acompanha isso e então você tem uma ideia aproximada da conversão dos dias ideais para os dias reais. Seu primeiro instinto seria tentar compensar isso por estima sobre a estimativa, e você provavelmente estaria errado. A principal coisa aqui é ficar consistente. Dessa forma, sua média de longo prazo permanece a mesma. Claro às vezes, vai ser baixo e às vezes acabará, mas quanto mais você estimar, melhor você é. Se você achar que você ainda pode ' T Tome uma estimativa decente, talvez isso signifique que você não conhece o suficiente sobre a história para estimar-a corretamente.

    falar sobre as histórias

    Quando você estimar, todos devem ter uma ideia aproximada do que precisarão ser feito, do começo ao fim, do que será necessário para que esta história seja completa. Você não precisa saber todos os detalhes, mas o suficiente que você pensa em você, poderia empreender a história. Se você não tem esse nível de confiança, provavelmente não deve estimando isso. Se você disser "Bem, esta história é muito grande para conhecer a maioria dos detalhes", então isso é uma indicação de que a história é muito grande e deve ser quebrada. Histórias, pelo menos na minha experiência, foram pequenos o suficiente para que uma pessoa, se necessário, poderia funcionar sozinha e realizá-la dentro de uma semana ou duas.

    Isso também ajudará a resolver seu segundo ponto na edição, que é Muita estimativa . Em vez de estimar cada tarefa para cada uma história, você simplesmente estimia a história como um todo, que deve ajudar a remover muita a estimativa. Quanto a fazer as reuniões menos monótonas, eu sugiro que planejasse o poker, que você pode ver mais informações sobre acima.

    Tornar o planejamento mais envolvente

    .

    Estimativa usando o Poker de Planejamento

    No que diz respeito a estimativa mais divertida, Você já tentou planejamento poker é o maneira que eu sempre fiz planejamento para todos os meus sprints em várias equipes, e é uma boa maneira de manter todos os envolvidos, pois cada pessoa tem que pelo menos escolher alguma coisa. Há também uma boa quantidade de diversão envolvida quando todos na equipe escolhe 3, e alguém abaixa 20 e tem que se explicar, ou quando todos na equipe derrubar um 5, mas o gerente abaixou um 8 (quem vai argumentar com o chefe quando ele quer te dar mais tempo!).

    Para fazer isso, Tudo que você precisa são alguns cartões de poker de planejamento , que muitas vezes fazemos no verso de cartões de índice, ou usando cartões de baralho normais com valores anexados aos cartões de rosto. Nada extravagante, e continua sempre

yone focado.Basta lembrar que tentando fazer qualquer tarefa por um dia inteiro (incluindo o Planning Poker) requer um pedágio em produtividade.Muitos conjuntos de cartões vêm com um cartão de café por um motivo;Se alguém está se sentindo queimado, dê uma pausa para a equipe para recarregar e pegá-lo quando todo mundo estiver fresco!

como alternativa a cartões físicos , você também pode olhar para Cartões eletrônicos .Os benefícios reais aqui são o rastreamento automatizado de resultados, rastreando histórias de usuários a serem estimadas e permitindo que todos mostrem suas cartas de uma vez para evitar "trapaça" (onde uma estimativa de uma pessoa é influenciada pelo outro devido a ser capaz de ver seu cartão).Obviamente, isso requer que todos tenham um computador e a capacidade de se concentrar na tarefa em mãos, portanto, use-a a seu próprio critério.

Outras dicas

    .

  1. por que os itens do backlog não estão inseridos e priorizados antes do Sprint Showoff? Desperdiçando o tempo dos desenvolvedores não é divertido. Deixe sua equipe liderar o trabalho com o proprietário do produto e o gerente de projeto alguns dias antes para priorizar as coisas. Isso vai para o planejamento que está em cada equipe de sprint também.

  2. Por que está demorando um dia para quebrar as coisas em tarefas? Se você tiver uma equipe de tamanho razoavelmente (2-4 desenvolvedores ,.5-1,5 qa pessoas por desenvolvedor, 1- 2 Misc) Então você deve ter 2-4 histórias de usuário este sprint. Passe 30 minutos ou mais com o proprietário do produto esclarecendo os requisitos, em seguida, 30 minutos ou mais a quebrá-lo para tarefas de ~ 8 horas. Não entre nas tarefas durante a reunião. Concordo como uma equipe quais são as tarefas o suficiente para as pessoas sãs para entendê-las, que é responsável por eles, e quanto tempo eles devem tomar. Concordo que "quanto tempo eles devem tomar (incluindo testes)" se encaixam confortavelmente dentro do sprint.

  3. Se não estiver apenas quebrando coisas em tarefas, o que mais você está fazendo? Claro, as retrospectivas podem levar 30-60 minutos, mas serão mais curtas enquanto as equipes entrarem em uma ranhura.

    4. Então, em resumo - pare de desperdiçar o tempo das pessoas e eles pisarão as reuniões um pouco menos. Além disso, divertido e comradarie na equipe não é algo que você pode abordar em reuniões. Ir para o almoço, piada, misture as pessoas para ter melhor personalidade de personalidade, têm concursos crescentes de bigode ... Uma vez que a moral acaba, então as pessoas irão naturalmente fazer as reuniões de planejamento de Sprint mais lumigantes.

Planejamento é uma área de Scrum onde as equipes têm muita flexibilidade. Tente algo novo cada sprint até que você atinge algo que funciona para sua equipe.

Algumas ideias bem sucedidas que tentei pessoalmente, ou ouvi sobre outras equipes:

  • Faça a criação e priorização da história do usuário sem toda a equipe. O proprietário do produto e / ou scrum mestre pode lidar com muito o trabalho ocupado e deixe a equipe ajustá-lo.
  • Faça seu backlog significativamente maior do que um único sprint. Pode demorar um pouco para construí-lo, mas se o seu backlog é longo o suficiente, o planejamento de reuniões é reduzido para fazer pequenos ajustes ou abordar os desenvolvimentos comerciais recentes.
  • tem reuniões de estimativa separadas do planejamento da Sprint. Se as pessoas acham que as reuniões são muito longas, não há razão para não dividi-las.
  • Plano especificamente se interrompe para a agenda. Isso é útil se você é muitas vezes perdendo tempo esperando por um ou dois membros da equipe retornar.
  • quebrar no meio da reunião e atribuir todos a tarefa de uma ou duas histórias de usuário, em seguida, reunir-se para relatar e ganhar consenso.
  • Certifique-se de que sua reunião de planejamento é sobre O que não é Como para fazê-lo. Os engenheiros caem muito facilmente no último. Se você precisar, configure reuniões de design separadas onde você discute o como.
  • Separe suas histórias em investigação e implementação. Reuniões de planejamento muitas vezes vão muito tempo quando os membros da equipe sabem muito pouco sobre o que eles estarão trabalhando e tentar descobrir durante a reunião. Por exemplo, digamos que você precisava integrar com uma API que sua equipe não tem experiência com. Em vez de tentar criar estimativas e tarefas durante a reunião de planejamento sobre algo que você é sem noção, faça uma história de investigação para aprender a API, faça um simples aplicativo "Hello World", e ensiná-lo à equipe. então você será equipado para planejar o trabalho real.
  • Mantenha a pista durante suas reuniões de questões específicas. Não apenas "O planejamento é chato", mas um nível de detalhe como ", passamos muito tempo falando sobre requisitos pouco claros, e ninguém parece saber a resposta certa". Em seguida, discuta essas questões específicas em seus retrospectivos e brainstorming para soluções específicas. Quebre seu problema até que as peças forem fáceis de resolver.

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

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

Com base na minha experiência, uma reunião de planejamento de Sprint não deve ter mais de 2 horas por semana sendo planejada (por exemplo, uma sprint de 2 semanas deve levar 1/2 dia no máximo), mas os bem-sucedidos devem ser mais curtos do que isso (metade deisto).

Em 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íficos .

Uma maneira que funcionou para mim:

  • Introdução rápida para o sprint pelo PO
  • estimativa da capacidade de sprint
  • histórias degradam e planejando o poker (fadado a 5/10 minutos por história) até que haja coisas estimadas suficientes para cobrir o sprint
  • compromisso oficial / previsão pela equipe

Então, em paralelo / paralis / auto-organizado em nossas mesas, tarefas e estimativas de tarefas.

no meu trabalho anterior, todo o primeiro dia de cada sprint (chamamos de iterações lá) foi retirado:

  • retrospectiva. Nós começamos fazendo isso à tarde do último dia, mas muitas vezes nos encontramos retrospectando sobre o sprint e depois voltando ao trabalho amarrando as últimas pontas soltas do trabalho desse sprint , então percebemos que seria melhor ter certeza de que o trabalho estava atrasado antes de retrospectos. Também parecia lógico consolidar toda a sobrecarga da reunião do processo de Scrum, para que os outros dias pudessem ser planejados e gastos em termos mais ideais. Isso normalmente levou 2 horas.
  • planejamento de sprint. O backlog foi estimado durante uma reunião de planejamento de marco (que poderia ser um dia inteiro em si mesmo para os devs e pos), e foi priorizado pela PDV antes do início de cada sprint. Descobrimos quantos desenvolvedores-dias nós tínhamos disponível (contabilidade para feriados, Vaca, etc), pegamos o trabalho que pensamos que poderíamos fazer fora do topo da pilha e revisamos rapidamente os requisitos do usuário (previamente vetido por nossa BAS) para Obtenha uma sensação mais completa do que o trabalho implicou do que com a simples visão geral durante o MPM. Isso normalmente levou mais 2 horas.
  • planejamento de tarefas. Conhecer as histórias e critérios de aceitação, quebramos cada história em tarefas de tamanho mordida estimadas em horas ideais (uma hora gasta com foco apenas em obter essa tarefa "feita" sem distrações ou roadblocks). A maneira como nossa escala de ponto acabou sendo calibrada, um 5 foi um desenvolvedor-sprint, portanto, um 1 poderia ser qualquer coisa até e incluindo dois dias de desenvolvedores. Por esse motivo, praticamente tudo tinha que ser discriminado para que os membros da equipe pudessem mostrar progresso na placa Scrum. Este foi outro bloco de 2 horas, com alguns dar e levar entre isso e o próximo item.
  • aat delineando. Nossos POS e BAS não foram programadores e não codificam. A posição se escondeu atrás de um contrato estipulando que eles oferecem requisitos na forma de um modelo de palavra e trabalhariam com o BAS para refiná-los nessa forma. Bas entenderam o código, mas seu tempo era puramente análise e teste final (que exigiam que o sistema existisse, para que pudessem registrar suas macros em selênio). Assim, para verificar se nosso código atenderia aos critérios de aceitação quando chegou a isso, tivemos que escrever nossas próprias AATs modelando as ações do teste de aceitação "Paper". Normalmente, fizemos isso no mesmo quadro nunitário que usamos para testes de unidade e integração (nós tentamos fitness e não poderíamos desistir rápido o suficiente). Este foi o resto do nosso primeiro dia de cada sprint e continuou no segundo.

No meu trabalho atual, ainda estamos adotando o processo de scrum, não tínhamos um planejamento de marco em toda a equipe e muito do que estamos trabalhando não possui critérios de aceitação estritos. Assim, nosso planejamento de sprint é tanto uma explicação sobre o que cada história implica e o que vamos chamar de fazer como é um compromisso de pegar as principais horas ideais do topo. Nós nos afastamos - por enquanto, pelo menos - porque somos uma equipe interna e cada um de nós trabalha pessoalmente com os usuários finais do nosso software para coletar requisitos e soluções de design. Mesmo assim, o planejamento da Sprint é uma coisa toda da manhã toda segunda-feira, e a tarde é gasta limpando quaisquer roadblocks pessoais para poder começar o desenvolvimento em sério na terça-feira.

.

Para realmente responder a pergunta da OP, em vez de contrastar outros comentários / respostas dizendo que não deveria demorar tanto tempo, há maneiras de abordar estimativas ágil, planejamento e retrospectivos que são um pouco mais interessantes do que você pode estar usando.

Especificamente resolvendo suas preocupações:

  • Reuniões são longas - time-box-los. Cada reunião, seja uma retrospectiva, planejamento de sprint, colapso de tarefas, etc, deve ter um propósito definitivo e tópico de discussão, e deve ser limitado tanto quanto possível a um período de tempo. É o trabalho do Scrum Master para manter essas reuniões no tópico e reverter para atender às metas de tempo.

  • As reuniões são monótonas - haverá um pouco disso; Você está trabalhando em pedaços de tamanho, um de cada vez, então você estará fazendo a mesma coisa mais e mais. Manter a equipe focada e dirigindo para realizar o objetivo da reunião ajudará.

    Algo mais que ouço é que talvez suas reuniões de planejamento de sprint estejam tentando realizar demais. Na minha última empresa, a estimativa de história foi feita em "Reuniões de Planejamento Milestone", que aconteceu cerca de um quarto e pegou o dia todo. Nessas reuniões, tudo o que construiu no backlog que não tínhamos estimado foi estimado em pontos. Se você estiver fazendo uma estimativa de história em pontos, e, em seguida, estimativa de tarefas em horas, você não quer fazer os dois ao mesmo tempo (talvez no mesmo dia).

  • Estimando histórias em pontos, então as tarefas em horas parece redundante

em> - Eles têm dois propósitos diferentes. O objetivo da estimativa da história é fornecer uma estimativa aproximada da complexidade, que você pode usar para preencher seu backlog sprint com base na velocidade anterior e largura de banda esperada. O objetivo da estimativa de tarefas é quebrar as histórias em coisas que levam um dia de desenvolvedor ou menos (e assim pode ser atribuído a um único cara que seria esperado para ter tudo feito a tempo) e garantir que você não tenha estimaria a complexidade de qualquer história nem mordido mais do que você pode mastigar no sprint.

Se as suas histórias levarem um dia ou menos, então é redundante, mas nem todas as escalas de pontos são calibradas igualmente; No meu último trabalho, um 5 foi dois desenvolvedores-semanas (porque no começo tivemos muitos épicos para estimar), que em escala linear fez um ponto qualquer coisa até 2 dias de desenvolvimento. Dado esse tipo de escala, praticamente tudo deve ser dividido em tarefas. Na minha nova empresa, um ponto é mais próximo de metade de um dia de desenvolvedores, portanto, um 1 ou até mesmo um 2 é definitivamente sua própria tarefa, e 3-8 é nebuloso em relação a forçar a equipe a dividir-se em tarefas.

  • Há um ciclo vicioso que leva mais tempo tornando as pessoas menos focadas por isso demora mais - time-box seu time-box. Tome pausas, assim como você deveria ser quando codificando. A cada 30 minutos, pegue 5 minutos para esticar as pernas, reagrupar, etc. Você pode fazer dez minutos a cada hora, mas não empurrar um bloco sólido de tempo de reunião muito além disso. Seus caras podem ficar com fome ou precisar de mais café, ou uma quebra de banheiro, etc. não os negam; Se você fizer eles sugá-lo, você encontrará suas mentes vagando. Além disso, mantendo as discussões curtas, doces e para o ponto também ajudará, como mencionado anteriormente.

    • A reunião de planejamento da Sprint tem 2 partes:

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

      3. A primeira parte é relativamente direta - com base no número de pontos de histórias que a equipe sente que eles podem assumir, o comprometimento para completar isso muitas histórias de usuário em sua ordem de prioridade.Feito.

      A segunda parte é o que os desenvolvedores devem realmente desfrutar - elaboração da história e projetar a solução.As tarefas caem disso.Então, tenha o dono do produto, ou seja qual for a SME que ele tenha fornecido explique uma história escolhida.Então tenha qualquer desenvolvedor queira levá-lo, lidere a discussão de design.Use uma placa branca.Bounce ideias ao redor.Divirta-se.

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

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

    dividir a reunião.

    Nós dividimos nossa reunião de planejamento de sprint em 3 mini-reuniões separadas

    • backlog grooming
    • seleção de histórias
    • falha de tarefa

    Nós fazemos cada um em um dia diferente, logo após o nosso Scrum diário - assim que o diariamente é feito, nós rolamos para a atividade de planejamento, e então estamos livres de reuniões (planejadas regulares) o resto do dia.

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

    Eu vou entrar 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 de sprint realmente terríveis. Tivemos todos os elementos certos, mas tudo acabou de levar para sempre e estava realmente drenando mentalmente e emocionalmente para passar.

    Então eu tenho essa ideia depois de ler Este negócio insider Artigo sobre o Diário de 5 minutos do Pivotal Sobre a quebrando nossas reuniões em sessões mais curtas e fazendo-as no início de cada dia.

    Eu trouxe a equipe em uma retrospectiva. Alguns membros da equipe gostaram disso imediatamente, outros eram um pouco apreensivos, mas o nosso estagiário mencionou algum estudo ele leu sobre o Técnica de Pomodoro e começou a acontecer sobre isso, e isso realmente ajudou a ideia a ganhar tração.

    Então decidimos tentar.
    Nós quebramos nossa reunião de 2 horas em três sessões de 25 minutos. (Sim, isso é matemática fuzzy, mas todos sentiam que nossas reuniões eram muito longas e só queria fazer isso se tivéssemos economizado tempo).

    e funcionou! Estamos fazendo isso por cerca de 6 semanas agora em dois projetos separados (6 de duas semanas de sprints) e fazia um mundo de diferença.
    Somos mais produtivos. Nós economizamos uma tonelada de tempo.
    Nós obtemos melhores saídas. E não temos mais nossas reuniões de planejamento.

    e honestamente, nossa caixa de tempo de 25 minutos é muito solta - algumas sessões vão muito rápido, como 5-10 minutos em algumas de nossas sessões de grooming, e algumas vão muito, como quando acabamos identificando novas histórias ou tendo que quebrar histórias para cima e re-estimar durante a negociação. No geral, porém, geralmente é uma média para não mais do que 1,5 horas para o todo Shebang, e acho que é por isso que funciona tão bem.

    .

    para os detalhes .....

    Grooming Backlog

    Bastante simples - revisamos as principais histórias prioritárias, falamos sobre o que eles implicam e garantem que nossas estimativas sejam boas.

    Vamos re-estimar histórias se necessário - como dizer que estimamos algo meses atrás e depois de perceber o que uma história semelhante realmente tomou, poderíamos concordar em re-estimar. (usamos Unidade - menos pontos de histórias < / a> pelo caminho, e nós não estime tarefas ).

    Além disso, se o po adicionaram quaisquer novas histórias que ele sente é prioridade, esta é a hora de estimar-lhes.

    Porque não fazemos a seleção de história até o dia seguinte, esse processo dá ao po pouco extra para fazer julgamento final sobre o que é mais importante para ser feito na próxima iteração - e isso provou ser muito útil.

    Esta reunião tende a ficar curta com alguns po e muito com os outros. (Pessoalmente, acho que é um ótimo indicador de cheiro de como seu po está fazendo)

    Seleção de história

    Obtenha o seu chris voss On, é hora de negociar.

    Nesta reunião, tomamos as principais histórias prioritárias e definimos um DoD para cada um. Negocemos o que cada um irá implicar - dividindo e combinando histórias conforme necessário - até que todos possam concordar com nossos objetivos da Sprint.

    Nós nos beneficiamos muito de terem mentes novas e aquela energia de bom dia para esta reunião - e saber que faremos tarefas outro dia nos permite gastar o tempo que precisamos realmente negociar bem e entender nossos compromissos.

    Tarefas

    Ok, então serei o primeiro a dizer, as tarefas eram minhas menos parte favorita do planejamento em nossas novas reuniões de um dia.

    Nós nunca acertamos nosso passo com isso. Tentamos economizar tarefas até o final da reunião - mas todos nós fomos apenas drenados até então e foi realmente improdutivo. Nós tentamos definir tarefas ao mesmo tempo que o nosso DoD durante nossa negociação, mas achamos isso muito distraindo e muito incômodos - nos que nos queimaríamos antes de selecionar todas as histórias. Além disso, foi muito difícil continuar com a troca de foco / pensando entre estimar, negociar, seleção de histórias e gerati tarefa

    sobre.Nós lutamos, e chupou, e fez nossas reuniões terríveis.

    mas agora, definindo o DoD em um dia, e não fazendo tarefas até o próximo, não nos queimamos, estamos sempre no Mindstate Direito, e nos dáUm dia inteiro para marinar sobre a história e realmente pensar e entender todas as tarefas antes de começarmos.

    Isso sozinho, IMHO, é um trocador total de jogos.

    .

    colocando tudo junto.

    Então, aqui é o que a nossa programação de cerimônia de sprint se parece com agora:

    • segunda-feira - Daily Scrum -> Sprint Review
    • terça-feira - Daily Scrum -> Grooming Backlog
    • quarta-feira - Daily Scrum -> seleção de história
    • quinta-feira - Daily Scrum -> Tarefas
    • sexta-feira - Daily Scrum -> retrospectiva

    Está funcionando muito bem para nós. Se você der um tiro, adoraria ouvir o que você pensa.

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

    Isso é claro porque descobrimos que, no nosso caso, o Scrum muito rigorosamente só desperdiçaria muito tempo.Isso é porque a maioria das histórias já está discutida com nossos membros da equipe quando o solicitante cria a história do usuário.

    Estou apenas dizendo que, se sua equipe teme a planejamento de reuniões, você provavelmente deve deixar ir algumas das "regras" do Scrum.

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

    dê energia à equipe. - i.e. faça-os trabalhar em coisas que eles acha que são os mais importantes.

    Licenciado em: CC-BY-SA com atribuição
    scroll top