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!
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
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.
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ã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.