Qual é a melhor maneira de estimar pontos da história no scrum?

Gosto da maneira como o planejamento do pôquer funciona no início de qualquer projeto, permitindo comparar e discutir detalhes de cada história.

Um dos problemas que notei com isso é que, com o tempo e à medida que você ganha mais experiência com o domínio do problema, você tende a votar menos pontos em cada história, ou seja, uma história que valia 5 ou 8 no início do projeto agora pode valer 3.

Como você evita ou lida com esse problema da melhor maneira possível? Existe uma maneira melhor de estimar? As histórias devem sempre permanecer as mesmas ou os pontos da história diminuem, ok?

Eu não acho que isso seja um grande problema.

Existem duas coisas óbvias que podem estar causando isso. Uma é que você está experimentando uma leve deflação de pontos. A outra é que sua equipe está realmente ficando mais rápida. (Espero que seja o último!)

De qualquer forma, não deve ser grande coisa. Os dois principais usos da velocidade são descobrir quanto trabalho executar na próxima iteração e fazer estimativas aproximadas das datas de entrega para grandes partes do trabalho. Nenhum deles é prejudicado por uma velocidade gradualmente variável. De fato, se a velocidade aprimorada vier a melhorar, seus novos números apresentarão uma imagem mais verdadeira da capacidade da equipe.

Se a velocidade está mudando muito rapidamente para o conforto, uma resposta são as histórias canônicas. Passe pelos últimos dois meses, escolhendo três histórias para representar os níveis de pontos usados. Coloque-os na parede onde você faz estimativas. Então, como você estima, use-os como comparação com a história com a qual está lidando. Isso deve reduzir a deriva e a volatilidade em suas estimativas.

Fundamentalmente, isso não é realmente um grande problema, pois a maioria dessas coisas sai na lavagem. Em geral, a manipulação explícita do resultado das estimativas será negativa para o processo. A estimativa de pontos da história funciona melhor quando as equipes ficam de olho na bola - você está estimando a complexidade relativa das histórias em comparação com outras histórias e, desde que você tenha informações históricas em mãos para as histórias completas, provavelmente verá as coisas se resolverem a longo prazo. Aqui é um lugar em que a coesão da equipe traz benefícios, pois a equipe eventualmente se estabelecerá em métodos e histórias de referência para a estimativa da história.

A deflação do ponto da história pode ser um problema moderado, pois à medida que as estimativas do seu intervalo de pontos são compactadas, você começa a perder informações sobre o ajuste fino da velocidade e essa compressão pode ter efeitos negativos na estimativa do comprimento para liberação de longo prazo planejamento (na medida em que você multiplicará os erros introduzidos pela compactação de todas as suas histórias em um intervalo estreito). Em geral, você deseja que os resultados do aumento da velocidade, devido à experiência, sejam expressos como tendo mais pontos na história do que estimativas diminuindo. A maneira de combater isso é fazer referência contínua às estimativas concluídas anteriores e garantir que você esteja sempre estimando a complexidade. Nunca indique quanto tempo você acha que algo levará; basta comparar a dificuldade geral de uma história em comparação com as histórias anteriores. Deixei' s dizem que você tem um aplicativo que suporta plataformas móveis e precisa portar para outro. É semelhante a uma porta anterior? Mais difícil, porque a plataforma tem ferramentas piores? Mais fácil, porque você tem um depurador melhor? Isso deve informar suas estimativas, não o fato de que essa porta provavelmente será mais rápida porque suas equipes estão se adaptando bem às estimativas. Concentrar-se na complexidade deve ajudar a resolver esse problema, na medida em que exista um.