Tem tempo exatamente quanto tempo cada membro da equipe gasta em uma história útil no Scrum?

Só é necessário ter alguma medida de quanto tempo uma história levou para implementar, para que você possa compará-la com a estimativa inicial. Armado com essa informação, você pode fazer estimativas melhores da próxima vez.

Por exemplo, para essa iteração, você decide que a história A levará dois dias e a história B, quatro. No entanto, ela realmente demora três para os dois. Em seguida, na próxima iteração, você poderá examinar novamente as histórias restantes e reestimá-las com base nessas informações. Se houver mais histórias como "A", você precisará de mais tempo (ou menos tarefas), no entanto, se houver mais histórias como "B", você precisará de menos tempo (ou fazer mais).

Você não deve registrar o tempo contra os membros da equipe, mas contra a história. Eu sei que alguns dizem que você não deve logar em nenhum momento, mas a menos que você tenha desenvolvedores com recordação perfeita, suas estimativas de futuras tarefas serão distorcidas. Ter números permite que você (até certo ponto) normalize as estimativas.

No Scrum, todo o esforço está focado em olhar para frente. Os reais, portanto, não têm valor intrínseco. O que é útil sobre os reais é usá-los para refinar como uma equipe faz suas estimativas.

Mesmo assim, no entanto, uma análise detalhada de como estimativas individuais são comparadas com as reais é de pouco valor. Na prática, a maioria das equipes aprende a viver com precisão na estimativa e preenche os Sprint Backlogs de acordo.

Por exemplo, vamos supor que uma equipe habitualmente supere, acima de estimativas de tarefas. Eles planejam 30 homens-dia de esforço para uma equipe de 5 pessoas durante um Sprint de 2 semanas (5 * 6 (assumindo 60% de utilização dos 10 dias úteis)) e descobrem que tudo é feito até o dia 4. Então, quando planejam o próximo Sprint, eles dizem para si mesmos: "Bem, nós fomos capazes de completar 30 dias de estimativas com muito tempo sobrando, então vamos colocar 60 (estimados) homens-dias de tarefas no próximo Sprint e ver o que acontece". Com o tempo, eles aprenderão como suas estimativas se relacionam com quanto trabalho podem ser feitos em um Sprint. Não importa quão ruins sejam as estimativas, desde que sejam consistentes.

Retrospectivas são o lugar onde a equipe se senta e analisa suas estimativas e como elas querem lidar com a precisão (ou não). O único fator importante, porém, é que eles calculem a quantidade certa de tarefas para colocar no próximo Sprint.

Eu fiz isso no meu primeiro projeto Scrum. Não forneceu nenhum valor. Essa técnica só faz sentido se você quiser reutilizar esse conhecimento para a próxima estimativa, mas nesse caso você deve estimar em horas com uma granularidade muito baixa (tarefa) que não é possível.

Nós fazemos isso em nosso projeto. Os gerentes adoram, porque eles têm planilhas cheias de números. Eu não vi nenhuma evidência de que isso realmente ajuda o projeto a funcionar melhor.

Você deve perguntar por que ele quer medir quanto tempo eles gastam em histórias de usuários.

A única razão válida que vejo é verificar a produtividade. Se ele realmente quer calcular a produtividade individualmente assim, você deve parar de usar Scrum.

O Scrum é centrado em equipe e não centrado individualmente. Isso funciona por causa disso.

Eu posso imaginar apenas dois usos:

1) Se você mantiver algum tipo de pontos de história ou pontos de complexidade para cada stoyry, poderá obter algum tipo de média ou intervalo de tempo necessário para cada ponto de complexidade. Isso pode ser útil para estimar tarefas futuras.

2) você pode calcular cada sucesso de previsão empoyeese: O tempo que eles previram para uma tarefa v / s o tempo que eles realmente levaram para terminar isso. Eu não vejo como isso vai melhorar o processo, mas pode ser usado como um ponto de recompensa / penalidade durante as avaliações.