Guia Scrum | 23. Pontos de história e estimativa no Scrum

No artigo de hoje, abordamos o tópico de Estimativa e Story Points no Scrum. Criar estimativas no Scrum ajuda a prever a complexidade e o tempo necessário para concluir as tarefas. Ao analisar o passado, todo o Time Scrum prevê coletivamente o que o futuro reserva.

Portanto, quanto mais experiente for o Time Scrum, mais precisas serão suas estimativas. A equipe também colabora no estabelecimento do tempo estimado para concluir as tarefas durante o Sprint Planning, lembrando que não é um compromisso final, mas uma previsão. Sua precisão depende de inúmeras variáveis ​​que sofrem constantemente 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 vamos discuti-las em detalhes para que você possa entendê-las 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. Os Story Points são unidades relativas. Isso significa que:
4. Técnicas de estimativa relativa
5. Resumo

Introdução

A cada Sprint Planning, o Product Owner apresenta novas User Stories para a equipe. O Product Owner os seleciona no Product Backlog para implementação no próximo Sprint. Em seguida, os membros do Time Scrum estimam em conjunto a carga de trabalho necessária para concluir esse novo lote de tarefas. Este 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 as pesquisas realizadas desde a década de 1940 provam o contrário. Os seres 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á fazendo a tarefa e do que foi – ou não – feito antes. É por isso que o Scrum normalmente usa unidades chamadas Story Points.

A importância dos pontos de história no Scrum

Cada Equipe de Desenvolvimento coloca em prática o valor de um Story Point a partir da experiência e do tamanho das tarefas individuais, ou seja, seguindo o princípio do empirismo. Na maioria das vezes, durante o Sprint Planning, o Scrum Master seleciona uma ou mais amostras de User Stories concluídas, que servem como ponto de referência para determinar o valor das User Stories a serem desenvolvidas.

É por isso que você não pode atribuir valores em Story Points sem o contexto. Por exemplo, se a primeira tarefa receber um valor de 10, as tarefas subsequentes serão avaliadas em relação a ela como maior ou menor. Desta forma, dentro de um projeto Scrum Team, todas as tarefas do Product Backlog estão relacionadas entre si. Isso significa que tarefas semelhantes executadas por uma equipe de desenvolvimento receberão um número semelhante de pontos.

Os Story Points são unidades relativas. Isso significa que:

O valor do Story Point refere-se apenas às tarefas executadas por um Time Scrum específico. Os Story Points descrevem a velocidade de conclusão das tarefas de uma equipe. Em outras palavras, uma User Story estimada em 10 Story Points pela Equipe A, pode chegar a 50 pela Equipe B. Isso porque, como mencionamos, seu valor é calculado relativamente a outras tarefas realizadas por essa equipe, e sua experiência com tarefas semelhantes .

O valor dos Story Points concluídos em um Sprint não pode ser a base para comparar o desempenho de dois Times Scrum. Para evitar erros no gerenciamento de projetos Scrum, é importante lembrar que a Velocidade de um Time de Desenvolvimento expressa em Story Points feito em um Sprint não pode ser usada para comparar o desempenho de dois Times. Isso porque eles poderiam fazer o mesmo trabalho em Sprints paralelos, que uma equipe estimou em 10 e a outra em 50 pontos de história.

Também não se deve esquecer que a estimativa contém muitos elementos desconhecidos e é feita com base em dados incompletos. Por esse motivo, as previsões de um Time Scrum muito experiente às vezes podem ser muito diferentes do esforço real necessário para completar uma História de Usuário.

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.

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

• Planejamento de pôquer. Este método relativo mais popular leva um jogo de cartas para calcular a quantidade de trabalho para completar uma tarefa. São regras e processos detalhados que abordaremos em um artigo separado.
• Jogo de estimativa de equipe. Este envolve atribuir a execução de User Stories em um determinado Sprint com valores numéricos apropriados selecionados da sequência de Fibonacci. Também dedicamos um artigo separado para isso também.

O Scrum, por outro lado, rejeita a forma clássica de Estimação Absoluta da metodologia tradicional de gerenciamento de projetos. A forma como estima as tarefas é definindo antecipadamente a pessoa-mês, a duração e o custo de todo o projeto. Este é um processo longo, de difícil implementação, e que requer a participação de especialistas que tendem a estabelecer a lógica e o código de conduta, mas não tomam nenhuma ação que não necessariamente executará as tarefas cujo valor eles 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 todos os times Scrum maduros. Estimar a quantidade de tempo e esforço necessários para completar tarefas individuais tornou-se o foco principal de muitas técnicas de estimativa relativa, como Planning Poker ou Team Estimation Game.

Histórias de usuário com pontos de história é outra técnica de medição eficiente que descrevemos, esperamos fornecer aos nossos leitores algumas ferramentas úteis. No entanto, é importante ter em mente que seus números referem-se apenas às tarefas específicas executadas pelo Time Scrum. Portanto, o número de Story Points 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.

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