Que problemas é SP Estimating E como isso está te beneficiando?
No nosso projeto atual, somos 6 desenvolvedores e fazemos estimativas baseadas em tempo absoluto, ou seja, 2 SP é um dia e a duração do Sprint é de 4 semanas (20 dias úteis). Então planejamos aproximadamente 200 SPs (de acordo com o cálculo 240 = 2*20*6) com 40 SP de buffer. Mas estamos notando nos últimos dois Sprints que conseguimos terminar aproximadamente 160 SPs e agora o Product Owner quer saber o motivo da diminuição na produção dos últimos Sprints, já que está claro que mesmo com buffer deveríamos conseguir atingir no mínimo ou aproximadamente 200 SPs.
Em segundo lugar, estou planejando mudar para estimativas baseadas em valores relativos usando a série de Fibonacci. Mas minha dúvida seria como escolher uma História de Referência, ou seja, minha história de usuário de 1 ou 2 SP para estimativa relativa? Acredito que aqui novamente a história de usuário de referência terá que ser estimada usando tempo, ou seja, digamos que essa história de usuário precisamos de 2 dias e daí em diante estimar as outras relativamente.
Em terceiro e último lugar, temos a seguinte estrutura para formulação de tickets:
História de usuário, ou seja, ticket de funcionalidade
- Subtarefa 1
- Subtarefa 2
Atualmente, com a estimativa de tempo absoluto, estimamos as subtarefas e somamos os SPs e atualizamos o ticket principal da história de usuário com a soma. É uma boa opção ou há alguma maneira melhor e também se eu mudar para estimativa relativa como devo realizar a estimativa para a estrutura de ticket acima. Análise coletada por e hospedada no G2.com.