Como medir a estimativa e pontos da história em Scrum? [fechadas]

Question

Vamos dar um exemplo, suponha que nós temos 5 histórias A, B e C, D, E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

As histórias são ordenados com base em sua importância (prioridade). Como você estimá-los? É estimado com base no tamanho do recurso? Por exemplo, eu lhes dei estimar valores:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Vamos supor que é um 2-semana sprint. Este é 14 dias de tempo size = 5,14x5 = 70 dias-homem. Agora, o que faz o valor 10 média? Será que isso significa quantidade de tempo (horas ou dias) uma equipe deve gastar? E o que são pontos da história? Suponha que este é o primeiro sprint; como você vai estimar o número de sprints, quando você não tem a velocidade da última corrida?

Answer 1

Argh! não me falha para escrever a partir da memória.

Um ponto da história está relacionada com a estimativa é claro, e quando você tenta descobrir o quanto você pode fazer para um sprint, um ponto da história é uma unidade de "trabalho" necessário para implementar parte ou uma característica todo. Um ponto história poderia ser um dia ou uma hora, ou algo entre os dois. Eu confundiu a "estimativa" e "ponto da história" abaixo, não sei o que eu estava pensando.

O que eu escrevi originalmente era "estima" e "pontos da história". O que eu pretendia escrever (e editado abaixo) foi "pontos da história" e "velocidade".

---

pontos da história e velocidade anda de mãos dadas, e eles trabalham juntos para tentar dar-lhe uma sensação de "quanto podemos concluir em um determinado período de tempo".

Vamos dar um exemplo.

Vamos dizer que você quer estimar recursos em horas, para um recurso que tem uma estimativa de 4 terá 4 horas para ser concluído, por uma pessoa, de modo que você atribuir uma estimativa tal a todos os recursos. Você considera, assim, que o recurso, ou a sua "história", no valor de 4 pontos quando se trata de competir por recursos.

Agora vamos também dizer que você tem 4 pessoas em seu projeto, cada um trabalhando uma semana normal de 40 horas, mas, devido a outras coisas acontecendo ao seu redor, como apoio, falando ao marketing, reuniões, etc., cada pessoa só vai ser capaz de trabalhar 75% sobre as características reais, os outros 25% serão utilizados nessas outras tarefas.

Assim, cada pessoa tem 30 horas disponíveis por semana, o que lhe dá 30 * 4 = 120 horas no total para essa semana, quando você contar todas as 4 pessoas.

Agora vamos também dizer que você está tentando criar um sprint de 3 semanas, o que significa que você tem 3 * 120 horas de valor do trabalho pode ser concluído. Esta é a sua velocidade, o quão rápido você está se movendo, quantos "pontos da história" você pode completar.

A unidade de sua velocidade tem para ele compatível com a unidade para seus pontos da história. Você não pode medir andares "quantos copos será o desenvolvedor (s) consomem durante a implementação deste" com "quantas horas temos disponível".

Você, então, tentar encontrar um conjunto de funcionalidades que, juntos, leva perto, mas não ultrapasse, 120 pontos, classificados por sua prioridade. Isso seria simplesmente a soma acumulada de cima e para baixo até chegar a uma tarefa que dicas a soma sobre, ou igual a, essas 120 pontos. Se inclinou sobre ele, não incluem a tarefa.

Você poderia facilmente estimar em dias, ou xícaras de café consumido pelo desenvolvedor, assim como o número é representativo para o tipo de trabalho que você está fazendo, e isso pode estar relacionado com o trabalho real que você irá executar ( ie. quanto tempo você tem disponível).

Você também deve avaliar a sua carga de trabalho após cada sprint para descobrir se esse número de 75% é preciso. Por exemplo, se você conseguiu apenas metade do que você se propôs a fazer, descobrir se suas estimativas de recursos estava errado, ou se as estimativas de carga de trabalho estava errado. Em seguida, tomar o que você aprendeu em conta ao estimar e planejamento para os seguintes sprints.

Observe também que recursos devem ser divididos se eles se tornarem muito grandes. A principal razão para isso é que as estimativas maiores têm muito mais incerteza construído para eles, e você pode atenuar que, dividindo-o em sub-recursos e estimar os. A característica geral grande, então se torna a soma de todos os sub-recursos. Ele também pode dar-lhe a capacidade de dividir a característica ao longo de várias pessoas, através da atribuição de diferentes sub-recursos para pessoas diferentes.

Uma boa regra de ouro é que os recursos de que têm uma estimativa mais de 1 dias provavelmente deve ser dividida. *

Answer 2

