Top Posts

livro certificação linux – tenha o seu

Continue lendo

Séri Agile: Como calcular pontos em uma Sprint?

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 17-12-2012

6

 

Olá Pessoal,

O post de hoje da série Agile trata-se de um assunto que não é fácil para o scrum master, equipe e 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 post. Claro que o que abordaremos aqui não é a única forma e 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.

Lets go…

Definir prazo, 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 5 novas features, mas conseguimos apenas concluir 3, por exemplo e isso é frustrante. Então como podemos evitar isso? Vamos ver como Kniberg nos ajuda 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 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 3 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

50 homens-dia disponiveis

Vamos considerar que seja um Sprint de 20 dias, então no cenário acima, apenas 2 dos 3 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 20, 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 colocar o item que sobrou, como se tiver 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? Ai é questão de análise do ScrumMaster 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 post Agile e espero que tenham gostado. Não deixe de compartilhar sua experiência. :)

Abracos, see ya!

Related Posts with Thumbnails

Comments (6)

Legal o posta cara, mas agora me esplica uma coisa, como eu chego ao tempo que as estórias irão levar?
Ex:
fazer página login – (7) pontos

autenticação DB – (6) pontos
Test de Perfomance – (5) pontos

Popular DB – (3) pontos

Outra coisa se eu tenho uma estória chamado Manter Usuários (12) Pontos.
Mas ela eu quero quebrar em tarefas do tipo:
Incluir Usuário
Alterar Usuário
Excluir Usuário

Consultar Usuário

Como fica as tarefas? divido os pontos nelas? ou elas colocamos em horas?

Depende do estilo do seu time. Aqui um CRUD é uma estoria completa. Não quebramos cada parte do crud. Quem pega uma estoria como Manter Usuarios, precisa entregar ela completa. Agora o Consultar usuario pode ser uma estoria separada, pq essa funcionalidade pode ser simples ou não, depende do tipo da consulta.

entãõ Silveirinha. Não receita pra isso. Não tem padrão. É o feeling da sua equipe, mas que tipo de equipe vc tem.Há um conjunto de fatores pra isso. Desde a experiência técnica, entendimento do negócio e grau de complexidade da estoria. E lembre-se estorias precisam ser do tipo INVEST. Por exemplo, no exemplo que vc deu eu só consigo ver 1 estoria que é Autenticação, os demais itens não são estórias, pois não entregam valor ao negócio. São tarefas técnicas que não são vendidas para o cliente. Eu como cliente não pagaria por Popular DB.

Então Camilo mas o que digo é que um CRUD tem uma story e varias tasks atreladas a essa story.

Tipo story Manter Usuários (12) Pontos.
task Incluir Usuário
task Alterar Usuário
task Excluir Usuário
task Consultar Usuário

A story Manter Usuários só estará pronta se todas as tasks atreladas a ela estiverem concluídas.Porém as task são jogadas em horas correto?
Como isso poderia ficar? Faço a conversão de pontos para horas e distribuo nas tasks?

Sim. Mas, não há conversao de horas pra pontos. Os pontos mede o grau de complexidade da estoria. E as hrs o tempo gasto pra tarefas. Aqui nao fazemos isso. São duas coisas diferentes. Vc estima em horas as tarefas e pronto. Dai vc vai saber quanto tempo medio pode levar.

Write a comment