Para definição do que será entregue ao final de um sprint, é de responsabilidade do time estimar quantas funcionalidades poderá entregar testadas e prontas para uso no prazo de 30 dias. Para estimar o número de funcionalidades por sprint, Ken Schwaber propõe um método chamado poker game, onde cada membro do time dá uma nota, que equivale a um peso. Os pesos são denominados de acordo com uma Progressão Aritmética, ou seja, 1, 2, 3, 5, 8, 13 e 21.
O peso que se repetir mais vezes pelos membros do time é o peso que valerá para a funcionalidade. Ao total de funcionalidades, os pesos são somados e essa é a estimativa de entrega em um sprint. Caso o time estime quatro funcionalidades em 40 pontos e entregue no prazo de 30 dias, essa será a velocidade de entrega do time, ou seja, seu time-box; de forma que no poker game dos próximos sprints, o time poderá estimar para desenvolvimento o número de funcionalidades que não ultrapasse 40 pontos.
Ken Schwaber propõe também o controle de volume de trabalho pendente, chamado também de burn down charter, onde após cada reunião diária é acrescido em um gráfico o que foi feito em horas e o quanto falta para o término, no prazo de 30 dias.
O conceito de lead time é empregado no Lean Manufactoring, e é uma iniciativa que visa eliminar desperdícios, ou seja, excluir o que não tem valor para o cliente e imprimir velocidade à empresa. O que vai de encontro ao pregado no Scrum. Dentro deste conceito, o lead time é apresentado como uma equação simples que o relaciona ao trabalho em processo (WIP) e a taxa de saída de um processo. O cálculo do Lead Time é feito através da seguinte fórmula: Lead Time = WIP / Taxa de saída.
É pregado por WERKEMA (2006), que a redução dessa taxa traz uma série de benefícios como aumento de produtividade e redução de defeitos e retrabalho. Para melhor fixação deste conceito é necessário entender alguns termos:
- Tempo de Ciclo (T/C): frequência com que um produto é finalizado em um processo;
- Lead Time (L/T): tempo necessário para um produto percorrer todas as etapas de um processo, do início ao fim;
- Tempo de Agregação de Valor (TAV): tempo dos elementos de trabalho que realmente transformam o produto de uma maneira que o cliente se disponha a pagar;
- Tempo de Não Agregação de Valor (TNAV): tempo gasto em atividades que adicionam custo, mas não agregam valor ao produto do ponto de vista do cliente;
- Taxa de Saída: resultado de um processo ao longo de um período de tempo, expresso em unidade / tempo;
- Trabalho em Processo (WIP): itens que estão dentro dos limites do processo, foram iniciados, mas não foram concluídos;
- Tempo de Setup ou Tempo de Troca: tempo gasto para alterar a produção de um tipo de produto para outro.
Exemplo lead time:
Deve-se ter o cuidado em não confundir o tempo de ciclo com o lead time, destacando que apenas quando um processo opera em fluxo contínuo, ou seja, quando uma unidade é terminada e logo em seguida a próxima é iniciada, sem paradas, o tempo de ciclo é igual ao lead time.
Partindo do princípio das user stories priorizadas, o time joga pontos e inclui o número de user stories referentes ao seu time box para o sprint. Porém, ocorre muitas vezes do time não conseguir traçar uma régua coerente no decorrer de alguns sprints e acabar puxando mais ou menos pontos para o mesmo. Isso pode ser causado por uma falta de controle do realizado, para poder comparar com o estimado ao final do sprint. Com isso, algumas vezes o time fica estagnado neste ponto e é onde o conceito apresentado pode trazer um benefício no controle e redução de setup, e que pode ser reduzido atacando WIP ou aumentando a taxa de saída.
No caso do WIP, é necessário introduzir uma nova etapa ao processo, na qual os itens de entrada são agrupados, assim como ocorre nas user stories com a criação de tarefas. Caso cada user story seja atacada de uma só vez do início ao fim, sem paradas, sendo que as paradas são removidas pelo scrum master, teremos um fluxo contínuo. Segundo apresentado é quando o tempo de ciclo é igual o lead time, iniciando assim um processo de produção puxada.
A sugestão neste caso é colocar em cada tarefa criada para determinada user story o tempo em que foi iniciada e o tempo que foi terminada. No caso de interrupções, colocar também a hora que foi interrompida e a hora que foi retomada. Dado isso, ao final da tarefa tem-se o tempo de ciclo daquela tarefa e somando os tempos de todas as tarefas, é obtido exatamente quanto tempo a user story levou para ficar pronta e qual foi o tempo de parada total da mesma.
Com isso, nas estimativas é possível ter uma idéia, por exemplo, de quanto tempo leva para ficar pronta uma user story de 8 pontos. Caso duas user stories de 8 pontos tenham um lead time, desconsiderando os tempos de parada, muito discrepante, é sinal que a pontuação precisa ser revista e a régua de pontos reajustada. Caso os tempos de parada das user stories sejam muito extensos, isso pode causar impacto no tempo do sprint. Com o controle proposto, o scrum master consegue atuar na diminuição deste tempo ou em um projeto KAIZEN para melhoria ao final do sprint.
Exemplo de tarefa com controle de tempo para cálculo de lead time:
Este artigo apresentou a utilização do lead time para controlar e calcular o tempo total de uma user story utilizada no scrum. Com isso, é possível eliminar um dos problemas que é a falta de controle, e com isso criar um time box coerente para o time. Outro ponto interessante é a informação que é criada para o scrum master poder tomar algumas iniciativas como diminuição de tempo de parada ou ajustes de estimativas, caso essas encontre-se discrepantes após consolidação dos dados.
Existem também ferramentas como o JIRA em que é possível efetuar o cadastro de uma user story e tarefas relacionadas. Ao iniciar uma tarefa, a ferramenta controla o tempo automaticamente, bastando o analista responsável parar a tarefa caso deixe de executar a mesma por algum motivo. Ao retornar na tarefa é possível iniciá-la novamente e a ferramenta faz todos os cálculos provendo informações valiosas para o time poder tomar uma decisão de melhoria de estimativas ou diminuição de setup. O mesmo pode ser feito com o uso de um quadro Kanban.
Referências
- SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum. New Jersey: Prentice Hall, 2002.
- SCHWABER, Ken. The Enterprise and SCRUM. Redmond: Microsoft, 2007.
- SOMMERVILLE, Ian. Engenharia de Software. 6. v. Belo Horizonte: WERKEMA Editora, 2006. 120 p.
- WERKEMA, Cristina. Lean Seis Sigma. 4. ed. São Paulo: Prentice-hall,
2003. 606 p.