Garantindo datas de entrega em projetos SCRUM

Uma situação muito comum no dia a dia de diversas equipes de desenvolvimento de software e como não deveria deixar de ser também acontece aqui na Globo.com, é quando as equipes de marketing ou produto precisam de uma data garantida para o lançamento de um certo projeto, no entanto, estas mesmas equipes se sentem inseguras quando o ScrumMaster esclarece que o time é que vai estimar o que cabe em cada Sprint  e que cada time possui uma velocidade relativa contada em pontos de complexidade. Nessa hora elas entram em um estado de transe e voltam a pedir o que sempre pediram e a trabalhar da maneira como sempre trabalharam, Ken Schwaber chama este reflexo de “Muscle Memory.

Explicando melhor, quando as pessoas estão sobre pressão em um momento em que estão tentando alguma coisa nova (como por exemplo tocar um projeto usando SCRUM), na primeira dúvida que surge elas tendem a querer voltar a fazer as coisas como sempre fizeram, para muitas pessoas é realmente difícil aceitar que o Time é que define a velocidade de entregas, e neste momento elas requisitam alguma coisa que lhes dê uma segurança de que aquele software será entregue com certeza na data definida, é nessas horas que ouvimos o famigerado pedido “Poxa, não dá pra vcs fazerem um Project bonitinho com as datas e tal”, como se um project fosse o certificado de garantia de que o Time vai entregar alguma coisa em alguma data. Eu cada vez mais acredito que cronogramas não funcionam e não tem como garantir nada.

Em uma situação dessas, em que um produto precisa de um determinado set de funcionalidades e onde está se pedindo uma data formal de entrega, uma solução possível seria adicionar uma margem de segurança (ou buffer) nas estimativas para garantir que as estórias do projeto estarão prontas com certeza e, em seguida, verificar quantos Sprints são necessários para realizar esta entrega.

Este buffer é feito usando as estórias e suas estimativas de complexidade, durante o planejamento de um Sprint o Time evolui sua avaliação a respeito da complexidade de implementação das estórias com base no maior esclarecimento que vai acontecendo nas reuniões do Sprint.

Sendo assim podemos presumir que em um primeiro momento, quanto estamos lendo uma estória pela primeira vez, teremos um grau de precisão na avaliação da complexidade relativamente baixo, por exemplo 50%. Conforme as dúvidas e a arquitetura do sistema a ser utilizada são esclarecidos esta precisão aumenta até que no Sprint Planning 1  deve-se ter, idealmente, uma precisão sobre a estimativa de complexidade em torno de 90%. São estes dois dados que vamos utilizar a estimativa com precisão 50% e a estimativa com precisão 90% para calcular o buffer.

Vamos imaginar o seguinte Sprint Backlog com 4 estórias, e que estas foram estimadas pelo time nas reuniões de levantamento de estimativas(50% de precisão) e posteriormente no Sprint Planning 1(90% de precisão).

Com estes dados em mãos agora podemos calcular o tamanho do projeto adicionando o buffer:

 Complexidade do Projeto = Est. 50% + [(Delta)/2]

onde Delta/2 é o buffer.

Usando os números da tabela acima temos que a complexidade do projeto = 28 +(40/2) = 48 e o tamanho do buffer é de 20 pontos de complexidade, ou seja, quanto maior é a diferença entre a primeira estimativa e a estimativa mais precisa (90%), maior será o buffer.

OK, agora que calculamos o buffer podemos calcular quantos Sprints serão necessários para termos certeza de que o produto será entregue contendo estas 4 estórias. Supondo que a velocidade do time seja de 10 pontos de complexidade por Sprint, então vamos precisar de pelo menos 5 Sprints (48/10) para entregar estas 4 estórias com uma boa margem de segurança.

Como os Sprints possuem duração fixa, na Globo.com por exemplo giram em torno de 15 dias, então podemos garantir que em pelo menos 75 dias (15 dias x 5 Sprints) o produto estará entregue com todas as funcionalidades.