Num projeto em SCRUM com iterações de 2 semanas, quanto tempo dura a reunião de planning de vocês?
Qual o nível de detalhe que entra no planning poker ? O erro nessa análise costuma ser baixo/alto ?
Num projeto em SCRUM com iterações de 2 semanas, quanto tempo dura a reunião de planning de vocês?
Qual o nível de detalhe que entra no planning poker ? O erro nessa análise costuma ser baixo/alto ?
Boaglio, aqui na empresa estou fazendo o planning todo em mais ou menos 4hs, depois de 3 planejamentos os valores estão bem mais próximos do que realmente acontece na hora de desenvolver, ou seja, os itens estão sendo mensurados com uma margem de erro bem menor.
Oi Boaglio,
Meu time trabalha no seguinte esquema:
10 dias úteis de desenvolvimento
1 dia para retrospectiva + review + atividades livres que agreguem valor ao trabalho
1 dia para planning + atividades livres que agreguem valor ao trabalho
Nosso planning dura entre 3 a 4 horas (planning 1 e 2) depende muito as estórias envolvidas e do conhecimento do time em relação a elas. Para tentar deixar o planning um pouco mais dinamico e organizado estamos tentando realizar junto com o PO reuniões só de estimativas, para que no dia do planning as estórias estejam mais claras pra todo mundo e no máximo seja necessário re-pontuar alguma.
So planning 2 entramos nos detalhes técnicos que envolvem a estória para poder quebrar as tarefas, eu considero o planning 2 um ponto de partida para o desenvolvimento da estória, afinal tarefas podem entrar ou deixar de existir a medida que o time começa a trabalhar nela.
Quanto ao erro na analise bem, não existe erro, na minha opnião pois é uma estimativa, e estimativa é um “chute calculado”, mas a gente tenta calibrar a nossa complexidade todo planning, para isso utilizamos os cartões com as estórias concluidas nos sprints anteriores e sempre que surge duvidas olhamos o passado e ver o que medimos como 2, 3 … e isso tem dado certo. Antes de usarmos as estorias antigas para calibrar nossa medida de complexidade em todo planning rolava uma discussão sobre o era cada ponto pra cada um dos integrantes, depois disso as discussões praticamente acabaram.
2 horas para Sprint Planning 1 e 2 horas para Sprint Planning 2. Total de 4 horas.
Para isso funcionar é necessário manter o backlog sempre organizado e estimado, não dá pra querer discutir tudo nesse tempo senão não dá certo. Para isso criamos reuinões que chamamos de pré-planning, que acontecem duas vezes durante os Sprints e servem para discutirmos e mantermos planejados algo em torno de 3 Sprints à frente. Cada uma dessas reuniões dura 1 hora e sempre reservamos tempo para elas no Sprint Planning anterior, já que é fundamental a presença de todo o time. Quando não há necessidade simplesmente não fazemos essa reunião e trabalhamos normalmente.
Nossa iteração de 2 semanas significa: 8 dias pra desenvolvimento + 1 dia pra fazer um demo pro cliente e ajustes finais + 1 dia para planejamento e retrospectiva e outras cositas. O planejamento em si leva no máximo 4 horas.
Também usamos um esquema de pré-planning parecido com o que o Guilherme descreveu. No nosso caso acontece no primeiro dia de iteração onde alguns desenvolvedores ajudam o cliente a levantar/estimar/priorizar estórias suficientes para as próximas 3, 4 iterações seguintes. Nessa reunião se conversa sobre as estórias o suficiente para estimá-las com segurança e desta forma chegamos para a reunião de planejamento com um backlog pronto para se trabalhar.
O erro nas estimativas depois de algumas iterações costuma ser bem baixo, principalmente porque os desenvolvedores/cliente colaboram pra elaboração das estimativas.