Eu já ouvi muitas explicações diferentes do que os Pontos de História significa e como usá-los. Quase todas as equipas Scrum os usam, mas não fazem parte do Guia Oficial Scrum. Este artigo tem como objetivo remover alguns dos pontos misteriosos em torno da história., Vou também partilhar os equívocos mais comuns que encontrei.
O que fazer História Pontos representam?
os pontos de História representam o esforço necessário para colocar um PBI (Produto Item Backlog) ao vivo. Cada ponto da história representa uma distribuição normal do tempo. Por exemplo, 1 ponto de história pode representar uma gama de 4-12 horas, 2 Pontos de História 10-20 horas, e assim por diante., Esta distribuição temporal é desconhecida durante a estimativa. Usando o PBI de referência para estimar, não é necessário saber quanto tempo leva. Você só quer ter uma indicação aproximada de quanto tempo o PBI vai levar para completar.
quais são os benefícios de usar pontos de História?
os pontos de História permitem a uma equipa:
- estimar rapidamente as questões. A estimativa é relativa a itens de atraso de produto já concluídos. Isto é mais rápido do que estimar sem qualquer referência.
- estimativa sem indicar um compromisso Temporal específico., Ao estimar em horas, você faz um compromisso de tempo preciso. Estimar em pontos de História impede dar um compromisso exato. Ninguém sabe exactamente quantas horas está a nomear para uma questão específica.abrace a incerteza que vem com a estimativa. Os pontos de história especificam um intervalo de tempo desconhecido. Selecionar a partir de uma seqüência específica de pontos de História Fibonacci nos permite capturar a incerteza.
- precisa o suficiente para planejar Sprints à frente. Isto permite-nos gerir melhor as expectativas de tempo das partes interessadas para o trabalho futuro.,
12 erros Comuns ao usar os Pontos de História
- Equiparando História Aponta apenas a complexidade, a incerteza, ou o valor de
Alguns PBI pode ser complexo e não precisar de um monte de tempo. Um PBI envolve a implementação de um algoritmo sofisticado. A equipe já fez isso antes, então eles serão capazes de fazê-lo rapidamente. O oposto também pode ser verdade, um PBI simples que leva muito tempo. A equipe precisa refaturar um pequeno pedaço de código, afetando um monte de funcionalidade. Como resultado, muita funcionalidade precisa de regressão testada, o que levará muito tempo.,
a incerteza na estimativa é capturada no ponto da história da própria sequência Tipo Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100. A escolha de um número específico a partir desta sequência reflecte a quantidade de incerteza. Naturalmente, se a incerteza for demasiado grande para estimar, você pode usar o ‘?’ cartao.
pontos de história não contam nada sobre o valor de um PBI. Os pontos de história fornecem uma estimativa aproximada. Pode ser que este item seja extremamente valioso, ou que não acrescente qualquer valor. Os pontos da história ajudam a determinar o ROI de um PBI., Você pode usar pontos de história para levar em conta o esforço para entregar essa funcionalidade juntamente com o valor. Mas como o valor também é incerto, não se considere rico ainda.
os pontos de história são sobre esforço. Complexidade, incerteza e risco são fatores que influenciam o esforço, mas cada um por si não é suficiente para determinar o esforço.2. Traduzindo histórias aponta para horas
traduzindo histórias aponta para horas, você pára de se beneficiar da velocidade da estimativa relativa. Começas a trabalhar em horas e arriscas-te a comprometer-te., Ele fornece um falso senso de precisão como você reduz um ponto de história com um intervalo de tempo de 10-20 horas para um número preciso como 15 horas. Será mais difícil chegar a um acordo em estimativas quando você trabalha no exato Reino das horas.3. Média de pontos de História
em uma sessão de poker de planejamento, metade da equipe estima um PBI em 3 pontos de História e a outra metade em 5 pontos de História. É fácil resolver a discussão colocando apenas 4 pontos de história como estimativa. A equipe não deve fazer isso porque mais uma vez tenta fornecer um falso senso de precisão., A questão não é ser 100% preciso. A questão é ser preciso o suficiente para planear com antecedência. Além disso, pode perder uma discussão valiosa ao fazer uma média. Talvez 5 pontos de história fosse uma estimativa melhor.4. Ajustando estimativas de pontos de história de problemas durante o Sprint
Quando a equipe começa a trabalhar em um problema, a equipe não deve ajustar a estimativa de ponto de História. Mesmo que a estimativa deles fosse imprecisa. Se a estimativa foi imprecisa, é parte da velocidade final do Sprint. É normal que as estimativas sejam por vezes erradas., Você não perderá esta informação, e fará parte da velocidade histórica de uma equipe.5. Nunca erros apontadores de histórias
um erro não relacionado com o Sprint actual deve ser apenas uma história apontada. O bug representa o trabalho que a equipa precisa de completar. Isto não se aplica se a equipe reserva uma porcentagem fixa de tempo para trabalhar em bugs durante o sprint. Um bug relacionado a um problema no sprint não deve ser a história apontada como parte da estimativa original.6. Adicionar pontos de história para pequenas tarefas
Um pequeno ponto para investigar algo deve ser apenas encaixotado no tempo., É claro que vai levar 4 horas para fazer, e não há necessidade de trazer quaisquer pontos de História na mistura.7. Ajustando cada Sprint do PBI de referência
Quando uma equipe ajusta cada sprint do PBI de referência, a velocidade de diferentes Sprints não é mais comparável. A equipe perde informações que você não pode mais usar a velocidade histórica para planejar com antecedência. É melhor usar uma gama de PBI recente como referência.8. Story Pointing unfinished issues again
When moving an unfinished PBI to the next sprint, it is not necessary to re-estimate., A estimativa pode não ter sido precisa, mas isso não é nenhum problema. Como resultado do planejamento do Sprint, a equipe saberá todas as tarefas necessárias para completar a questão. A estimativa destas tarefas é em horas. Assim, no próximo Sprint, a equipe saberá quanto tempo ainda é necessário para completar o PBI. O fato de que o PBI não foi concluído fará parte da velocidade.9. Ajustar a estimativa do ponto de história porque um desenvolvedor específico irá trabalhar nele
história apontando um PBI é relativo à história de usuário de referência e feito pela equipe., A história dos membros da equipe aponta o PBI e chegar a acordo sobre a estimativa em uma sessão de Poker de planejamento. Um PBI pode ser 3 pontos de história para um desenvolvedor sénior, mas 8 pontos de história para um desenvolvedor júnior. A equipe deve chegar a um acordo sobre o trabalho que representa para a equipe e usá-lo para o planejamento. Você não deve ajustar os pontos da história porque uma pessoa específica fará o trabalho. Talvez quando começarem a trabalhar no assunto, o desenvolvedor Sénior esteja a trabalhar num problema de produção. Pode então ser necessário para o desenvolvedor júnior pegá-lo.10., Nunca ajustando a referência de PBI
Quando a composição da equipe muda ,isso pode afetar as estimativas de velocidade e ponto de História. Ambos dependem da equipa que executa o trabalho. Imagine a sua história-apontou a questão quando dois programadores Seniores estavam presentes. Quando você quer começar a trabalhar nestas questões, ambos deixaram a empresa. Agora dois novos desenvolvedores Júnior estão na equipe. É uma boa prática estabelecer uma nova história de Utilizador de referência em que toda a equipa trabalhou., Isso garante que todos estão na mesma página quando a história aponta, e dá à equipe algum tempo para estabelecer uma nova velocidade. À medida que a equipe se torna mais madura e melhor na estimativa, pode ser uma boa ideia estabelecer uma nova referência PBI’S.
11. Em conformidade com o perito da sala.ao planejar o Poker, há o risco de que a equipe esteja em conformidade com o óbvio especialista da sala. Uma maneira de resolver isso é deixar o especialista elaborar sobre o trabalho. Então, faça o resto da estimativa sem o perito. A formação de competências específicas é inevitável., Não deixe que isto quebre o fato de que a estimativa é um esforço de equipe.12. Não discutindo questões incorretamente apontadas em retrospectiva.
de vez em quando, a história da equipe aponta um problema onde é claro que a estimativa estava completamente errada. É importante discutir estas questões e tentar aprender, por isso as estimativas futuras são mais precisas. Numa das minhas equipas, esquecemo-nos de levar em conta a criação de dados de teste ao estimar. Então, fizemos um ponto especial para discutir para cada questão se a criação de dados de teste era aplicável., Quando aplicável, gostaríamos de perguntar se eles tiveram em conta a criação de dados de teste. Isto melhorou muito as nossas estimativas.
conclusão
o conceito de pontos de história é simples, mas difícil de aplicar. Quase todas as equipas Scrum os usam, mas não fazem parte do Guia Oficial Scrum. Por causa disso, as pessoas têm opiniões diferentes sobre como você deve usá-las. O termo Story Point em si já é confuso, como você pode usá-lo para tipos de trabalho que não Histórias de usuário. Além disso, “ponto” sugere que um ponto de história representa valor., Como referiu um colega, talvez o termo “Factor de planeamento” ajude a reduzir a confusão que muitas pessoas sentem. Estar ciente dos erros que podem ser feitos ao usar pontos da História ajuda a aplicá-los da maneira correta.
