International Product Owner Foundation

Steen Lerche-Jensen

10 Aprovando, estimando e confirmando User Stories

As User Stories, que são a entrada do processo, detém estimativas de alto nível acerca da criação de Backlog do Produto Priorizados e dos processos de criação das User Stories. Essas estimativas são utilizadas pelo Product Owner a fim de aprovar as User Stories para a Sprint.

Deve-se notar que é responsabilidade do Product Owner a garantia de que as User Stories aprovadas entregarão valores e irão de encontro às necessidades e requisitos dos stakeholders do projeto. Uma vez aprovadas, as User Stories são estimadas pelo Time de acordo com a utilização de várias técnicas de estimativas discutidas nesta seção. Após a estimativa, o time se compromete com um subconjunto de User Stories aprovadas e estimadas, as quais eles acreditam que podem completar na próxima Sprint. Essas User Stories são Aprovadas, Estimadas e Confirmadas que farão parte do Backlog da Sprint. 

Embora o Product Owner aprove as User Stories iniciais para uma Sprint, a decisão final sobre qual User Stories específica (dentre as aprovadas pelo Product Owner) deve ser escolhida para a Sprint fica com o Time Scrum. O Time (com consulta ao Product Owner, se necessário) finaliza em qual User Stories eles trabalharam durante a Sprint.

10.1 Planning Poker

Planning Poker, também chamada de Estimation Poker, é uma técnica de estimativa que utiliza o consenso para estimar tamanhos relativos de User Stories ou o esforço necessário para criá-las. 

No Planning Poker, a cada membro do time é atribuído um conjunto de cartas. Cada carta é numerada numa sequência e os números representam a complexidade do problema, em termos de tempo de esforço, como estimado pelo membro do time. O Product Owner escolhe uma User Story do Backlog do Produto priorizado e a apresenta ao time. Os membros do Time Scrum têm acesso à User Story e tentam entendê-la melhor antes de providenciar a estimativa para seu desenvolvimento. Então, cada membro escolhe uma carta do baralho que represente sua estimativa para a User Story. Se a maioria ou o time inteiro selecionar a mesma carta, então a estimativa indicada por aquela carta será a estimativa para aquela User Story. Se não houver consenso, no entanto, os membros discutirão acerca das razões para selecionar cartas ou estimativas diferentes. Depois deste debate, eles escolherão cartas de novo. Esta sequência continua até que todas as hipóteses sejam compreendidas, mal-entendidos sejam resolvidos e se chegue ao consenso ou acordo.

O Planning Poker pressupõe uma melhor interação e comunicação ampliada entre os participantes. Isto facilita o pensamento independente dos participantes, evitando o fenômeno do pensamento de grupo.

 

  • As cartas “planning poker” Ágeis podem ser utilizadas para a atividade ou simplesmente números são escritos num papel antes da reunião e distribuídos para os membros do time Scrum.

  • Dimensionamento/estimativa utilizando o Planning Poker é um método abstrato que tira o foco do tempo atual em horas ou dias e em seu lugar coloca o foco na descrição do custo relativo e complexidade de uma tarefa em comparação a outras.

 O Time Scrum utiliza Fibonacci como números a fim de estimar o esforço: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

  • Estimativas de números são baseadas no tamanho relativo que o time sente ser apropriado.
  • Zero “0″ significa nenhum esforço requerido para completar essa story (funcionalidade deve ser criada pela conclusão de alguma outra user story); 1 significa que a story é trivial; 5 significa que é comum; 20 diz que é extremamente difícil ou muito permanece desconhecido.
  • Se o time fornece uma estimativa de 3 ou 5 ou 8, então essas user stories são perfeitas para este time.
  • 13 significa que o time está pedindo gentilmente para que você quebre a story em peças menores, se possível.
  • 20 ou 40 significam que o time está lhe dizendo que aquela story é muito grande e deve ser quebrada em múltiplas stories pequenas.

O processo:

  1. O scrum master permite que o time leia a story, e, se necessário, o product owner/especialista funcional explica a story.
  2. O scrum master facilita a discussão sobre as dependências e quais stories técnicas ou tarefas técnicas devem ser realizadas a fim de apoiar a conclusão da story. As stories ou tarefas técnicas são anotadas.
  3. Para user stories ou stories técnicas derivadas, o scrum master pede aos desenvolvedores para votarem utilizando-se do método do planning poker, com um “um-dois-três-já!”
  4. O scrum master, então, desafia os maiores e menores votos a explicar suas posições e a lógica por trás das decisões ou seja, porque eles creem ser mais ou menos difícil do que seus pares esperam.
  5. O scrum master repete os votos até que os números convirjam e o time como um todo possa entrar em acordo sobre um número ou em algum tempo para os números mais próximos.
  6. Se o time não entrou em acordo em um número sequer, o scrum master decidirá o melhor número baseado no número de votos ou em algumas vezes dando mais peso ao voto dos membros do time que estão trabalhando nesta user story específica.
  7. O scrum master atribui os pontos de esrforço à story, conhecido como “a estimativa do plano”.
  8. Repetir até que não hajam mais stories ou o time alocado para a reunião esteja exausto.

