Você deve reestimar as histórias de usuários?

Meu projeto atual está tendo uma 'discussão' que é dividida no meio - "essa história é mais complexa do que pensávamos originalmente, devemos re-estimar" vs ", que você nunca deve re-estimar, pois apenas estima e aumenta e diminui " .

Alguém pode esclarecer se você deve reestimar?

IMHO Eu imagino que você possa trazer um cartão totalmente novo para um novo requisito ou história, mas voltar e re-estimar os itens da lista de pendências parece distorcer o conceito de tamanho relativo e só 'inflará' sua lista de pendências.

Uma parte central da estimativa de histórias em uma equipe em que trabalhei foi a ideia de uma história que era "grande demais" para ser estimada. Ou seja - a carga de trabalho implícita na história estava além do escopo de um único sprint.

À medida que mais informações chegavam, ou a equipe entendia melhor o que, a princípio, parecia uma única besta de uma história, freqüentemente reestimamos a história. Na maioria dos casos, isso pode envolver a quebra da história "grande demais" em histórias menores e realizáveis ​​e a estimativa delas.

Essas histórias “grandes demais” nunca foram para números de tamanho ou para queimar gráficos.

Além disso, podemos voltar a uma história mais detalhada e, com uma melhor compreensão dos requisitos, poderíamos reestimar. Você não deve reestimar uma história simplesmente porque ela se tornou mais fácil de ser alcançada (por exemplo, após a criação de várias bibliotecas de estrutura, uma parte dependente do trabalho será mais fácil de ser alcançada), porque a idéia é que, à medida que você se torna ' melhor ', a equipe pode conseguir mais em um sprint, mas certamente acho que é válido reestimar as histórias se sua compreensão delas mudar.

O seguinte seria um comentário, mas eu me empolguei ...

Não se esqueça de distinguir entre tamanho e complexidade na sua estimativa. Você deve estimar apenas o tamanho, não a complexidade ou a dificuldade. Por exemplo - adicionar um botão a uma tela deve sempre ser um '1', pois, para o usuário, ele está recebendo um botão - o tamanho é muito baixo. Não importa se você realmente o implementa em C # (baixa complexidade, muito fácil) ou Assembly (alta complexidade, muito difícil); a história do usuário tem o mesmo tamanho.

Então, quando eu digo que vale a pena re-estimativa de quando as mudanças de compreensão, não é que a sua compreensão de como implementar o recurso mudou, é a sua compreensão do que o recurso é que mudou.

Portanto, "quero um botão" é fácil, mas mais tarde você percebe que o usuário significa "quero um botão clicável , que fica verde e exibe uma mensagem ao usuário , agora é uma história mais complexa e, portanto, deve ser re estimado.

Atualização ; conforme solicitado, tentarei elaborar o que quero dizer com estimativa de 'tamanho' em vez de complexidade.

Eu acho mais fácil considerar essa distinção em termos de um novo produto. Sua equipe está encarregada de criar um sistema de várias telas, onde tudo é novo. Entre suas histórias de usuário, você tem uma série de histórias como;

1) Quero um botão na Tela A que, quando clicado, mostrará um erro para usuários não autorizados. 2) Quero um botão na Tela B, que quando clicado mostrará uma mensagem se o dia atual for um fim de semana. 3) Quero uma opção de menu na Tela C, que quando clicada fará com que a tela pisque a cada 5 minutos.

Agora, quando a equipe estima essas histórias, elas concordam que são todas aproximadamente do mesmo tamanho e estimam cada uma como uma história 'pequena', valendo 5 pontos em sua escala de velocidade de sprint.

Os sprints começam e, para o primeiro sprint, a equipe não consegue nenhuma dessas histórias, porque passa todo o ciclo configurando projetos, infraestrutura, bibliotecas principais, etc. E há um cara novo na equipe que ainda está aprendendo.

Alguns disparos, e a equipe monta uma tela que cumpre a História 1 - dias felizes, eles agora alcançaram 5 pontos de velocidade. (Com uma média de, digamos, 1 ponto por sprint, devido aos sprints improdutivos no início).

Agora, para o próximo sprint, a infraestrutura está no lugar, a equipe tem um modelo de tela para reutilizar e o novo cara está pensando em tudo, e nesse sprint, a equipe acaba com a História 2 e 3.

Agora, eles alcançaram 10 pontos em um sprint, com uma média de cerca de 4 pontos por sprint. Isso mostra que a produtividade da equipe está melhorando ao longo do tempo, o que é totalmente esperado, à medida que o projeto evolui, a equipe aumenta, o código principal é reutilizado (não reescrito).

Isso para mim é o ideal. Histórias bem estimadas, demonstrando um aumento de velocidade ao longo do tempo (que, eventualmente, você alcançará o nível mais alto, a menos que algo importante mude - como um novo membro da equipe, etc.).

Por outro lado, se logo no início, a equipe analisou essas histórias e as estimou com base na complexidade, elas descobririam que a História nº 1 é uma GRANDE história, pois estão considerando todos os esforços de aceleração, mais a cara novo que precisa de treinamento. A história nº 2 é MÉDIA, porque eles acham que estarão pelo menos a caminho e deve ser mais fácil. E finalmente, a história nº 3 é PEQUENA, porque será fácil assim que as nºs 1 e 2 forem concluídas.

