Dúvida sobre estimativas

Oi Alex tudo bem?

No dia a dia não me preocupo muito não. O Scrum é para projetos complexos e é difícil mesmo estimar histórias.

É bom deixar anotado em algum lugar o porque não deu certo o sprint, geralmente anoto no site do Kanbam.

Espero ter ajudado!!!

Oi Alex Alves de Almeida

O que o mercado tem praticado é contabilizar na sprint que foi entregue e com os 13 pontos. Você poderia até re-estimar se perceber que errou muito, tinha uma complexidade muito maior que ninguém viu. Seria exceção e não regra e sua história que tinha 13 virou outro número.

Agora se foi algo que deixou de ser feito não.

Veja o exemplo abaixo suponha um backlog de 5 itens. história 1 => 10 pontos história 2 => 5 pontos história 3 => 11 pontos história 4 => 10 pontos história 5 => 12 pontos

Total de 48 pontos.

Na sprint 1, vocês falaram que iriam entregar as histórias 1, 2 e 3, totalizando assim 26 pontos.

No final da sprint ficou assim: História 1: fez 8 pontos de 10 História 2: fez 5 pontos de 5 História 3: fez 10 ponts de 11.

a sua velocidade de fato foi de 5 pontos, pois só entregou a história 2. Se começar a aceitar essa quebra e falar sua velocidade foi de 23, você vai começar a gerar disfunções. Como por exemplo: 1) Tem uma velocidade de 23 mas de fato não entrega valor para o cliente. (vide que só 1 história foi finalizada) 2) Começa a passar a ideia de que é aceitável começar muita coisa e terminar poucas. Seu time com o tempo pode começar a perceber que isso é aceitável e sair iniciando um monte de coisa e finalizando pouco. 3) Você verá nos seus gráficos vários picos, porque seu time na sprint A faz de fato uma qtd e inicia outra, para dar tempo de finalizar na próxima sprint. 4) Você terá dificuldade para ver velocidade. 5) Fica mais complexo avaliar se suas histórias não precisam ser menores para caber em uma sprint.

Essa prática pode gerar diversas disfunções no seu time.

Obs: A explicação acima é estimando em story point e não em hora

Sugiro tentar usar story point na história se tiver abertura. Ajuda muito estimar história em pontos e não em horas. Quando estima em horas, gera uma crença que é braçal todo o trabalho intelectual para realizar aquela história.As tarefas para realizar uma história você acaba estimando em horas, mas a história não recomendo.

Espero ter ajudado. Lembre de finalizar o tópico caso sua dúvida tenha sido esclarecida.

Obrigado pelas respostas André e Juliano.

@André sim, o projeto é complexo, o time vivia uma outra realidade de pontuação, que não estava refletindo a verdade, então eu estou mudando, porém existe umas resistências.

@Juliano, estou usando Story Points na escala de Fibonacci. A reclamação do time é justamente por uma história estar incompleta, o que eu fiz foi o seguinte, não terminou a história? caiu, independente do pontos. No planning fazemos a estimativa do que falta para completar, algo que fosse fácil, por exemplo, 2 pontos, porém o time reclama "Poo, e os outros pontos, perdemos, é como se não tivéssemos feito nada e agora vamos fazer só 2 pontos." Já estavam acostumados a começar algo, não terminar completamente e mesmo assim computar os pontos, o que não acho certo.

Achei que de repente eu estava sendo muito rígido e haveria uma forma mais flexível. Mas esse não é o único problema, tem várias outras coisas que colaboram com o cenário.

Obrigado

Alex, Eles não perdem o ponto. Vão ser contabilizados quando a história for entregue. Pense o seguinte, se estimou em 13 pontos. Ele não conseguiu terminar uma parte. Aquela parte que falta ainda está dentro do que foi pensando para as 13. Não tem motivo para ser re-estimado e adicionar mais pontos. Ele vai entrar na próxima sprint e pode falar que entrou 13 pontos.