Lembre-se que os pontos são ROMs apenas (ordem aproximada de magnitude) estabelecidas através do uso de " Planning Poker " como uma prática comum. Os primeiros Sprints são quando você começa a identificar o que os pontos significam para a equipe e quanto mais tempo você for, mais precisa será a equipe recebe.

Além disso, olhar para usar os pontos que são um pouco mais espaçados. Uma prática que eu vi e usado é usar a fibonacci seqüência, ela garante que você não 't têm muitas diferenças 1 ponto.

Também não se esqueça testadores, quando apontando uma qualquer história fazendo testes necessidades de pesar como às vezes uma tarefa de desenvolvimento simples pode causar um grande esforço de teste e se eles são verdadeiros Sprints a idéia é ter tudo concluído como poderia ser enviado (construído, testado e documentado). Portanto, a estimativa de uma história é determinada pela equipe não por um indivíduo.

Answer 3

O valor 10 é apenas um valor relativo às outras estimativas, por exemplo, é metade tão duro como um 20 ou um pouco mais difícil do que a 9. Não há uma tradução específica de 1 ponto = x horas de esforço é algo a apontar.

Onde eu trabalho, temos o que chamamos de "pontos épicas", que é o quão difícil é uma história de alto nível, por exemplo. integrar a pesquisa em um novo site, que será composto de várias histórias para ser concluído e, em seguida, estimamos horas em cada história que é criado a partir de quebrar cada épica, por exemplo. basta colocar Pesquisa em documentos de suporte no site. Os "pontos épico" são distribuídos em uma variação de números de Fibonacci (1,2,3,5,8,13,21,28,35) para que épicos mais amplos e vagos apenas obter um grande valor, por exemplo, maior coisa que 8, é um indicador de que ele pode ser dividido em mais histórias facilmente estimáveis. Também vale a pena notar aqui que onde eu trabalho nós só trabalhamos 5 dias por semana e dentro de cada sprint um dia está perdido para encontros como o demo, reunião de planejamento da iteração, retrospectiva e revisão para que haja apenas 9 dias para um sprint. Acrescentando a programação em pares para algumas coisas, tempo para corrigir bugs e outros trabalhos não-projeto como tickets de suporte e torna-se bastante difícil dizer quantas horas serão gastos pelo punhado de desenvolvedores no sprint.

Os primeiros sprints são onde os valores começam a se tornar mais concreta como base a experiência adquirida, as estimativas podem tornar-se mais clara em termos de como adivinhar o valor.

Answer 4

Com uma nova equipe ou projeto que sempre começar por assumir um ponto da história é um único "dia ideal", e descobrir cada desenvolvedor recebendo cerca de 3,5 dia ideal por semana, que é a forma de calcular a nossa velocidade inicial provável.

Uma vez que você atravessou o palco "Planning Poker" e equilibrado / comparado todas as suas histórias, a duração real de um ponto da história do mundo real é realmente desconhecida - tudo o que você realmente tem é uma boa ideia bonita de relativa duração, e use o bom senso para chegar a uma velocidade provável.

Pelo menos, é assim que eu fazê-lo!

Se você também está apontando seus pontos da história em que é aproximadamente igual a um dia ideal, então eu sugiro quebrar suas histórias para baixo em histórias menores, caso contrário você não vai ter um bom tempo no planejamento e iterações de rastreamento.

Answer 5

boas respostas ao redor.

Um ponto que eu gostaria de acrescentar é que não é realmente importante que você escolha como uma base para o seu valor de pontos (horas, dias ideais, o que mais). O importante é mantê-lo consistente.

Se você mantê-lo consistente permitirá que você a descobrir "a verdadeira velocidade" de sua equipe. Por exemplo, digamos que você tinha poucas iterações:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

E agora você está começando a iteração 4 e você tem o seguinte no backlog (classificadas na prioridade):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

Agora, assumindo seus pontos estimativas são consistentes você pode estar razoavelmente certo de que a equipe vai terminar itens 1,2 e, provavelmente, 3 mas definitivamente não 4.

Você pode aplicar o mesmo a carteira de lançamento para melhorar a sua previsão de data de lançamento. Isto é o que permite que as equipes de Scrum para melhorar as suas estimativas à medida que avançam.

Answer 6

JB King tem a melhor resposta, mas nenhum voto, o que significa informação incorreta está sendo propagada e contribuindo para o geralmente pobre interpretação de scrum. Por favor, veja as respostas reais de uma das pessoas que projetaram Scrum aqui:

http: //blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Lembre-se, é sobre o esforço, não complexidade.

Agora, ler e assistir a um vídeo aqui:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points