Olá pessoal,
no post de hoje eu abordo alguns detalhes sobre o momento em que estamos planejando a Sprint, mais precisamente na etapa do processo Scrum conhecida como Reunião de Planejamento.
Nesse post aqui eu já falei sobre o planejamento da Sprint e procurei responder à pergunta "Quantas histórias minha equipe é capaz de desenvolver?". Nele, eu falo sobre a utilização da velocidade da equipe como medida para auxiliar nessa seleção.
No post de hoje quero mostrar que essa medida está em constante mudança e, por isso, é importante estarmos sempre atentos e atualizando a velocidade da equipe a cada Sprint.
Podemos notar isso analisando a quantidade de pontos que são entregues no final de Sprints sucessivas. Essa quantidade está sempre mudando e, portanto, a velocidade também. Os motivos dessa mudança podem ser vários:
- Ausência de algum membro da equipe
- Feriados durante a Sprint
- Subestimação/Superestimação de histórias
- Histórias urgentes e imprevistas que entram na Sprint
- Outros
No projeto em que faço parte utilizamos o Planning Poker para estimar os pontos das histórias (mais informações sobre como fazer isso aqui, aqui e aqui), mas também temos guardados quanto tempo (em horas) cada história levou para ficar pronta. Com isso podemos pegar, por exemplo, as histórias que pontuamos com 3 pontos, ver o total de horas consumidas, dividir pela quantidade de histórias e aí teremos uma relação de quanto tempo, em média, a equipe leva para finalizar uma história de 3 pontos.
Na tabela a seguir podemos observar que recentemente houve uma mudança na quantidade de horas que levamos para finalizar histórias de 3, 5 e 8 pontos. As duas últimas tiveram uma mudança sutil, mas a história de 3 pontos passou a ser finalizada em 75% do tempo anterior. Não devemos entender que essa diminuição do tempo significa necessariamente que a equipe passou a ser mais eficiente, mas devemos encarar como uma mudança natural, já que os pontos são baseados em estimativas.
Ainda analisando a tabela, podemos fugir um pouco do tema velocidade e entrar na discussão pontos vs horas, que já foi abordado nesse post aqui.
Olhando os dados da tabela percebemos claramente que pontos e horas não formam uma função linear. Ou seja, não é porque para finalizar a história de 1 ponto leva 2h que a história de 2 pontos deveria levar 4h, e a de 5 pontos levar 10h. Não é bem por aí, afinal estamos lidando com incerteza e nossos pontos de estimativa são fuzzy (mais informações sobre fuzzy você encontra aqui).
E você leitor, anda medindo frequentemente a velocidade da sua equipe? Faz de outro jeito? Sinta-se convidado a compartilhar conosco um pouco da sua experiência.
Até o próximo post!
A velocidade da minha equipe, eu aplico de outra forma.
Quantidade de Issues / nr. Dias da Sprint = Velocidade Ideal
E, diariamente verifico a velocidade do dia anterior, sendo quantidade de issues anterior – quantidade issues resolvidas.
Exemplo:
ISSUES ESTIMADA = 34
DIAS SPRINT = 5
VELOCIDADE IDEAL = 6,8 / dia
—
DIARIAMENTE
ISSUES RESOLVIDOS = 31 (exemplo, dia 1), onde o ideal seria estar com 27
VELOCIDADE ATUAL DO TEAM = 3 / dia
OI Everaldo,
entendi que você utiliza dias úteis. Mas como você trabalha esse acompanhamento diário? Você o usa para substituir o Burndown da Sprint?