Os tamanhos do Story Point para tarefas repetitivas mudam depois que você automatiza a tarefa?

Aqui está a situação do Scrum:

1. Uma determinada tarefa (implementar uma tabela de dados preenchida de back-end) é uma história frequente
2. As tabelas frequentemente têm funcionalidade semelhante, mas personalizada
3. Cada tabela leva cerca de uma semana para ser implementada (8 histórias)
4. Eventualmente, a equipe investe 4 semanas para criar um componente reutilizável
5. Agora, criar uma nova tabela é quase instantânea

Minha pergunta: uma nova história da tabela ainda é 8 porque a saída / complexidade não mudou? Ou é 1 porque o esforço é mínimo?

Minha pesquisa: Quando fiz o treinamento de scrum com Jeff Sutherland, saí com o entendimento de que a história ainda é um 8 porque os pontos da história medem a produção. O PM ainda está recebendo as mesmas tabelas, elas estão sendo entregues 5x mais rápido. É uma melhoria genuína da velocidade (fazendo o mesmo trabalho, mas mais rápido)

Mas gostaria de verificar se meu entendimento está correto. Alguma ajuda por aí? Estamos procurando a definição formal de scrum, btw. Eu pesquisei no site da scrum inc e passei por "A arte de fazer o trabalho duas vezes na metade do tempo" e não consigo encontrar documentação de que meu entendimento está certo ou errado.

Obrigado!

Atualização Eu estava realmente procurando por links para documentação pelas autoridades formais do scrum. Penso que esta pergunta é enganosa agora, porque muitas das respostas abaixo são apenas opiniões das pessoas.

ATUALIZAÇÃO 1/22: RESPOSTA SCRUM INC

"Permanece o mesmo para representar entrega de valor igual. A velocidade da equipe é uma medida-chave. Sua melhoria no processo deve resultar em aumento da velocidade: https://www.scruminc.com/velocity/ " --- Resposta Scrum Inc. via Twitter

MINHA RESPOSTA CURTA:

O Dr. Jeff Sutherland, criador do Scrum, responde a essa pergunta diretamente em seu Webinar Points vs. Hours no slide 6

O que são pontos? Os pontos são uma medida do resultado da equipe. Correlacionado com, mas não necessariamente, o mesmo que esforço.

JJ Sutherland, CEO da Scrum Inc. responde ainda mais diretamente em sua lição sobre Como obter a velocidade certa

Só porque a equipe melhorou na implementação de qualquer história, o valor em pontos que você deve permanecer o mesmo.

MINHA RESPOSTA LONGA:

Fontes adicionais. Como essa pergunta é controversa, aqui estão as pesquisas que respondem a algumas das preocupações expressas em outras respostas:

Sim. O objetivo do Scrum é aumentar a velocidade

Fonte 1

Embora a velocidade tenda a oscilar ao longo do tempo, como regra, ela deve subir cerca de 10% por Sprint. - JJ Sutherland

Fonte 2

O slide 5 da lição sobre velocidade do Scrum Inc mostra um gráfico de velocidade com uma melhoria de 12x ao longo do tempo E intitula o gráfico "Melhoria de saída" com "Pontos" como o eixo y:

Fonte 3

Acesse ScrumLab.scruminc.com e consulte os webinars da Metrics. Ele mostra como medimos o desempenho da empresa usando melhorias na velocidade, na métrica de felicidade e na receita por ponto. Eu ouço tantas equipes lentas reclamando que ir mais rápido só gera mais porcaria. Isso ocorre porque os proprietários do produto não são responsabilizados pela duplicação da receita por ponto. Se você dobrar a velocidade e dobrar a receita por ponto, a empresa gerará quatro vezes mais dinheiro. Isso fará todos felizes. É por isso que você precisa das três métricas. - Jeff Sutherland

Sim. Pontos de História Medem Saída / Produção

Fonte 1

A métrica de gerenciamento da entrega do projeto precisa ser uma unidade de produção Jeff Sutherland em seu artigo definitivo Por que os pontos da história são melhores que as horas

Fonte 2

Se a equipe começar a estimar histórias com valores mais baixos, porque eles adquiriram substancialmente mais experiência e as histórias parecem mais fáceis, o Velocity nunca parecerá melhorar. Essa é uma grande razão pela qual a estimativa em horas não funciona. - CEO da Scrum Inc, JJ Sutherland

NÃO. Aumentar a velocidade não estraga a previsibilidade

Antes de tudo, como um PO ou previsibilidade executiva é muito importante, mas a produtividade é ainda mais importante. A maioria dos pedidos de compra, se escolhidos entre manter os níveis de produção ou melhorar significativamente a produtividade à custa de uma pequena previsibilidade, escolheria o aumento da produtividade. Dito isso, a troca é uma escolha falsa se uma equipe empregar o padrão de scrum de ontem recomendado para o planejamento de sprint.

Usando o bom senso ... se uma equipe produz 10 widgets por semana, encontra uma maneira de produzir 40 widgets por semana; sua velocidade melhorou 4x. O pedido está obtendo 4 vezes mais widgets na mesma quantidade de tempo. Chamar essa velocidade plana é contrária à definição da palavra.

SIM. Jogar o sistema é possível se toda a equipe trapaceia

Finalmente - é possível jogar no sistema, mas é possível jogar em qualquer sistema. O Scrum minimiza as histórias de coleta de cereja dos desenvolvedores individuais, retirando de uma lista de pedidos pendentes e medindo a velocidade em equipe, e não em desenvolvedores individuais. Se você medir dev pela velocidade do dev, não estará fazendo o scrum. E mitiga o sistema de jogo por meio de estimativas, organizando histórias como um grupo. Para poupar suas estimativas, você deve fazer isso na frente do grupo e o grupo deve conspirar com você. Mas se você quiser jogar o sistema, não importa realmente qual processo você usa. O Scrum depende de uma equipe de 4-6 funcionários capazes e motivados, interessados ​​em atingir objetivos juntos; mas se você tem funcionários que estão trapaceando no trabalho de burlar o sistema, seu processo não é o problema.