10.2 Punho de Cinco

O Punho de Cinco (Fist of Five) é um mecanismo simples e rápido para atingir o consenso num grupo e guiar uma discussão. Depois da discussão inicial, uma proposta dada ou uma decisão pendente, é solicitado aos membros do time Scrum que votem numa escala de 1 a 5 usando seus dedos. O valor do uso desta técnica é não só a construção do consenso, mas o impulsionamento da discussão uma vez que a cada membro do time é pedido explicações sobre a razão do ranking feito. É dada, também, a oportunidade para expressar quaisquer problemas ou inquietações. Uma vez discutido pelo time, uma decisão coletiva terá sido feita.

O número de dedos utilizado para votar indica o nível de concordância e desejo pela discussão:

  1. Um dedo: Eu discordo da conclusão do grupo e tenho preoucupações importantes.
  2. Dois dedos: Eu discordo da conclusão do grupo e gostaria de discutir sobre problemas menores.
  3. Três dedos: Eu não estou seguro e gostaria de seguir a conclusão do consenso do grupo.
  4. Quatro dedos: Eu concordo com a conclusão do grupo e gostaria de discutir algums problemas menores.
  5. Cinco dedos: Eu concordo totalmente com a conclusão do grupo.

Em algums casos, ele também é usado, como abaixo, para descobrir se as pessoas entenderam o objeto da discussão ou o requisito em detalhes.

 

10.3 Pontos para Estimativa de Custos

Estimativa de Custos pode ser realizada utilizando-se melhor das unidades relativas (como por exemplo, estimativa de esforço) do que das unidades absolutas (como custos atuais incorridos). A fim de estimar os custos para implementar uma User Story, o Time Scrum pode utilizar pontos de story. Quanto ele estiver terminado, o custo estimado para cada tarefa será na forma de pontos de story, ao invés de unidades monetárias. Para que se faça isso com sucesso, o Time Scrum deve identificar uma User Story parâmetro com a qual todos os membros possam se relacionar. Uma vez que esta linha de base estiver identificada, todas as estimativas de custo para User Stories devem ser feitas em comparação ao parâmetro. Essas estimativas permanecerão fixadas durante a Sprint porque os times não devem mudar durante a Sprint.

10.4 Wideband Delphi

A Wideband Delphi é uma técnica de estimativa em grupo para determinar quanto trabalho é envolvido e quanto tempo passará para ser completo. Indivíduos dentro do time, anonimamente, dão estimativas para cada funcionalidade e as estimativas iniciais são representadas num gráfico. O Time, então, discute os fatores que influenciaram suas estimativas e prosseguem para um Segundo round de estimativas. Este processo se repete até que as estimativas individuais estejam próximas umas às outras e um consenso para a estimativa final seja alcançado.

10.5 Dimensionamento relativo/Pontos de Story

Além de ser utilizado para estimativa de custos, pontos de story podem ser utilizados também para estimar o tamanho global de uma User Story ou funcionalidade. Essa abordagem atribui um valor de ponto de story baseado numa avaliação geral do tamanho de uma User Story, levando em consideração risco, montante de esforço necessário e nível de complexidade. O Time Scrum vai conduzir essa avaliação e um valor de ponto de story vai ser atribuído. Uma vez que a avaliação é concluída em uma User Story no Backlog do Produto Priorizado, o Time Scrum poderá, então, avaliar outras User Stories relacionadas àquela primeira story. Por exemplo, uma funcionalidade com 2 pontos de story deve ser duas vezes mais difícil de completar do que uma com apenas 1 ponto de story. Uma com 3 pontos de story deve ser três vezes mais difícil de concluir do que uma com apenas 1 ponto de story.

10.6 Estimativa de Afinidade

A Estimativa de Afinidade é a técnica usada para estimar rapidamente um grande número de User Stories. Usando notas adesivas ou cartões de índice e fita, colocam-se as User Stories numa parede ou outra superfície, na ordem da menor para a maior. Para isso, cada membro do time começa com um subconjunto de User Stories do Backlog do Produto Priorizado geral para colocar pelo tamanho relativo. Uma vez que todos tenham fixados suas User Stories na parede, o time revisa todos os lugares e poderá mover as User Stories de acordo com o apropriado. Esta segunda parte do exercício envolve discussões. Finalmente, o Product Owner indicará algumas categorias de tamanhos na parede. Essas categorias podem ser pequenas, medias ou grandes, ou eles podem numerá-las usando valores de pontos de story para indicar os tamanhos relativos. O Time, então, morevá as User Stories para essas categorias como o passo final deste processo. Alguns benefícios-chave desta abordagem giram em torno da transparência, uma vez que ela é visível para todos e a facilidade de ser conduzida.

10.7 Variedade de estimativas

Estimativas para projetos devem ser apresentadas em variedade. Figuras precisas podem dar uma impressão de serem altamente precisas quando, de fato, elas podem não ser. De fato, estimatvas por definição são entendidas como não tão precisamente corretas. A variedade de estimativas deve ser baseada no nível de confiança que o time tem em cada estimativa. A variadade pode ser pequena quando o time está confiante e maior quando está menos confiante.

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification