A equipe Scrum é soberana na estimativa do esforço necessário, tipicamente em pontos (history points), para o desenvolvimento de cada uma das histórias do Product Backlog. O Product Owner, porém, precisa ter uma boa ideia da velocidade da equipe, o número de pontos que ela consegue realizar por Sprint, para poder controlar a ansiedade dos patrocinadores e clientes com relação às entregas que serão feitas.
A Tabela 21.1 é adaptada dos ensinamentos de Henrik Kniberg e outros agilistas e é a que mais tenho usado em minhas equipes para estimar velocidade e, com ela, tempo para as entregas.
Tabela 21.1 – Evolução da velocidade
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | 8 | ||||||||
| Velocidade estimada | |||||||||
| Dependências | |||||||||
| Versão |
Cole essa tabela em algum lugar próximo ao Burndown Chart de sua equipe e preencha-o, na medida em que os Sprints progridem, sempre indicando qual é o Sprint corrente. Aqui, iremos destacar, com letras em vermelho, a coluna da tabela que corresponde ao Sprint em questão.
No primeiro Sprint de um projeto, especialmente quando trabalhamos com uma nova equipe, não há como estimar a velocidade. A equipe ainda está calibrando o seu chute. Nesse caso, o Product Owner apenas registrará o número de pontos efetivamente realizados pela equipe: a soma de todos os pontos das histórias que foram aceitas na revisão do Sprint.
A Tabela 21.2 ilustra esse registro ao final do primeiro Sprint.
Tabela 21.2 – Evolução da velocidade, Sprint 1
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | N/A | 12 – 28 | 8 | ||||||
| Velocidade estimada | 20 | ||||||||
| Dependências | |||||||||
| Versão |
O Product Owner anota, na linha Velocidade Estimada, N/A (não se aplica, já que estamos no primeiro Sprint), e constata que a equipe entregou três histórias cujos pontos, somados, resultam em 20. Agora, ele subtrai o número mágico desse total (12) e o soma ao total (28). Sua velocidade estimada para o Sprint 2 é algo entre 12 e 28. Logo mais falaremos sobre o número mágico.
Ao final do segundo Sprint, a equipe realizou 22 pontos. Como esse número está entre 12 e 28, o número mágico é decrescido de dois, passando a ser seis. Assim, a estimativa para o próximo Sprint é que a velocidade seja 22 +/- 6 (entre 16 e 28).
Tabela 21.3 – Evolução da velocidade, Sprint 2
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | N/A | 12 – 28 | 16 – 28 | 6 | |||||
| Velocidade estimada | 20 | 22 | |||||||
| Dependências | |||||||||
| Versão |
Ao final do terceiro Sprint, a equipe realizou 15 pontos. Como esse número não está entre 16 e 28, o número mágico é acrescido de dois, voltando a ser oito. Assim, a estimativa para o próximo Sprint é que a velocidade seja 15 +/- 8 (entre 7 e 23), como mostra a Tabela 21.4.
Tabela 21.4 – Evolução da velocidade, Sprint 3
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | N/A | 12 – 28 | 16 – 28 | 8 | |||||
| Velocidade estimada | 20 | 22 | 15 | ||||||
| Dependências | Faltou um membro da equipe nesse Sprint | ||||||||
| Versão |
Note que a equipe observou a falta de um membro da equipe no terceiro Sprint. Imprevistos acontecem. É importante observar o que impacta, positiva ou negativamente, o desempenho da equipe. Para o Product Owner, porém, o importante é ir calibrando o chute, aproximando a estimativa da realidade. E é por isso que o número mágico aumenta quando a realidade fica fora da estimativa e diminui quando fica dentro. Não importa se os pontos alcançados ficam fora do limite superior ou inferior da estimativa: se a equipe tivesse realizado 29 pontos em vez dos 15, ainda assim o número mágico voltaria a ser oito.
Mas, afinal, de onde vem esse número mágico? De lugar nenhum! Ele é um chute inicial. Na minha prática acabei por concluir que um número mágico igual a oito, com o incremento ou decremento de dois, funciona bem. Uso a regra de três para velocidades iniciais reais diferentes (20 está para oito como 40 está para dezesseis e, então, o passo incremental fica em quatro, para mais ou para menos). Se você não gosta do número oito, tente com outros números e incrementos. Para efeito de nosso exemplo, sigamos com o número mágico inicial oito e rodemos mais alguns Sprints.
Tabela 21.5 – Evolução da velocidade, Sprint 4
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | N/A | 12 – 28 | 16 – 28 | 7 – 23 | 6 | ||||
| Velocidade estimada | 20 | 22 | 15 | 20 | |||||
| Dependências | Faltou um membro da equipe nesse Sprint | ||||||||
| Versão |
A tabela 21.5 mostra que a equipe voltou a fazer 20 pontos no quarto Sprint, ficando dentro da estimativa, o que faz com que o número mágico volte a ser seis. Assim, a estimativa de velocidade para o quinto Sprint passou a ser entre 12 e 28 pontos. A tabela 21.6 mostra que a equipe se manteve dentro da estimativa no quinto Sprint, quando entregou o MVP completo (o mínimo produto viável – ver o Capítulo 19).
Tabela 21.6 – Evolução da velocidade, Sprint 5
| Sprint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Número Mágico |
|---|---|---|---|---|---|---|---|---|---|
| Velocidade real | N/A | 12 – 28 | 16 – 28 | 7 – 23 | 12 – 28 | 4 | |||
| Velocidade estimada | 20 | 22 | 15 | 20 | 23 | ||||
| Dependências | Faltou um membro da equipe nesse Sprint | ||||||||
| Versão | MVP |
O produto é, então, lançado para um grupo significativo de clientes e, com o seu feedback imediato, o Product Owner irá refinar as próximas histórias de desenvolvimento, sempre com o apoio da equipe e com as informações dos usuários e, repetindo-se algumas dinâmicas selecionadas e exemplificadas na parte V desse livro, chega-se a uma definição de quais histórias irão compor a versão 1.0 do produto.
Imagine que o total dessas histórias some 160 pontos e a equipe de marketing da empresa deseja saber quanto tempo tem até que o produto possa ser lançado. O Product Owner já sabe que, no melhor cenário, a equipe pode chegar a 27 pontos por Sprint e, no pior cenário, a 19 pontos por Sprint, assim:
Pior cenário = 160/19 ≃ 9 Sprints
Melhor cenário = 160/27 ≃ 6 Sprints
Ou seja, a versão 1.0 será entregue entre seis a nove Sprints. Essa é outra razão pela qual prefiro Sprints curtos, de uma semana. Além de se chegar mais rapidamente a uma estimativa de velocidade que se aproxime da realidade, é mais fácil coordenar ações acessórias ao desenvolvimento (marketing, precificação, etc) em um período mais visível de tempo (semanas ou meses em vez de trimestres, semestres ou anos). É assim, inclusive, que a agilidade irá permear outras áreas da empresa.
Em equipes que adotam plenamente o Scrum, com seus papéis, ritos e artefatos, junto com as práticas de engenharia de software do Extreme Programming (XP, ver Capítulo 3), é comum chegar em um número mágico igual a dois e um incremento igual a um.
