Guia Scrum | 34. Velocidade no Scrum – Velocidade da Equipe de Desenvolvimento

A velocidade no Scrum ajuda você a determinar a taxa na qual o Time Scrum conclui as tarefas. Podemos defini-lo como o número médio de Story Points concluídos em um Sprint. O Velocity também pode estimar a duração de um projeto com base no progresso do trabalho já concluído. No entanto, isso só faz sentido para uma equipe madura que trabalha em um ritmo uniforme e constante. Dê uma olhada no que é o Velocity e como fazê-lo funcionar melhor para você!

Velocidade no Scrum – índice:

1. Velocidade no Scrum – Introdução
2. Velocidade real e planejada
3. Dificuldades e riscos associados ao Velocity no Scrum
4. Resumo

Velocidade no Scrum – Introdução

A velocidade é um método opcional, mas popular, para medir o ritmo de um Time Scrum. Isso ocorre porque uma velocidade estimada com precisão permite prever, de forma razoável, o tempo necessário para concluir um projeto. No entanto, é uma medida que só pode ser aplicada a um determinado Time de Desenvolvimento, que realizará tarefas que ele próprio “valorizou” usando uma unidade familiar, como Story Points, por exemplo.

A velocidade da equipe de desenvolvimento é mais frequentemente apresentada na forma de um gráfico de velocidade. No eixo X estão marcados Sprints consecutivos. No eixo Y, por outro lado, encontraremos o número de Story Points ou outras unidades correspondentes que foram concluídas em um determinado Sprint. Com o Gráfico de Velocidade, o Time Scrum ganha uma visão clara das mudanças no ritmo de seu trabalho. Se a linha marcada no gráfico estiver subindo, significa que o Time está otimizando sua eficiência ou reduzindo o valor dos Story Points. Tanto o Scrum Master quanto o Product Owner devem, portanto, seguir cuidadosamente a linha que mostra a Velocidade do Time.

Velocidade real e planejada

A velocidade real da equipe de desenvolvimento descreve o ritmo de trabalho no Sprint concluído e é calculada no final de cada Sprint. Leva o valor da soma dos Story Points para todas as User Stories concluídas. A velocidade real da equipe de desenvolvimento permite planejar e estimar com alguma probabilidade o ritmo das tarefas futuras.

A Velocidade planejada, por outro lado, é estimada com base em um valor médio da Velocidade real. Requer a suposição de nenhuma mudança na equipe de desenvolvimento. É uma importante ferramenta interna para a Equipe de Desenvolvimento, que a partir dela pode avaliar se a cooperação na Equipe está indo bem e se o ritmo de trabalho está sendo mantido.

O Planned Velocity também permite que o Product Owner preveja o tempo de execução de User Stories bem definidas agendadas para execução em Sprints subsequentes. Isso permite um cultivo mais eficiente do Product Backlog, sobre o qual escrevemos neste artigo. No entanto, a prática de aplicar a velocidade planejada para estimar a duração do projeto não é tão simples.

Dificuldades e riscos associados ao Velocity no Scrum

A velocidade no Scrum é muitas vezes dada muita importância sem considerar os seguintes fatores:

• estimar conjuntos maiores ou todo o projeto – embora a Equipe de Desenvolvimento possa estimar com precisão o número de pontos de história a serem atribuídos a uma tarefa específica, é muito difícil ou impossível descrever conjuntos maiores para implementação futura nessas unidades
• mudanças no projeto – qualquer mudança no projeto significa potencialmente uma mudança no número de pontos de história necessários para atingir a meta do produto. Também pode ser que tarefas já concluídas precisem ser modificadas ou até mesmo não utilizadas na versão final do Produto
• imprevistos – prever o ritmo de projetos futuros com base nos já concluídos, ou seja, traduzir a Velocidade real em Velocidade Planejada, pode resultar em estimativas precisas. No entanto, cada projeto tem suas peculiaridades e uma previsão precisa com base no histórico geralmente é impossível.

Resumo

Usar a velocidade como uma métrica para avaliar a eficácia da equipe de desenvolvimento pode fazer com que sua confiabilidade seja degradada. Também pode degradar a qualidade das estimativas, sobre as quais escrevemos com mais detalhes neste artigo. Afinal, para obter os melhores resultados possíveis nas métricas, o Time de Desenvolvimento pode superestimar a intensidade de trabalho das tarefas para aumentar a Velocidade. Isso é prejudicial, pois a própria equipe perde informações valiosas para fazer melhorias e planejar suas tarefas com mais precisão.

A velocidade no Scrum é útil principalmente como uma medida interna usada pela equipe de desenvolvimento para avaliar o ritmo de seu trabalho. Isso porque permite determinar quantas tarefas ele é capaz de concluir durante um único Sprint.

A velocidade nas mãos do Product Owner torna-se uma ferramenta útil para estimar o prazo para tarefas maiores.

No entanto, os maiores riscos estão associados ao uso do Velocity como métrica para avaliação do Time de Desenvolvimento. Isso porque pode levar a uma diminuição de sua credibilidade e até mesmo uma superestimação deliberada de seu valor para melhorar a avaliação externa do trabalho do Time Scrum.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto