Guia Scrum | 23. Pontos de História e Estimativa no Scrum

No artigo de hoje, abordamos o tema de Estimativa e Pontos de História no Scrum. Criar estimativas no Scrum ajuda a prever a complexidade e o tempo necessário para concluir as tarefas. Ao analisar o passado, toda a equipe Scrum prevê coletivamente o que o futuro reserva.

Portanto, quanto mais experiente a equipe Scrum, mais precisas são suas estimativas. A equipe também colabora na definição do tempo estimado para concluir as tarefas durante o Planejamento da Sprint, tendo em mente que não é um compromisso final, mas uma previsão. Sua precisão depende de inúmeras variáveis que constantemente sofrem mudanças imprevisíveis e circunstâncias inesperadas. Felizmente, a metodologia Scrum inclui técnicas e ferramentas para facilitar algum grau de certeza, e hoje discutiremos isso em detalhes para que você possa entender e aplicá-las imediatamente!

Pontos de História e Estimativa no Scrum – índice:

1. Introdução
2. A Importância dos Pontos de História no Scrum
3. Técnicas de estimativa relativa
4. Resumo

Introdução

Em cada Planejamento de Sprint, o Product Owner apresenta novas User Stories para a equipe. O Product Owner seleciona-as do Product Backlog para implementação na próxima Sprint. Em seguida, os membros da equipe Scrum estimam em conjunto a carga de trabalho necessária para concluir este novo lote de tarefas. Esse tipo de atribuição é uma estimativa, estimativa de requisitos.

Parece que a maneira mais simples é definir o tempo necessário para concluir a tarefa em horas ou dias. No entanto, a prática e a pesquisa realizadas desde a década de 1940 provam o contrário. Os humanos são incapazes de estimar com precisão o tempo necessário para concluir até mesmo tarefas muito bem definidas. Além disso, o número de horas necessárias para concluir uma tarefa depende de quem está realizando a tarefa e do que foi – ou não – feito antes. É por isso que o Scrum normalmente usa unidades chamadas Pontos de História.

A Importância dos Pontos de História no Scrum

Cada equipe de desenvolvimento coloca em prática o valor de um Ponto de História, baseando-se na experiência e no tamanho das tarefas individuais, ou seja, seguindo o princípio do empirismo. Mais frequentemente, durante o Planejamento da Sprint, o Scrum Master seleciona uma ou mais amostras de User Stories concluídas, que servem como um ponto de referência para determinar o valor das User Stories a serem desenvolvidas.

É por isso que você não pode atribuir valores em Pontos de História sem o contexto. Por exemplo, se a primeira tarefa recebe um valor de 10, as tarefas subsequentes serão avaliadas em relação a ela como maiores ou menores. Dessa forma, dentro de um projeto da equipe Scrum, todas as tarefas no Product Backlog estão relacionadas entre si. Isso significa que tarefas semelhantes realizadas por uma equipe de desenvolvimento receberão um número semelhante de pontos.

Pontos de História são unidades relativas. Isso significa que:

1. O valor do Ponto de História se relaciona apenas às tarefas realizadas por uma equipe Scrum específica. Os Pontos de História descrevem a velocidade de conclusão das tarefas de uma equipe. Em outras palavras, uma User Story estimada em 10 Pontos de História pela Equipe A pode receber 50 pela Equipe B. Isso ocorre porque, como mencionamos, seu valor é calculado relativamente a outras tarefas realizadas por essa equipe e sua experiência com tarefas semelhantes.
2. O valor dos Pontos de História concluídos em uma Sprint não pode ser a base para comparar o desempenho de duas equipes Scrum. Para evitar erros na gestão de projetos Scrum, é importante lembrar que a Velocidade de uma equipe de desenvolvimento expressa em Pontos de História feitos em uma Sprint não pode ser usada para comparar o desempenho de duas equipes. Isso porque elas poderiam realizar o mesmo trabalho em Sprints paralelas, que uma equipe estimou em 10 e a outra em 50 Pontos de História.

Também não deve ser esquecido que a estimativa contém muitos elementos desconhecidos e é feita com base em dados incompletos. Por essa razão, as previsões de uma equipe Scrum muito experiente podem, às vezes, ser muito diferentes do esforço real necessário para concluir uma User Story.

Técnicas de estimativa relativa

Quais são as técnicas de estimativa mais eficazes no Scrum? Não existe um método único que funcione para cada equipe.

Entre as técnicas de estimativa dentro das metodologias ágeis, as mais comuns são:

• Planning Poker. Este método relativo mais popular utiliza um jogo de cartas para calcular a quantidade de trabalho necessária para concluir uma tarefa. As regras e o processo detalhados abordaremos em um artigo separado.
• Team Estimation Game. Este envolve atribuir a execução de User Stories em uma Sprint dada com valores numéricos apropriados selecionados da sequência de Fibonacci. Também dedicamos um artigo separado para isso.

O Scrum, por outro lado, rejeita a clássica forma de Estimativa Absoluta da metodologia tradicional de gerenciamento de projetos. A maneira como estima as tarefas é definindo previamente os meses-homem, a duração e o custo de todo o projeto. Este é um processo longo, difícil de implementar e requer a participação de especialistas que tendem a estabelecer a justificativa e o código de conduta, mas não tomam nenhuma ação que não necessariamente realizará as tarefas cujo valor estimaram. Em outras palavras, não é apenas tedioso, mas também altamente ineficiente.

Pontos de História e Estimativa – Resumo

A estimativa é uma habilidade muito importante que caracteriza todas as equipes Scrum maduras. Estimar a quantidade de tempo e esforço necessários para concluir tarefas individuais tornou-se o foco principal de muitas técnicas de estimativa relativa, como Planning Poker ou Team Estimation Game.

User Stories com Pontos de História é mais uma técnica de medição eficiente que descrevemos, esperando fornecer aos nossos leitores algumas ferramentas úteis. No entanto, é importante ter em mente que seus números se relacionam apenas às tarefas específicas realizadas pela equipe Scrum. Portanto, o número de Pontos de História não pode se tornar a base para comparar a velocidade de diferentes equipes de desenvolvimento.

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