estimativas Histórias em Scrum [fechado]

Question

Nós começamos um projeto que será gerido com Scrum / XP. Nós escrevemos todo o adiantado product backlog para fins de avaliação. Estamos certificando-se de todas as histórias são centrada no cliente e estamos avaliando-as por

• valor de negócios história : Moscovo técnica - deve, deve, poderia, seria / não terá este implementado
• esforço história / complexidade (= pontos da história): 1, 2, 3, 5, 8, 13, 21, 100 - relacionados com a complexidade história / esforço em vez de dias ideais duração

100 pontos da história pode ter algumas histórias com Would / Não vai ter, porque eles realmente são maiores histórias complexas que serão discriminados mais tarde, se necessário.

Calculado importância história é com base no valor e esforço por não se sobrepõem histórias Moscow.

Mas sem 100 histórias ponto nossas histórias até agora (também discriminados) tem complexidade entre 2 e 8, que nós pensamos que é um tamanho história apropriada para microgestão evitar. Mas algumas histórias tornou-se relacionado ou dependentes uns dos outros. Temos histórias que pode demorar mais se for feito primeiro, e menos se alguma outra história seria feito antes deles.

Perguntas
É possível ajustar pontos da história, mais tarde, durante o desenvolvimento, como podemos ver com tarefas história onde podemos reavaliar-los, adicionar, remover existente ou não é este o caso com histórias? Porque mudar sua complexidade, também vai mudar data final estimativas com base na velocidade planejada. Qual é a melhor prática neste caso?

Answer 1

Você absolutamente pode estimar suas histórias novamente e você deve. Os pontos só são bloqueados quando os commits equipe a eles no Sprint sessão de planejamento imediatamente antes do início de uma Sprint.

Uma prática que usei é quando se faz o indivíduo Sprint Planning você deve avaliar cada história novamente. A equipe aprende ao longo do tempo e vai se tornar mais precisas as estimativas e dependências de identificação. Lembre-se o que se passa em um Sprint está à altura da equipe, o proprietário do produto define o atraso geral. Se o projeto for tempo ligado não tentar fazer as estimativas caber a data final, se você fizer isso você está se preparando para o fracasso.

Lembre-se que com a velocidade que você comece com um palpite sobre o que você pode realizar. Geralmente não é até o 3º ou 4º Sprint que você bateu identificar uma velocidade realista que a equipe pode gerenciar. Sim isso não significa que você pode ter assumido a equipe poderia entregar 20 pontos por Sprint e realmente só pode fazer 15 pontos. Sim que o tempo de entrega meios sai ou histórias cair abaixo da linha de corte.

Quanto a histórias dependentes você deve trabalhar com o seu proprietário do produto. Se as negociações da equipe para eles geralmente você pode reorganizar histórias. A maioria das pessoas são receptivos a alguém que lhes diz "Se fizermos um agora vai levar a Sprint completo, mas se fizermos A tarde vai levar 15% de um Sprint", que faz com que seja bastante convincente.

A prática útil para tentar está programando as histórias dentro da Sprint. Durante a sessão de planejamento, uma vez todas as histórias são validados e discutidos os puxa equipa um calendário e discutir quando eles querem ter as coisas. Colocando as datas-alvo em um calendário que ajuda a identificar as sobreposições e as dependências entre as histórias. Isto pode identificar as coisas que são de série na natureza e pode causar um Sprint a falhar.

Espero que esta informação é útil.

Answer 2

De sua explicação você está fazendo um grande trabalho já. É claro que sempre haverá histórias com uma dependência. Alguns não podem mesmo ter valor para o cliente diretamente visível; isto é, o esforço inicial para definir-se uma arquitectura e algumas estruturas). Mas se você deixá-los fora você vai criar um monte de dívida técnica. Se você puder, eu sugiro que você tente fazer a equação completa e de alguma forma mostrar a relação entre as tarefas.

Por exemplo: -. A tarefa 3 é de 8 pontos se feito após a tarefa 2, mas 12 pontos, se feito de forma independente

Desta forma, o proprietário do produto vai sentir a dor de ignorar as dependências, mas ainda pode fazer uma escolha a fazer as histórias mais valiosos em primeiro lugar. Se o proprietário do produto é a certeza de que todas as histórias de fazê-lo nos próximos sprints, então você pode dirigir para tê-los implementado na ordem mais eficiente. Por exemplo, ao bloquear itens para os quais não foram cumpridas as dependências (ou seja, você só pode ter o 'mudar meu logotipo no site recurso depois que a história 'versão webenabled' está concluída.)

Boa sorte!

Answer 3

Eu só posso descrever a minha experiencia.

Quando estávamos planejando primeiro sprint decidimos que poderia realizar 18 pontos. Então pegamos várias histórias e estimativa total foram de 15 pontos. Como eu mencionei acima nós estávamos fazendo os primeiros passos no scrum e é por isso que decidimos que 3 pontos não utilizados e de fator de forma 0,6 garantido nosso sucesso.

Mas nossas estimativas de cada história foram apenas aproximados. Também tivemos algumas histórias dependentes. E nós não fizemos plano de implementação de cada história, porque nós pensamos que é unnessecary com metodologia ágil.

Como resultado, nós não o nosso primeiro sprint com apenas 8 pontos completos.

Antes de nossa segunda corrida eu decidi que devemos ter algo de bom e velho simples cascata e methodoligies iterativos (e eu era um scrum-master). Assim, em nosso planejamento próxima primavera para fazer estimativas corretas planejamos cada história (cerca de 20 minutos por história), com diagramas simples, todas as dependências, os detalhes de implementação e assim por diante. O planejamento foi difícil e levou 2 reuniões.

Mas a segunda corrida foi muito melhor e fizemos quase tudo (na verdade, nós fizemos tudo, mas com alguns bugs). Eu acho que nós vamos ter menos de fator de forma em 3º sprint e ele vai ser bem sucedido.

Answer 4

Existem alguns padrões que iria ajudá-lo na divisão User Stories de uma forma que eles permaneceriam INVEST, o que significa que você tentar salvar as dependências, o tamanho, a capacidade de teste e valor em particular. Você pode ler mais sobre isso aqui: http: // www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard está aplicando ativamente e melhorá-los, e ele não está sozinho; -)

Esteja ciente de que a divisão e dependências de manutenção (que é como criar um caminho crítico em um gráfico de Gantt) vai superar a capacidade da equipe para ser criativo, e para negociar sobre essas histórias, e também pode esconder uma " não valioso-proposição".

HTH
ANdreaT