Sem pontos de crédito para histórias incompletas --- I notice this text is already in Portuguese. If you intended to translate from another language, please provide the source text in the original language (such as English or German), and I'll translate it to Portuguese for you.

Foto de Mike Cohn
Mike Cohn
2 Min. Tempo de Leitura
Este conteúdo foi traduzido com IA. Ver original

Estar perto só conta no jogo de ferraduras e com granadas de mão. Esta é a minha resposta à pergunta se histórias quase concluídas devem ser incluídas no cálculo da Velocity. A seguir, quero explicar por que vejo as coisas desta forma.

O problema das histórias inacabadas

Quando uma equipe conclui muito, mas não tudo, ao final de um Sprint, normalmente quer receber crédito por parte desse trabalho. Então argumentam, por exemplo, que o trabalho está 90% concluído e que isso precisa ser contabilizado.

Mas uma equipe só faz isso quando há Story Points suficientes em jogo. Completar uma história em 90% que valeria apenas um Story Point não compensaria. Afinal, receberiam apenas 0,9 pontos na Velocity. Com User Stories que renderiam 8, 13 ou 20 pontos, a situação é bem diferente. Essas histórias geralmente são simplesmente grandes demais para serem totalmente concluídas em apenas um Sprint.

As equipes frequentemente ficam irritadas quando o Scrum Master não permite a contabilização de trabalhos inacabados. Então pensam: "Você vai ver o que ganha com isso." Naturalmente, querem mostrar a ele o quão estúpida é essa regra, completando sempre todas as histórias. Para isso, porém, as histórias precisam primeiro ser divididas em partes menores. Aliás, essas são todas coisas que o Scrum Master acha boas! Uma vantagem dessa regra rigorosa é, portanto, que as equipes dividem as histórias em partes menores e se esforçam mais para concluir tudo em um Sprint.

Na experiência, porém, isso também leva a um grande problema. Ou seja, a maioria das equipes superestima seu progresso. Afirmam, por exemplo, já ter concluído 90%, quando na realidade são apenas 70%.

Infelizmente, parece bom reportar mais progresso – afinal, assim é possível alcançar uma Velocity mais alta. No entanto, a sensação boa não vai durar muito. Quando se quer estimar, com base na Velocity média da equipe, quanto tempo ainda será necessário para o trabalho restante, o esforço será subestimado drasticamente.

Então uma equipe nunca pode contabilizar trabalhos iniciados no cálculo da Velocity?

Pode sim. Se os membros da equipe perceberem cedo o suficiente que uma história não será concluída neste Sprint e a dividirem, podem contabilizar as partes concluídas. Mas isso precisa acontecer cedo o suficiente para que não possam simplesmente trapacear para conseguir uma Velocity mais alta. Dividir uma história no último dia na proporção de 90% para 10% é apenas uma tentativa de conseguir mais alguns Story Points. De modo geral, pode-se dizer que tal divisão só deve ser feita enquanto nenhuma parte da história estiver concluída. O Scrum Master deve sempre incentivar os membros da equipe a serem honestos consigo mesmos – afinal, eles sabem melhor do que ninguém se estão trapaceando.

Este texto é do blog de Mike Cohn e foi traduzido por nós para o alemão.

Mais sobre este tema

DevOps

Este artigo explica as vantagens e desafios na implementação de DevOps e o que significa utilizar DevOps na empresa.

Quadro Kanban

O que é um Kanban Board e como se define o trabalho com um Kanban Board? O Glossário Ágil da Agile Academy explica como usar e trabalhar com ele!

Regra de Las Vegas

A expressão "O que acontece em Las Vegas, fica em Las Vegas" é um termo popular em filmes e equipes para manter segredos. Explicamos a origem

Fale com nosso assistente Fale com nosso assistente