Não sei se entendi bem, mas se um história tem 13 pontos de fato. Ela será contabilizada como 13 pontos entregues quando for entregue. Não pode diminuir para dois, porque o time fez parte em uma sprint e parte em outra. Isso pode gerar outras disfunções, como o PO, po essa história tem 2 pontos, agora outra mais simpes tem 5?

Em relação a reclamação do time, é justamente para isso. "Forçe" o time a terminar mais e não ficar começando um monte de coisa. Além disso, ajuda a unir o time com foco na sprint.

Na retrospectiva converse e tente entender porque não terminou dentro da sprint. Os pontos que precisam ser questionados:

1) Pq o time não viu que aquela história não seria finalizada? 2) Pq as reuniões diárias não apontou para esse risco? 3) Pq nenhuma outra pessoa ajudou a finalizar a história? 4) O time não está pegando coisa além da capacidade na planning? 5) A história não poderia ter sido fatiada pelo P.O? 6) O time não poderia ter pensando em uma solução melhor que atendesse a história dentro do tempo da sprint?

Como você disse que "o time vivia uma outra realidade de pontuação, que não estava refletindo a verdade, então eu estou mudando, porém existe umas resistências.", é normal essas inconsistência. Vá usando isso, para gerar essa conversa e ciclo de melhoria até ajudar e sua capacidade ser bem confiável.

Se sua dúvida foi esclarecida lembre de marcar como solução a resposta que te ajudou. Se não, só mandar.

Se quiser jogue os outros problemas aqui no fórum ou me procura no linkedin. www.linkedin.com/in/julianogranadeiro

Olá. Tenho o mesmo problema do Alex. Entendo que o framework define que os pontos computados numa sprint são somente os consumidos em tarefas prontas. Porém no ramo de negócios do sistema o qual sou Scrum Master é de certo modo comum existir histórias que irão demorar mais de uma sprint para estarem prontas. A construção da Nota Fiscal Eletrônica por exemplo. Não faz sentido quebrar em muitas partes, porque essas partes menores não irão agregar valor para meu produto. Mesmo assim, já tentamos dividir as tarefas para que sempre coubessem na iteração, porém isso gera muitas duvidas no time de desenvolvimento para entender a história como um todo, o que nos gerou muitos problemas e inconsistências na regra de negócio solicitada. Vejo que a solução proposta pelo Juliano e pela maioria dos agilistas em partes resolve a situação. Porém distorce os gráficos comparativos entre sprints, pois no exemplo citado a tarefa de 13 pontos foi finalizada na sprint atual, porém somente 2 pontos foram de fato consumidos por essa tarefa na sprint. Isso deforma a constatação da produção da equipe nessa sprint.

Luiz, realmente tem algumas histórias que são fora da curva, tem que dividir em épicos para poder entrega-la.

Não tenho nenhuma experiência com NF, então não consigo te dar um exemplo claro. Mas no projeto que estou hoje existem várias etapas que precisam ser feita para que eu possa entregar valor pra usuário, pois muitas delas correm sem que ele saiba.

O que fizemos foi criar histórias, que na visão do PO completavam ali o quebra cabeça, mas para o usuário nada, pq ele quer o produto que ele possa usar.

Se vc compra um carro em uma loja, um carro novo, mas a loja precisa pedir para fabrica, pois não tem o carro em pronta entrega. Suponha que vc pudesse acompanhar a montagem dele pela web, fazendo chassis, colocando motor, componentes internos, elétrica, pintura, testes de qualidade e por ai vai. Nada isso faz com que vc possa pegar o carro e dirigir, mas são etapas que vc pode acompanhar um progresso.

Se o PO conseguir fatiar as histórias dessa maneira, embora o usuário ainda não tenha a NF, o PO poderá acompanhar o quão próximo está de ter algo que o cliente possa usar.