A simples mecânica de listagens e sprints que Scrum advoga é uma ferramenta muito poderosa. Mais do que pode parecer à primeira vista. A analise diária do Sprint Burndown chart e analise periódica do Release Burndown chart mostram o andamento do projeto continuamente e sem esforço burucrático.
Sprint
Um Sprint é uma unidade de entrega e simultaneamente um periodo de tempo. O Sprint é baseado no valor de Foco. Ao definir um conjunto finito de coisas a fazer e um tempo para as fazer o Sprint dá à equipa a liberdade de fazer como, quando, e na ordem que for melhor para a equipa desde que no fim todo o conjunto esteja completo e seja entregue.
A duração do Sprint é medida em dias uteis. Não se conta o dia utilizado para a reunião de fim/principio de Spint. Este dia deve ser acrescentando para obter um cronograma real.
Um Release é constituido por vários Sprints. Normalmente entre 4 e 12 dependendo do tamanho do Release backlog e dos Sprints. Além dos Sprints de trabalho onde o release backlog é queimado ( ou seja, as historias contidas nele são completadas) devem ser incluidos Sprints unicamente dedicados à resolução de bugs e um ultimo Sprint dedicado a “fechar o pacote” e preparar a entregua final do release.
Story Points
Esta unidade de medida é odiada por aqueles bitolados nos métodos tradicionais de estimativa por horas-homem porque não existe uma correspondência entre um Ponto de Historia e tempo a menos que se introduza o conceito de Sprint de tamanho fixo.
Pelo método de Dias Ideais ou pelo de Tamanho Relativo cada história tem o seu tamanho estimado em Story Points (Pontos de Historia). A partir dai é estimado o tamanho do Product Backlog, depois dos Release Backlogs e dos Sprint Backlogs.
Velocidade
A Velocidade é numero de Story Points ( Pontos de Historia) que a equipa consegue completar por sprint – conforme a Definição de Pronto estabelecida no inico do Projeto. Teóricamente é esperado que este numero seja constante ao longo do Projeto sendo que o tamanho do Sprint e a constituição da equipa sejam mantidas constantes.
A velocidade uma função da equipa ( numero de membros, qualidade dos membros, capacidade dos membros, comprometimento e foco dos membros ) e da duração do Sprint.
Cada equipa tem uma velocidade diferente e cada uma deve experimentar com tamanhos de sprint difernetes até arranjar a combinação ideal que maximize a velocidade.
Duração do Projeto
Imaginamos que temos um Produto com um backlog de historias que totalizam 2000 SP.E imaginamos que a velocidade da equipa é 40 SP/ Sprint. Imaginamos ainda que o projeto foi dividido em 4 releases de 700 , 500, 500 , 300 pontos repestivamente e que cada sprint foi definido para 10 dias uteis.
A duração do projeto é numero dias uteis que é necessário para completar os 2000 pontos em 4 pacotes.
Para o primeiro release a equipa precisa de 700/ 40 = 18 sprints. Com mais um sprint final e um sprint de correção de bugs a cada 4 sprints de trabalho temos 18 sprint de trabalho => 5 (=18/4) sprints de bugs + 1 de final = 24 sprints (240 dias uteis)
Repare que o arredondamento é sempre feito para cima e as contas feitas com numeros inteiros. Isso é para que não exista a tentação de incluir falsa exatidão nos calculos.
500 / 40 = 13 => 3 (=13/4) sprints de correação + 1 final = 17 sprints ( 170 dias uteis)
300/40 = 8 => 2 ( 8/4) sprints de correção + 1 final = 11 sprints ( 110 dias uteis).
Com dados reais talvez as historias possam ser passadas de um release para outro para diminuir a necessidade de arredondamentos. Por outro lado bas práticas de desevolvimento podem ser instuidas para diminuir a necessidade de sprints de correção.
Enfim, o projeto demoraria pelo menos 240 + 170 + 170 + 110 = 690 dias uteis.
Se a cada 5 dias uteis correspondem 7 dias corridos e a cada 30 dias existe um feriado (em média) então 690 dias uteis correspondem mais ou menos a 966 dias corridos que equivale a mais ou menos 2 anos e meio.
Fazendo a conta directamente obeteriamos
2000/ 40 = 50 => 13 ( 50/4) sprints de correção + 1 final = 640 sprints ( 640 dias uteis) Repare que isto lhe dá uma estimativa um pouco menor. Esta é uma estimativa minima. Menos que isto é impossivel. A estimativa de 690 é mais realista porque contabiliza release por release.
Mas olhando para trás vemos que são 4 releases em 2 anos e meio. Nada mau. Sobretudo se considerarmos que teremos o primeiro release logo apos 240 dias uteis ( 336 dias corridos que é mais ou menos um ano). Após o primeiro ano o produto já pode ser comercializado e o retorno já pode começar a entrar. Com isso os próximos releases podem ser alterados com ideias sugeridas pelos usuários reais que usam o Produto diáriamente.
A duração do projeto é contabilizada em dias uteis e equivale ao numero de dias uteis necessários para implementar todos os pontos do product backlog.
P = pontos no product backlog
Rn = numero de Pontos no release backlog n
V = Velocidade da equipa
U = dias uteis por sprint.
d = duração do projeto
d= U* P / V + U * P / V + U * P /4 V
ou
d =
Sérgio Taborda's Weblog 
Caro,
Eu conheci o seu blog hoje e achei muito bom. Parabéns.
Por isso acredito que valha a pena comentar nele para que sempre possamos melhorar juntos, certo?
Sendo assim, eu gostaria de fazer 2 comentários. Em primeiro lugar, quero dizer que concordo com você que velocidade é a quantidade de story points realizados na sprint. Penso apenas que velocidade não deve ser vista de forma CONSTANTE, mas, MÉDIA. Do contrário, o PO poderia ter uma falsa impressão de que o time sempre iria fazer a mesma quantidade de pontos em todas as sprints, o que não é verdade. Um outro ponto importante neste caso é que, se o PO cobrasse velocidade constante do time, este acabaria mentindo: aumentando ou diminuindo a quantidade de story points das user stories. E não é isso o que queremos, né?
Você também comentou que a equipe deve ajustar a duração das sprints até arranjar a combinação ideal para ter uma maior maximização de velocidade. Se você me permite, eu discordo: O tamanho da sprint deve ser baseado na frequencia de mudanças dos requisitos. Quanto mais intensamente eles mudarem, menor deve ser o tamanho da sprint para que as cerimônias de Review e Retrospective possam fazer o que delas é proposto: Inspeção e Adaptação. Além do mais, sprints são “time boxed”. Se você mudar constantemente o tamanho das sprints dentro do projeto, o que vai acontecer é que o micro gerenciamento torna-se distorcido.
De qualquer forma, estou muito satisfeito em saber sua linha de raciocínio em relação ao “lado humano” das pessoas, tão esquecido no “mercado de trabalho”. Parabéns.
Marco,
obrigado pelo seu comentário. Se gostou deste blog, talvez goste do meu novo blog onde expando mais sobre estes assuntos.
Entenda que quando falo que a velocidade é constante me refiro a que ela é constante no limite. Ou seja, conforme o tempo o avança e mais sprints são feitos – mantendo a mesma equipe – mais a velocidade permanece constante de uns para os outros. Isto se dá pelo aprendizado constante e ajuste constante de quando seria uma boa quantidade de pontos.
A durança de um sprint deve tender da mesma forma para um constante. Isto porque se a velocidade é a quantidade de pontos por sprint, como concordamos, se o tamanho do sprint é constante, a velocidade também tende a uma constante. Repare que isto não significa que todos os sprints tenham exatamente a mesma velocidade real mas sim que estatisticamente são iguais. Recentemente li um artigo – que infelizmente não consigo encontrar sobre este mesmo assunto. O conceito a ter em mente é que velocidade é diferente do tamanho do sprint. Tamanho so sprint é aquilo que a equipe disse que ia fazer, velocidade é o que realmente fez. Ora, imagine que num primeiro sprint o tamanho foi de 300 SP e a velocidade foi 100 SP. Qual deveria ser o tamanho do próximo sprint ? Segundo o artigo, e eu concordo, deveria ser 100 SP. Como explicar o compromisso com mais do que realmente cumpriu ? ASsim se executa o segundo sprint e do 100 pontos 150 são feitos. No meio do sprint se sente uma falta de historias e a reserva é usada. Ok. Terceiro sprint. Vamos prometer quanto ? 100 ? 150 ? Não vamos exagerar e prometer 120. Mas acontece que fazemos 140. Ok. O processo continua. Depois do décimo sprint deve existir um valor central e um pequeno erro de oscilação. Digamos que esse numero é 148 com erro de 10 SP. Isto significa que a equipe nunca consegui mais do que 158 pontos. Portanto qualquer compromisso com mais do que isso é suicídio.
Veja de outra forma, existe um valor moda para a velocidade. Isto porque se a equipe é a mesma – tem os mesmos skills e o sprint tem sempre a mesma duração, então a mesma quantidade de trabalho é realizado. Isto é o que se espera num primeiro momento. O objetivo é : depois de chegar neste patamar, o Scrum Master deve procurar a hiper produtividade, ou seja, sempre conseguir mais no sprint seguinte que no anterior. Para isso os bloqueios que impedem a equipe de crescer devem ser removidos. O objetivo inicial é saber qual a velocidade minima com que podemo contar, e depois tentar acelerar. Desta forma se o nosso projeto tem 18000 pontos e sabemos que podemos consumir 148 por sprint podemos calcular quantos sprints, no máximo, são necessários. Isto nos dá um sentido de escala.
O PO não cobra coisa nenhuma do time. É o time que se compromete com um tamanho de sprint. Mas quando um time ainda não se conhece e/ou nunca executou scrum é dificil avaliar. O processo de adaptação tb se usa aqui. O valor de comprometimento vai sendo ajustado pelo time – não o PO nem o SM – mediante os valores históricos e a experiencia que tiveram em sprints anteriores. Por outro lado, também não é o PO que decide o tamanho das historias. Então ele não teria como ajustar ou mentir. Nem o time. Afinal porque o time iria fazer isso se tem liberdade de escolher qualquer numero ? Afinal um dos valores do Scrum é compromisso. Porque a equipe mentiria no seu compromisso ? Isso viola o que é mais básico no scrum, os valores.
A duração do sprint e o tamanho de do sprint são na realidade a definição de velocidade ideal. E dai se deriva o fator de foco ( velocidade realizada / velocidade ideal = pontos realiados / pontos de compromisso). O fator de foco deve tentar a 100% ou caso contrário o SM não está fazendo seu trabalho. Agora, esta variáveis não dependem da frequencia com que os requisitos mudam. Não sei de onde tirou essa ideia. Parece que vc estabelece uma relação entre os requisitos mudarem e o acontecimento de cerimonias. Ora, não é assim. A cerimónias são pré-agendadas no inicio e no fim de cada sprint com um hiato entre sprints. Eu não considero que ha um continuum de sprint sem nada no meio. mas mesmo que vc considere isso, uma cadeia se cerimônias e sprints sem intervalos no meio, as cerimônias já estão lá , agendadas, antes que as use. Se vc decidiu no dia 1 que iria executar 1000 pontos do seu backlog de 8000 pontos em 4 sprints de 1 mes, é exatamente isso que vc vai fazer. Se no final desses sprints vc realmente executou 1000 pontos ou não altera o fato que vc executou 4 sprints , cada um com cerimonias de abertura e fechamento. Por outro lado, o sprint é um tempo de execução para o time, mas o que o PO faz nesse tempo ? nada ? Não. Nesse tempo o PO está conversando com os stakholders para preparar as escolher as historias dos próximos sprints. Se os requisitos mudaram, então as historias do backlog mudaram, não as do sprint. Se uma historia do sprint muda, isso é um bloqueio. A historia deve ser substituída imediatamente por uma na reserva e a mudança ser discutida depois. Essa mudança entrará como uma nova historia num sprint mais ha frente. Em nada a velocidade é afetada , já que a velocidade não depende se historia A ou B é feita. Tando faz. O que interessa é o tamanho. Se vc tinha a historia A com 20 pontos e trocou por B 10 pontos + C 10 pontos tudo está na mesma no que concerne o compromisso e a velocidade.
A seua frase dá impressão que quando os requisitos mudam mais frequentemente então mais frequentemente a equipe tem que ser consultada. Isto não é verdade. Não é um scrum saudável. Se vc marcar uma sessão de planning poker entre sprints vc é livre de marcar essas sessões para durarem 1 dia ou 1 semana. Depende do que o PO precisa para escolher as historias do próximo sprint. Mas o PO também tem que fazer a sua lição de casa. Ele deve saber arranjar as historias novas mesmo sem a participação da equipe para poder ter algum feeling do que vai acontecer a seguir. O PO que entra no planning poker para discutir o funcional da historia não está fazendo seu trabalho.
Veja que a a adaptação e inspeção que se faz no review e na retrospectiva não são das historias ou do funcional do projeto e sim do andamento do projeto em si mesmo. Estas reuniões não dependem do domínio do problema, nem do domínio da solução. Elas dependem apenas do processo. Revisar o andamento do projeto e ajustar o processo é o que se pretende com cerimonias. Logo nunca a alteração de requisitos pode ter influencia nisto. Se está tendo, algo nesse processo scrum, está errado e o SM deve resolver esse problema.
Resumindo. Eu não defendo que vc esteja sempre mudando o tempo do sprint ou o tamanho do sprint (= ao compromisso da equipe). Pelo contrário. Um equilíbrio deve ser encontrado. Mas o equilíbrio não é conhecido à partida. Portanto nos primeiros sprints ha um processo de adaptação para se ir experimentando combinações até que uma dê certo. A combinação certa não é igual para todas equipes e projetos. A mesma equipe, com as mesmas pessoas, pode ter velocidades diferentes para projetos diferentes mesmo mantendo o sprint com a mesma duração, ou ter a mesma velocidade que tinha antes, mas só se o sprint tiver o dobro da duração. Nos primeiros tempos é um processo de tentativa-erro-ajuste. Depois disso sim o tamanho do sprint será fixo e a velocidade tenderá a para um patamar.
Finalmente, para haver algum nível de previsibilidade o PO poder se comprometer com os stakholders é necessário que um numero constante seja assumido. A diferença entre o scrum e o resto é que esse números não é chutado. É observado empiricamente medindo o processo do time ao longo tempo. Nas metodologias tradicionais as pessoas gostam de usar o melhor tempo que a equipe fez (o máximo), em vez do tempo que a equipe mais fez ( a moda) porque gostam de comprimir o prazo artificialmente. Em scrum isso não se faz. É para isso que temos os releases. A escala simplesmente é mais rica que apenas um relógio.