Agora, o que você acabou nesse modelo é simplesmente uma estimativa ofuscada de TIME; as estimativas estão considerando o quão difícil será e quanto tempo levará para que um trabalho seja feito e, como sabemos, isso é difícil na melhor das hipóteses. Nesse modelo, a velocidade é nivelada desde o início e você nunca poderá demonstrar uma melhoria no desempenho da equipe. Se você estimar a tempo, só poderá conseguir 40 horas de trabalho em uma semana. E você seria tolo em planejar um sprint com mais ou menos trabalho. Se a equipe melhorar seus recursos, você poderá reservar apenas 40 horas de trabalho. Você só alcançará 40 horas de trabalho.

Por isso, observei que um trabalho em C # é mais fácil do que um trabalho em Assembly (menos complexidade), mas que o 'tamanho' da tarefa deve ser estimado de forma equivalente. Dessa forma, você pode ver que a escolha de mover idiomas, melhorias na capacidade (ou ajustes em alguma outra dinâmica da equipe) tem um impacto direto na velocidade.

[ Outra atualização: abordando a priorização ]

Quanto à priorização, acredito que esta seja uma discussão separada para dimensionar / estimar. Você não prioriza a fila simplesmente com base nas estimativas de uma história; caso contrário, apenas realizaríamos pequenos trabalhos, e nunca os maiores, [possivelmente] mais importantes. Em uma equipe que liderei, rotineiramente tínhamos conversas sobre complexidade ao gerenciar uma fila de sprint. O PO deveria entender que, embora uma tarefa seja uma tarefa "PEQUENA" (nos pontos da história), pode ser difícil de obter devido a X, Y, Z. Às vezes, a velocidade da equipe seria afetada, a fim de implementar algumas dessas histórias mais complexas. Outras vezes, o PO dizia "bem, eu prefiro ter outras 5 coisas neste sprint, então adiaremos os trabalhos mais complexos".

Se simplesmente estimassemos histórias em dificuldade, isso estaria escondendo a velocidade. Tarefas difíceis ou demoradas sempre teriam mais peso, a fim de tornar a velocidade média. Como observei antes, essa é apenas uma forma diferente de estimativa de tempo, e não há velocidade de rastreamento de ponto se esse for o seu método de estimativa, como você sempre tem uma duração fixa para um sprint, então sua "velocidade" só mudaria se você estimado incorretamente (por exemplo, uma tarefa de 8 horas demorou 1 hora).

Espero que isso esclareça um liitle?

A principal razão pela qual não recordo é que isso destrói a utilidade da sua velocidade. Considere uma equipe de scrum hipotética que estima cada história como 1 ponto. Eles completam aproximadamente 10 histórias a cada iteração, para uma velocidade média de 10.

Durante uma retrospectiva, um membro da equipe argumenta que, em retrospectiva, quando você olha para quase todas as iterações, uma das histórias realmente deveria ter sido um ponteiro de 5, então eles deveriam apontá-la para "fixar" sua velocidade. Isso eleva a velocidade até 14.

No próximo planejamento, a velocidade sugere que eles possam assumir mais quatro histórias. Eles têm certeza de que isso não pode estar certo, porque há boas chances de que uma das histórias futuras que eles estimaram seja realmente um indicador de 5. Infelizmente, eles não têm idéia de qual. De repente, eles têm uma velocidade que é absolutamente inútil para o planejamento.

O fato é que, se eles mantiveram sua velocidade em 10, isso leva em consideração suas habilidades de estimativa. Se 10% de suas histórias nas iterações anteriores foram realmente cinco indicadores, as chances são de 10% de suas histórias nas iterações futuras serem subestimadas da mesma forma. Durante um longo período de tempo, tudo sai na lavagem.

Lembre-se de que a velocidade não tem unidades. Um número maior não é melhor que um número preciso e útil. Se você quiser se gabar, multiplique tudo por 1000 :-)

Resposta curta: o proprietário do produto pode fazer o que quiser com uma história - até o sprint em que a equipe se compromete a concluí-la.

Portanto, se a equipe quiser reestimar uma história para um sprint futuro, fique louco.

Quando você está no sprint, o trabalho (e a estimativa) são fixos.

Eu trabalhei dessa maneira em vários projetos e funciona muito bem. Se você estiver realizando um burn-down para o backlog do produto, atualize a estimativa ou, pelo menos visualmente, deixe claro que a alteração não é um caso de burn-up.

Parece que, nesse caso, se a estimativa estivesse muito errada, você cancelaria o sprint e começaria novamente. Obviamente, isso dependeria do scrum master e do proprietário. Quando não há como chegar perto da estimativa, precisamos ser honestos com o chefe e dizer a eles mais cedo para que as decisões possam ser tomadas.

Não há problema em reestimar os itens da lista de pendências, para cima ou para baixo. O desenvolvimento é um processo de aprendizado, portanto, espera-se que alguns itens futuros da lista de pendências se tornem mais simples ou mais complexos, dependendo do conhecimento adquirido em sprints passados.

Talvez a 'velocidade' (se usada pela equipe / empresa como uma métrica) não pudesse ser exatamente medida no caso de uma enorme re-estimativa, mas o mais importante é que os exercícios de re-estimativa afiariam as próprias estimativas da equipe em futuro. A chave a ser previsível é usar as informações mais atualizadas, sem restringir uma estimativa antecipada.