Planejamento de sprint, revisão: velocidade, capacidade, previsão e como esses valores se relacionam?

Eu sou relativamente novo no Scrum e no seu planejamento de sprint/retro (etc), nossa equipe hoje estava tentando calcular velocidade, capacidade e previsão para o sprint seguinte, mas acabamos de perceber que ninguém realmente sabia como fazer isso.

Alguém poderia me explicar (como se eu tivesse 5 anos) - e/ou apontar para algum lugar - como fazer isso? Eu pesquisei e estou prestes a começar a ler o Guia do Scrum, mas ainda estou perdida.

Caveats: Since I'm still new to this I do not have too much data (1 sprint completed) and there was no velocity, capacity, etc, taken there, I understand that perhaps what I'm trying to accomplish will not be 100% accurate, but ny help will be appreciated.

Sprint anterior:

Team members: 4

Previous sprint(s) completed: 1 (2 weeks)

Previous sprint points Taken: 34

Previous sprint points completed: 13


Novo Sprint

Points wanting to take: 21

Sprint duration: 2 weeks

Working Days of each team member: (9 + 9 + 9 + 4.5) = 31.5 days

3
Além da excelente resposta de Thomas abaixo; Pergunte a si mesmo algumas perguntas - por que você está estimando em pontos? Eu quero dizer realmente . É simplesmente porque você herdou isso? Como um time júnior, você poderia simplesmente dizer "quantas coisas conseguimos fazer?" Isso provavelmente será próximo da quantidade de coisas que você faz na próxima Sprint, impedindo alguma variação no ambiente. Orientar a equipe para absorver menos e deixar alguma capacidade. Eles sempre podem adicionar mais tarde, se quiserem. Além disso, os dias não são iguais. Não há relação entre os dias e pontos do homem. Se você quiser estimar em dias de homem, faça isso
adicionado o autor Venture2099, fonte

1 Respostas

A velocidade não é algo calculado, é medido. Velocidade é a quantidade de trabalho que é concluída em um Sprint. Nesse caso específico, como você estima o trabalho nos Pontos de História, você terá uma Velocidade nos Pontos de História. No final de um Sprint, você pode olhar para todo o trabalho que foi feito (de acordo com a Definição de Feito), resumir os Pontos de História e essa é a sua Velocidade para o Sprint anterior.

Capacidade é quanto trabalho uma equipe pode assumir. No Scrum, prefiro representar isso como uma porcentagem e considerar apenas os membros da equipe de desenvolvimento. Se todos os membros da equipe estiverem trabalhando para todo o Sprint, a capacidade é de 100%. Em um Sprint de 2 semanas com uma Equipe de Desenvolvimento de 5 pessoas, se houver um feriado da empresa e nenhum outro tempo livre, a capacidade da equipe seria de 90%. Eu mantenho a capacidade de nível muito alto e aproximo-me de mantê-la em dias inteiros (alguém tirando a folga é computado quando eles tiram um dia inteiro de folga), mas há pessoas que preferem uma capacidade mais refinada. Ao pensar em Capacidade, também é útil considerar quaisquer habilidades especializadas que os indivíduos tenham.

O conceito de O tempo de ontem pode ser útil para previsão e planejamento de um Sprint. Yesterday's Weather diz que a previsão do próximo Sprint é muito parecida com os resultados reais de seus sprints mais recentes.

No seu exemplo, você completou um Sprint e tem uma velocidade conhecida de 13. Você deve planejar uma velocidade próxima a 13 para o seu próximo Sprint. Depois de concluir algumas Sprints, você pode dar uma olhada na Velocidade dos Sprints anteriores e usar uma média de janela deslizante. Uma recomendação comum é usar os 3 Sprints concluídos mais recentes. No entanto, você também deve ajustar a capacidade.

Observe que Velocity, Capacity e Yesterday's Weather não fazem parte do Scrum, conforme definido no Scrum Guide. O Scrum está em silêncio sobre os métodos usados ​​para planejar um Sprint.

Também recomendo que você tente ter mais Itens do Backlog do Produto refinados e prontos para o trabalho de desenvolvimento do que os que você pode trazer para o Sprint. Se sua equipe aumentar seu desempenho (ou talvez o trabalho tenha sido superestimado), provavelmente você não quer que as pessoas fiquem ociosas. Eles devem ter algo para fazer, como investigar e definir o próximo trabalho ou poder começar o próximo item de prioridade mais alta no Backlog do Produto.

5
adicionado
@ Venture2099 Eu não tenho certeza do que você quer dizer. Já parece que eles têm técnicas de estimativa (eles estão usando Story Points) e estão rastreando Velocity (Sprint 1 tem uma Velocity no valor de Story Points completos). Essa questão parece ser exclusivamente sobre como planejar quanto trabalho levar para o Sprint. Eu ficaria mais do que feliz em tornar esta resposta mais clara, mas não tenho certeza do que mais incluir.
adicionado o autor Grant, fonte
@intercoder OK - expandirei essa resposta. Mas o Velocity é simplesmente a quantidade de trabalho (no seu caso, Story Points) competiu no Sprint anterior. Nenhum cálculo é necessário.
adicionado o autor Grant, fonte
@intercoder As minhas edições abordaram tudo? Se não, me avise e eu posso trabalhar lá.
adicionado o autor Grant, fonte
@intercoder Para calcular a capacidade, eu tenho que saber o tamanho do seu time. Mas o exemplo que dei na minha pergunta é de fato calculado (baseado em 5 pessoas na equipe, 2 semanas de sprints e um dia de folga para toda a equipe). A capacidade máxima é o (número de pessoas * dias úteis no Sprint). A velocidade proposta será uma fração disso, que você pode usar para ajustar a velocidade.
adicionado o autor Grant, fonte
@ThomasOwens e @ Venture2099 Eu tenho lido on-line sobre fórmulas para calcular capacidade , velocidade , etc. Existe alguma utilidade. Preciso usá-los para calcular o próximo sprint? Por exemplo: Velocidade = pontos entregues/# sprints concluídos Capacidade = # membros da equipe * # semanas no sprint * 24 horas (60%) ou 32 horas (80%) do trabalho real
adicionado o autor Loopo, fonte
@ThomasOwens que realmente ajuda muito :) obrigado. Mas eu ainda estou tendo dúvidas sobre como calcular a capacidade quando vamos dizer que 1 membro da equipe será digamos 3 dias de férias fora do sprint? Quero dizer, de onde você tira 90%, é um palpite aleatório ou um cálculo? obrigado
adicionado o autor Loopo, fonte
@ThomasOwens e @ Venture2099 . graças a um monte isso é tudo um pouco novo para mim, então ainda experimentando/aprendendo a abordagem "melhor/correta". Obrigado por todos os links e explicações.
adicionado o autor Loopo, fonte
Thomas - Eu não quero replicar sua resposta, pois ela cobre 80% do que o post está pedindo, mas eu sugiro que você adicione mais à sua. O OP parece estar faltando alguns padrões básicos e está sobrepondo-os. Pode valer a pena dividir sua resposta em cabeçalhos "Planejamento", "Técnicas de estimativa" e "Velocidade". A maioria dos novos iniciados no Scrum apenas transforma tudo em um.
adicionado o autor Venture2099, fonte
... @ intercoder Eu ficaria preocupado se você estivesse tentando chegar a um compromisso muito detalhado e minucioso da equipe. Você precisa se sentir confortável com a ambigüidade de progredir. finding-marbles.com/wordpress/wp-content/ uploads/2012/06/& hellip;
adicionado o autor Venture2099, fonte