Olá Habr! Apresento a você a tradução do artigo
“Por que não uso pontos de história para o planejamento de sprint”, de Mike Cohn.
Conforme descrito em Estimativa e planejamento ágeis, sou um grande fã de histórias para avaliar os pedidos em atraso de produtos. No entanto, também recomendo avaliar o backlog do sprint em horas, e não em pontos da história. Por que essa aparente contradição? Escrevi anteriormente sobre os motivos. Eu recomendo usar diferentes unidades de medida (pontos e horas) para diferentes pedidos em atraso.
Mas muitas vezes me fazem uma pergunta relacionada, que quero fazer aqui:
Estou curioso para saber por que você não está usando pontos da história para o planejamento de sprints. Eu pensei que o ponto de medir a velocidade nos pontos da história era, em parte, determinar quanto podemos levar (ou consertar) no sprint. Você usa apenas pontos da história para o planejamento a longo prazo (por exemplo, planejamento de liberação)?Não uso pontos da história para o planejamento de sprint, porque os pontos da história são uma medida útil a longo prazo. Mas pontos não são úteis a curto prazo.
Seria apropriado que a equipe dissesse: "Temos uma velocidade média de 20 pontos na história e ainda temos 6 sprints, então terminaremos cerca de 120 pontos nessas seis corridas".
Seria inapropriado para a equipe dizer: "Temos uma velocidade média de 20 pontos na história, então terminaremos no próximo sprint". Isso não funciona.
Suponha que o time de basquete esteja no meio da temporada. Até o momento, disputaram 41 jogos e marcaram em média 98 pontos por jogo. Seria apropriado dizer: "Provavelmente, marcaremos uma média de 98 pontos por jogo no restante da temporada". Mas eles não devem dizer antes de nenhum jogo específico: "Temos uma média de 98, por isso, faremos 98 hoje". É por isso que digo que a velocidade é um preditor útil a longo prazo, mas não um preditor útil a curto prazo.
A velocidade varia de sprint para sprint.
É por isso que quero que as equipes planejem seus sprints observando o backlog do produto, escolhendo uma das coisas mais importantes que eles poderiam fazer, dividindo esse elemento / história do usuário do backlog do produto em tarefas e avaliando as tarefas, perguntando a si mesmas se podem compromissos de liberar esse item de lista de pendências do produto e repetido até que sejam preenchidos. Nenhuma discussão sobre pontos da história. Nenhuma discussão sobre velocidade. É apenas uma questão de obrigações, e decidimos o quanto podemos cumprir dividindo os pontos do backlog do produto em tarefas e avaliando-os.
Quando a equipe terminar de planejar o sprint dessa maneira, é provável que o número de pontos da história que eles estão buscando sem saber seja próximo ao seu valor médio, mas isso mudará.
Também será verdade que a equipe executará aproximadamente o mesmo número de horas de um sprint para o próximo. Utilizo o termo “capacidade” para me referir a este número de horas, porque a velocidade é reservada para se referir a uma medição do volume de trabalho planejado ou concluído, conforme indicado nas unidades usadas para avaliar a lista de pendências do produto (que eu recomendo usar pontos de história )
Sobre o autor: Mike Cohn é um dos autores da metodologia de desenvolvimento de software Scrum. Ele é um dos fundadores da Agile Alliance e da Scrum Alliance. Ele é especialista em ajudar as empresas a implementar e melhorar o uso de processos e métodos ágeis para criar equipes de alto desempenho.
Referências:
Estimativa e planejamento ágeis , Mike Cohn, 2005.
PS Você classifica o backlog do sprint em horas ou pontos da história?