Suas histórias de tabela de back-end não exigem mais oito pontos de esforço.

"Um Story Point é uma unidade de medida relativa, decidida e usada por equipes individuais do Scrum, para fornecer estimativas relativas de esforço para o preenchimento de requisitos"

scrum.org

Se você continuar estimando as histórias da tabela de back-end em oito pontos, distorcerá sua velocidade como uma medida do esforço por sprint.

Também seria falso continuar atribuindo oito pontos ao trabalho que você sabe que requer apenas um ponto de esforço.

Aumentar a velocidade não é um objetivo. O objetivo é um planejamento confiável.

Os pontos da história são uma ferramenta em um ciclo de feedback que informa, ao longo do tempo, qual é a sua velocidade típica. Isso mostrará quantos pontos você pode adotar realisticamente em um sprint. A velocidade pode variar um pouco com o tempo, mas se mudar muito rapidamente é inútil. Um aumento repentino na velocidade diria apenas que você ainda não sabe o que está fazendo. Então, você deseja manter a velocidade constante, o que indica que suas estimativas foram boas e provavelmente serão boas para o próximo sprint.

Você sabe que sua saída não é constante; você está ciente do fato de que pode criar tabelas muito mais rapidamente agora. Portanto, isso anularia totalmente o objetivo do seu ciclo de planejamento, se você insistir em vincular pontos da história a resultados.

Novamente, a velocidade não está relacionada à produtividade e um aumento da velocidade não é motivo para comemorar. Um ponto da história é, em última análise, um pedaço do seu sprint. Para torná-lo mais real, algumas equipes definem uma tarefa conhecida que todos entendem e chamam de tarefa padrão de story story, para que qualquer trabalho possa ser relacionado à tarefa padrão em termos de complexidade e consumo de tempo. Escusado será dizer que se a tarefa padrão se tornar mais fácil, tudo mudará e todos terão que se adaptar ao novo significado de um ponto da história, o que é péssimo. O caminho certo e conveniente a seguir seria definir uma nova tarefa padrão igualmente desafiadora para a equipe.

Os pontos da história refletem quanto esforço será necessário para implementar a história. Eles são uma previsão de esforço. Se a quantidade de esforço diminuir, o número de pontos também deve ser.

Lembre-se, os pontos são uma ferramenta para ajudá-lo a estimar. Nada mais nada menos. Eles não são uma recompensa ou uma métrica que mede a produção. Eles são simplesmente uma maneira de estimar quanto trabalho será envolvido na consecução do objetivo da história.

Você diz que essa tarefa originalmente levou 8 pontos, o que equivale a cerca de uma semana. Agora, digamos que seus sprints duram uma semana, portanto, no planejamento, você deverá retirar 8 pontos em histórias. Se você mantiver essa história em 8 pontos, poderá planejar apenas terminar essa história no sprint. Se o tempo real é de apenas uma hora em vez de 40 horas, o que você fará nas outras 39 horas? Você acabou de criar um plano muito ruim para o seu sprint por causa de pontos imprecisos da história.

se a história for representada com mais precisão como um ponto, isso significa que você ainda poderá obter mais 7 pontos no sprint atual de uma semana. Isso parece refletir mais de perto a sua realidade, portanto, mudar o tamanho da história faz sentido porque ajuda a planejar.

Você menciona na sua pergunta um desejo de melhorar a velocidade, mas isso não é realmente o que você deveria estar fazendo. Pelo menos, não no sentido literal. Sua produtividade aumentará naturalmente, mas, para planejar, seu valor de velocidade deve permanecer razoavelmente constante.

Pense nos efeitos. Digamos que você tenha uma equipe de cinco, uma velocidade de 100 pontos em uma corrida, e espere razoavelmente que todos mantenham 20 pontos. Agora você tem essa tarefa que se tornou trivial, mas ainda obtém oito pontos. Um membro da equipe pega cinco dessas tarefas, realiza-as em dois dias, coloca os pés sobre a mesa pelos oito dias restantes, bate em todos ao lidar com 40 pontos de tarefas e recebe um bônus. Todo mundo é mordido pelo chefe.

Se você estiver satisfeito com isso, não altere os pontos desta tarefa. Eu não gostaria dessa situação.

Todas as tarefas com o mesmo número de pontos devem levar um desenvolvedor pela mesma quantidade de tempo.

E eu discordo totalmente com a resposta de Nathaniel aqui. Manter os pontos tornaria a velocidade totalmente imprevisível, porque algumas tarefas serão executadas mais rapidamente, mas outras não, portanto, um sprint com tarefas aceleradas fornecerá uma velocidade enorme, e o próximo sprint novamente.

Também não é como você estimaria. Se sei que tenho dez tarefas bastante semelhantes, em primeiro lugar não lhes dou os mesmos pontos. Dou muitos pontos ao primeiro, destinado a "executar as tarefas e criar as ferramentas para executar tarefas semelhantes muito rapidamente", e muito menos pontos às tarefas repetidas.

É uma situação diferente quando um desenvolvedor júnior inicia, ou um desenvolvedor se junta a uma equipe diferente, e aumenta sua velocidade em outro momento porque eles aprendem (como fazer seu trabalho em primeiro lugar, ou todos os bits que precisam saber sobre o determinado projeto).