Agile

25 jan, 2013

Como calcular pontos em uma Sprint?

Publicidade

Olá, pessoal! O artigo de hoje, da série Agile, trata de um assunto que não é fácil para o scrum master, para a equipe e o product owner: definir a quantidade máxima de um ponto que um Sprint pode suportar, ou seja, quantas estórias do backlog podem fazer parte do sprint backlog? É isso que veremos neste artigo.

Claro que o que abordaremos aqui não é a única forma, ou a mais adequada para ser implementada em qualquer projeto, porém é bem utilizada por scrum master mais experientes, como o Crisp.  Eu particularmente gosto de ter os cases do Crisp como referência.

Definir prazo, de acordo com a quantidade de trabalho dentro de um número X de dias, não é uma tarefa fácil. Claro que quanto mais experiência vamos adquirindo, as chances de erros tendem a diminuir. Mas não quer dizer que não podemos errar em estimativas e sabemos que esse tipo de erro gera grandes impactos, até porque o cliente está diretamente envolvido – já que prometemos entregar em uma Sprint cinco novas features, mas conseguimos apenas concluir três. Então, como podemos evitar isso? Vamos ver como Kniberg nos ajuda a entregar tudo aquilo que prometemos e manter uma boa saúde da equipe.

Lá vem a pergunta: como uma equipe define as estórias que vão para um Sprint?

  1. Pode ser por sentimento ou instinto: essa aqui é bem comum e pode ser a primeira opção a ser adotada. É errado? Não. Tudo depende da equipe e da auto-confiança da mesma nas estórias definidas no backlog do product owner.
  2. Estimativas de cálculo de velocidade: essa aqui é um pouco mais matemática e não envolve sentimento ou instinto. E o objetivo final da “velocidade” ajuda a saber a quantidade de trabalho que pode ser adicionado ao sprint.  Porém temos duas formas de  fazer o cálculo:
  • Forma 1 – Tempo de Ontem: é assim que é chamada, onde olhamos para o Sprint anterior e somamos os pontos do que foi entregue e podemos ter uma margem para próxima Spring.
  • Forma 2 – Fator foco: é onde uma estimativa de como a equipe é focada para achar o fator foco, então o calculo para encontrar esse “fator foco” seria:
fator foco(%) = soma das estimativas

                homem-dia

Agora, calculando os pontos por estória para o Sprint, é só pegar o percentual do fator foco anterior e multiplicar pela quantidade homem-dia do Sprint seguinte, assim chegamos ao total de pontos que o Sprint a seguir deve atingir para garantir a entrega. Se o resultado for 20 pontos por exemplo, então esse será o valor máximo que o Sprint backlog pode ter. Cálculo:

Pontos = fator foco(%) * homem-dia

O que é homem-dia?

Se nunca viu este termo, homem-dia é quantas pessoas teremos disponíveis para aquela Sprint e o cálculo não é por “cabeça” e sim por disponibilidade. O fato de ter três pessoas não quer dizer que temos elas 100%. Podemos ter o seguinte cenário:

  • Camilo: 20 dias
  • João: 20 dias
  • Maria: 10 dias

Logo, temos 50 homens-dia disponíveis.

Vamos considerar que seja um Sprint de vinte dias, então, no cenário acima, apenas dois dos três tem disponibilidade 100% para toda a Sprint, e isso tem um grande impacto na quantidade de estórias para o backlog.

Simulação

Supondo que tivemos 40% de fator foco no Sprint anterior, quantos pontos máximos devemos ter na próxima Sprint, com base no homem-dia anterior?

Pontos = 40 %* 50 = 20

Então sabemos que  não podemos ultrapassar o valor de vinte, do contrário já estaremos comprometendo a entrega de estórias do Sprint.  Vamos supor as seguintes estórias  no backlog:

  • fazer página login (7)
  • autenticação DB (6)
  • Test de Perfomance (5)
  • Popular DB (3)

As estórias acima atingem 21 pontos. O que fazer? Colocar apenas por causa de 1 ponto? É possível pensar assim, mas a melhor escolha poderia ser escolher o menor número, ou seja, até 18 pontos  (no caso acima) e evitar ultrapassar  o limite de pontos para o Sprint. Em alguns casos, pode-se colocar o item que sobrou, como se tivesse um tempo de folga e for possível ser implementado, mas o product owner não pode contar com aquela estória ao final da Sprint.

E quando não temos nenhuma Sprint para fazer os cálculos?

Isso acontece quando vamos para primeira Sprint. Então, que fator foco adotar? Aí é questão de análise do scrum master conhecer sua equipe e ter uma ideia do escopo. Você vai encontrar livros Scrum que falam 70%, 50%, 80%, enfim, fica a seu critério. Eu adotaria 70%, por não ser algo muito alto, nem tão baixo.

Vou ficando por aqui com mais um artigo Agile e espero que tenham gostado. Não deixe de compartilhar sua experiência.