Scrum - Projetos Ágeis e Pessoas Felizes

Cesar Brod

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

21.6 Mais algumas considerações sobre a velocidade

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

Sprint12345678Número Mágico
Velocidade real8
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

Sprint12345678Número Mágico
Velocidade realN/A12

28
8
Velocidade estimada20
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

Sprint12345678Número Mágico
Velocidade realN/A12

28
16

28
6
Velocidade estimada2022
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

Sprint12345678Número Mágico
Velocidade realN/A12

28
16

28
8
Velocidade estimada202215
DependênciasFaltou 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 de 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

Sprint12345678Número Mágico
Velocidade realN/A12

28
16

28
7

23
6
Velocidade estimada20221520
DependênciasFaltou 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

Sprint12345678Número Mágico
Velocidade realN/A12

28
16

28
7

23
12

28
4
Velocidade estimada2022152023
DependênciasFaltou um membro da equipe nesse Sprint
VersãoMVP

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.

TODO: Colocar debaixo da estrutura correta quando o capítulo 21 for inserido

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

Utilizamos cookies para melhorar a sua experiência em nosso site. Para mais informações, visite nossa Política de Privacidade.