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

 

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!

6 comentários em “Séri Agile: Como calcular pontos em uma Sprint?”

  1. Silveirinha

    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

    1. Camilo Lopes

      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.

  2. Silveirinha

    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?

  3. Camilo Lopes

    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.

    1. Silveirinha

      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?

      1. Camilo Lopes

        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.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *