Hoje vou falar um pouco sobre a matemática usada na metodologia scrum e agile em geral.
A matemática ágil é muito simples. Isto leva as pessoas a achar que falta alguma coisa e a incorrer em vários erros lógicos e práticos. Isto é mais comum em pessoas de níveis de gerencia que gostam de ficar inventando números sem significado. Em agile a matemática é simples, porque há poucos números com significado. São poucos números, mas perfeitamente suficientes para conhecer o estado do projeto e do team.
Dois pontos em que a matemática ágil assenta:
O primeiro ponto que precisa ficar claro é que todo o ágil trabalha apenas com escalas discretas. Nem todos os valores são possíveis. Esta discretização é muito importante para não dar falsas estimativas ou falsas expectativas. É importante para manter o significado dos números. Desconfie sempre de números apresentados com muitas casas decimais. Essas décimas não significam nada.
O segundo ponto é que em caso de dúvida se trabalha sempre com valores pessimistas. Isto evita falsas estimativas e a falsa sensação de que está tudo bem. O objetivo é sempre ser transparente e quando mais depressa soubermos que algo está mal, mais depressa podemos atuar.
O Tamanho é medido em Pontos de História (Story Points)
Para que seja possível algum tipo de metrificação é necessário atribuirmos um valor numérico a cada história. O Tamanho representa uma estimativa númerica da quantidade de trabalho intrínseca à história. Como é uma estimativa, o valor não será exatamente o valor do volume de trabalho, mas aproximado. A única regra é que o valor atribuído respeite a ordem relativa das histórias em relação à sua quantidade de trabalho. Ou seja, que a ordem das histórias, ordenadas por quantidade de trabalho seja a mesma ordem que quando ordenadas por Tamanho, mesmo os números em si não sendo os mesmos.
É vital compreender que o mais importante não é o valor número atribuído à história, mas como esse valor faz a história se comparar às outras.
Em ágil, o Tamanho representa o mesmo conceito que a Quantidade de Matéria representa em física. Um conceito de substância. Sabemos quando um objeto tem mais substância que outro, mas exatamente definir um número é complexo. Sabemos facilmente comparar a substância entre histórias, mas saber um número exatamente, é complexo.
Enquanto que a Química nos deu a resposta de como se define exatamente a quantidade de matéria (em moles), ainda não temos uma forma exata para a quantidade de trabalho de uma história em software. Por isso, para medir o Tamanho existem diferentes escalas possíveis. É uma situação análoga a como medimos temperaturas: várias escalas são possíveis. Contudo, todas as escalas usadas em ágil têm que ser:
Não é um requisito que a escala seja numérica. Existem escalas que não são numéricas, como a escala de tamanho baseado nas etiquetas de tamanho de roupa (XL, L, M, S, XS, etc.) ou a de volume de animais (o elefante é muito maior que o rato). Estas escalas são muito úteis para permitir uma classificação das histórias sem que haja um viés (bias) matemático. Por exemplo, evita que as pessoas façam contas para classificar as histórias. Contudo, estas escalas não são úteis para realizar cálculos de tamanho. Outras escalas, como a escala de Fibonacci é mais adequada a cálculos. Mesmo assim, ela incorre em problemas quando as histórias têm tamanho zero ( um valor possível na escala). Isto porque a soma de histórias com tamanho zero, não é zero.
A escala de Fibonacci tende a ser a mais usada porque é aquela que, além das regras padrão, minimiza a falsa precisão já que o espaçamento entre os tamanho é proposicional ao erro da estimativa. Contudo, não há escalas perfeitas, e no caso da escala de Fibonacci o problema é o valor zero que não realmente representa a ausência de tamanho, mas um tamanho muito menor quando comparados com os outros. Ou seja se História A tem tamanho 1 ponto e a História B zero pontos, o que podemos dizer é que:
Tamanho(B) << Tamanho(A)
Em que “<<” significa “muito menor que”. O Tamanho de B não é realmente inexistente, apenas pode ser desprezado face ao tamanho de A.
Ora, o problema é que as métricas de velocidade e fator de foco sempre são sobre a soma dos tamanhos. E quando somamos muitos “valores insignificantes”, a soma pode ser significante, e até maior, face ao tamanho 1. Imagine um sprint de apenas histórias com tamanho zero. Significa que não vai haver trabalho nenhum ? Não.
Então, ao trabalhar com Tamanhos na escala de Fibonacci é importante fazer as somas em duas partes
Soma = Soma de Histórias de Tamanho não-zero + Soma de Histórias de Tamanho zero
E considerar o segundo fator um valor a re-estimar, U, em que U não é zero.
Soma = Soma de Histórias de Tamanho não-zero + U
Esta técnica é importante quando somamos muitas histórias com tamanho zero. Se temos 1 ou 2 histórias de tamanho zero na soma, podemos desprezá-las no cálculo.
Em ágil não existe tamanho médio. Simples assim. Sempre que ouvir alguém falar de tamanho médio de histórias pode saber que essa pessoa não sabe de ágil. Falar sobre tamanho médio de histórias é como falar sobre o tamanho médio de todos átomos da tabela periódica. Você pode definir esse número, mas ele é irrelevante para qualquer finalidade prática.
Como dito, em ágil há muito poucos número que têm significado e o tamanho médio não é um deles.
O mesmo pode se aplicar a qualquer outra estatística sobre o tamanho como seja mínimos, máximo, moda e variância.
Uma outra tentativa comum é forçar todas as histórias a terem o mesmo tamanho. Dessa forma o tamanho é constante e não é necessário planning poker. Esta é uma outra forma da falácia do tamanho médio.
Para que todas as histórias possam ter o mesmo tamanho significa que elas devem poder ser divididas de forma a chegar no mesmo tamanho padrão. Ora, o conceito de História é exatamente o conceito de algo que não é infinitamente indivisível. É uma unidade de trabalho que aporta um certo valor, ou não aporta nada. Não existe o conceito de História “meio pronta” porque ela é uma unidade. A história atua como um átomo. Assim como átomos formam moléculas, podemos agregar histórias para formar histórias maiores e isso é por vezes útil, mas ao dividir sempre batemos um valor mínimo indivisível.
Tentar que todas as histórias tenham o mesmo tamanho é como tentar que todos os átomos sejam do mesmo tamanho. Não é da sua natureza e o conceito não faz sentido.
É um erro, por exemplo, assumir que uma história de 5 pontos pode ser desmembrada em uma historia de 2 e um de 3 pontos. Isto não é em geral verdade. Sendo mais comum que ao separar cada parte é maior. Ou seja, a história única tende a ser menor que a soma da partes. Por isso, é comum juntar histórias em histórias maiores, desde que caibam em um sprint.
O tamanho constante e tamanho médio são conceitos atrelados à tentativa de reduzir a matemática ágil à contagem de quantas histórias há para fazer e remover o overhead de tentar estimar o seu tamanho. Isto porque as pessoas não sabem estimar, então querem evitar esse passo.
Claramente isto pode ser feito, mas não tem significado algum. Dizer que há 20 histórias para fazer é uma afirmação desprovida de informação sobre o tempo que irá demorar para as realizar. Para isso, precisamos da soma dos seus tamanhos e da velocidade do team.
É importante entender que quando se fala de quantidade de trabalho, isso não significa quantidade de esforço. O esforço depende do agente que vai realizar a história : o programador. Programadores com melhores ferramentas e mais conhecimento resolvem a história com menos esforço. Programadores com piores ferramentas e menos conhecimento resolvem a história com mais esforço. O esforço depende portanto de quem vai realizar a história e como será realizada e não da história em si. Por isso que é muito importante entender que o Tamanho é principalmente uma forma de comparar histórias e não tanto de medir exatamente o trabalho que vai ser realizado. Afinal, é uma estimativa por definição.
A qualidade das ferramentas, das pessoas, das práticas, etc. são tudo fatores que afetam o quanto trabalho pode ser feito por unidade de tempo. São fatores que afetam a Velocidade, não o Tamanho.
A Velocidade é medida em Pontos de História por Sprint (Story Points / Sprint)
O Tamanho nos dá uma forma de atribuir um número a uma história com base na quantidade de trabalho intrínseca à história, mas não nos informa da capacidade do team realizar esse trabalho. Para isso precisamos do conceito de Velocidade.
Um dos números mais centrais da metodologia ágil e do scrum, a Velocidade, mede quantos pontos de história um team entregou em um sprint.
A velocidade é a soma dos pontos de todas as histórias completadas durante o sprint. Não importa quando no sprint a história foi completada, nem se ela já tinha sido trabalhada em outros sprints anteriores.
Velocidade = Somatório do Tamanho de todas as Histórias completadas no sprint.
A Velocidade por ser entendida como a quantidade de trabalho realizado por unidade de tempo. Esta característica de “unidade de tempo” é que lhe dá o nome de “velocidade”, mas é na realidade uma taxa. Ao contrário de outras métricas em outras metodologia o tempo em ágil não é continuo. É discreto. Esta é a mudança de paradigma mais difícil de entender. O tempo de entrega é separado em unidades chamadas sprints. Cada sprint é uma unidade indivisível de tempo. Não há unidade menor que um sprint. Então a Velocidade seria definida como o trabalho realizado em um Sprint.
Velocidade = Quantidade de Trabalho Realizado por Sprint
O Sprint é um período de semanas. Normalmente de 2 a 4 semanas. É vital que este período seja constante. Se não for, as velocidades não são comparáveis. Repare que a conta a seguir é sem significado em ágil:
Velocidade por semana = Quantidade de Trabalho Realizado / Semana
A diferença é que o Sprint não marca apenas uma unidade de tempo, mas um período em que o team é isolado do resto do mundo, afim de maximizar o foco do team no trabalho em causa. Quando este isolamento não existe, dizemos que o team sofre interferências. Há vários tipos de interferências e todas elas corroem o conceito de sprint e portanto o conceito de velocidade. Histórias mal definidas e mudança de requisitos são exemplos de interferências comuns.
O Sprint é uma unidade de tempo de isolamento. A Velocidade é uma medida do trabalho realizado em isolamento, e portanto, com máximo foco.
Outro ponto importante é que a Velocidade é para um conjunto das mesmas pessoas. Se as pessoas mudam, as velocidades não são mais comparáveis e não têm mais o mesmo significado. É um erro comum os gerentes compararem velocidade de sprints em que o team não tinha os mesmos membros, ou pior, comparar velocidades de teams diferentes.
Não é verdade, em geral, que ao adicionar mais pessoas a velocidade aumenta. Isto porque as interações entre as pessoas também aumentam o que causa perda de foco: ou seja, interferência. O colega ficam perguntando coisas a todo o momento é uma interferência e afeta brutalmente o foco.
Em geral a velocidade é uma função do período do sprint e das pessoas do team (não apenas do número de pessoas). Para que seja possível comparar velocidades, estes fatores têm que permanecer constantes ao longo do ciclo de iterações.
É comum cair no erro de concluir que: se o tempo em ágil é discretizado em sprints, então podemos dividir o tempo continuo em sprints consecutivos. Basta fatiar o calendário em períodos. Isto, embora muito comum, não é correto em ágil. Sprints são períodos de isolamento do team dedicado apenas à execução das história. Mas uma história precisa de muito trabalho até chegar ao ponto de poder ser realizada ( ver o conceito de Definition of Ready). Aquilo que antes se chamava: Análise de Software. A História tem um ciclo de vida que começa na ideia e vai até à construção e eventualmente deploy. Ora, o ágil só versa sobre o team de produção, aquele que constrói e, portanto, todo o resto do ciclo da história acontece antes, ou depois: fora do Sprint.
Em uma empresa onde as pessoas que fazem a análise são pessoas diferentes das que constroem, o fluxo de sprint pode ser realmente continuo onde os sprints se seguem uns aos outros sem interrupção. Isto porque a demanda por histórias novas consegue ser suprida a tempo por outro team. Mas se são as mesmas pessoas, o tempo de relógio precisa ser separado entre a analise de histórias e a realização de histórias e isso corrói o conceito de sprint. Neste tipo de ambiente os sprints não devem ser consecutivos sem interrupção. Deve haver um tempo para levar as histórias da ideia ao ponto de poderem ser construidas e só então, é feito um Sprint para as realizar.
Dividir o mesmo team para realizar ambas as tarefas, claramente não é um bom uso de recursos. As pessoas precisam de foco para realizar o seu trabalho, seja analisar, seja construir. É um erro comum achar que Scrum, e Ágil em geral, se aplicam a todo o processo de desenvolvimento de software.
O Fato de Foco não tem unidade. É um valor adimensional.
Como dito, o Sprint é um período de isolamento do team para que foque na construção das histórias. Então é interessante aferir a qualidade desse foco.
O Fator de Foco é a razão entre o trabalho que o team entregou e o trabalho que o team se comprometeu a entregar, em um mesmo Sprint. O trabalho com que o team se comprometeu é o Sprint backlog. A quantidade de trabalho com que se comprometeu é a soma dos pontos das histórias no sprint backlog.
Fator de Foco = Quantidade de trabalho entregue / Quantidade de trabalho com que o team se comprometeu
Este fator é numericamente igual a
Fator de Foco = Velocidade do Sprint / Tamanho do backlog no Sprint
É preciso entender que este número pode ser maior que um se o team realizar mais trabalho que aquele com que se comprometeu. Isto acontece quando são realizadas histórias adicionais, além daquelas originalmente previstas.
O fato de foco é a razão entre dois números inteiros e é apresentado como uma razão e não como uma percentagem. Por isso se chama “fator” e não “percentagem de foco”. Por que o numerador e denominador têm apenas – normalmente – dois dígitos significativos, o fator de foco não pode tem mais que dois dígitos significativos. Exemplo:
Fator de Foco = 25/ 23 = 1,0869565217391304347826 = 1.1
Apenas os primeiros 2 dígitos significam algo. Esta também é a razão porque não se apresenta em percentagem. As pessoas têm tendência a multiplicar por cem e arredondar depois , ficaria
Fator de Foco = 108,70 %
Mas este número tem 5 dígitos significativos. Sendo que começamos com dois, os três últimos dígitos não significam nada. Este é o tipo de lógica usada por gerentes que não entendem ágil. Não cometa este erro, porque fica muito aparente que não sabe o que está fazendo.
Histórias de Slack são histórias que não fazem parte do Sprint backlog mas que já estão alinhadas caso o team precise consumir mais histórias do que aqueles no Sprint backlog.
O tamanho das histórias de slack não conta para o tamanho do sprint backlog, mas conta para a Velocidade. Realizar histórias de slack além das histórias inicialmente combinadas é o que permite ao time ter um fator de foco maior que 1.
Uma história só pode ser completada dentro de um sprint. Apenas no sprint em que ela foi completada que seus pontos são considerados. Então pode acontecer que uma história, por várias razões, atrasar e não é completada no sprint onde ela começou a ser feita. Normalmente ela “vaza” para o sprint seguinte e é completada nesse sprint. Os seus pontos não são considerados no sprint anterior, apenas no seguinte. Isto faz com que o Fator de Foco do sprint anterior seja menor que 1 e que o do sprint seguinte seja maior que 1. Esta oscilação pode acontecer e a inspeção do Fator de Foco vai demonstrar a sua existência. A oscilação em si não é um problema, decorre do cumprimento das regras de discretização. O que é um problema é a repetição frequente deste fenômeno. Indica que o team não está avaliando corretamente o tamanho das histórias, ou do sprint backlog ou há interferências que precisam ser removidas.
O Fator de Foco é a única métrica que não depende do team. Não depende do tamanho do Sprint, nem do número de pessoas porque é a razão entre duas quantidades medidas no mesmo Sprint.
O Fator de Foco pode ser comparado entre teams pois denota informação independente do team e relativa ao processo. Problemas de interferência, má estimativa, falhas no compromisso são todos visíveis no Fator de Foco.
O Fator de Foco é portanto a métrica que permite auferir a saúde não apenas do team, mas do processo ágil como um todo.
A capacidade, também chamado de orçamento, é um número importante que determina qual é a velocidade máxima possível do team no sprint. Embora a cada sprint o team devesse permanecer imutável, na prática isso não é possível. Por exemplo, as pessoas vão de férias.
A capacidade tem que ser portanto calculada a cada sprint.
Normalmente, a capacidade em um Sprint é a Velocidade do Sprint anterior se todos os outros fatores são constantes: mesmo período de Sprint, mesmas pessoas no team, mesma quantidade de interferências (zero). Se o team modificar algum destes fatores a velocidade do novo sprint não é esperada igual à do anterior e o team deve conferenciar sobre qual capacidade se sentem confortáveis em se comprometer.
Um team de 4 pessoas com velocidade de 25 pontos , em um sprint de 3 semanas podem considerar que durante as férias de um dos membros, que estará ausente durante todo o sprint, apenas 3 pessoas estarão disponíveis, logo não é esperado que o team faça 25 pontos de novo. Seria menos. O team das 3 pessoas presentes deve conferenciar para chegar em um valor.
A Capacidade é usada durante o Sprint planning para entender quais histórias devem ser colocadas no sprint, e quanto deve ser a sua soma. A soma final será o Tamanho do Sprint Backlog que pode ser igual, maior , ou menor que a Capacidade. Contudo, só pode ser maior se o team se sentiu confortável adquirindo essas responsabilidade, normalmente é igual ou menor.
É importante notar que o que é considerado no denominador do Fator de Foco é o tamanho do Sprint backlog e não a Capacidade. Se o team tinha calculado 20 pontos de capacidade, mas fechou em um Sprint backlog de 25 pontos, são os 25 pontos que são comparados com a velocidade. Não os 20. Apenas o que é contratado é que vale. A capacidade é uma estimativa para o team entender se está contratando tamanho de mais, ou de menos.
Assumir mais pontos no Sprint backlog do que aqueles da Capacidade é uma fonte comum de um baixo fator de foco. Se a capacidade era 20 é muito mais provável que o team faça 20 pontos que 25. Se seguir a Capacidade o fator seria 20/20 = 1. Mas aceitar acima e depois não conseguir cumprir é automaticamente 20/25 = 0,8. O fator é muito menor simplesmente por se comprometer com mais do que poderia realizar. Adotar um Sprint backlog acima da Capacidade tem que ser a exceção e muito bem pensado.
O objetivo último de medir a velocidade e o fato de foco é estimar balizas relativas ao backlog, ou seja a todo o trabalho pendente. Este tipo de previsão só faz sentido se o backlog é fechado, ou seja, se não há novas histórias entrando continuamente.
Dado um Tamanho de Backlog, B – que é o resultado da soma dos tamanhos de todas as histórias existentes no backlog – queremos saber quantos sprints, s, são necessários para esvaziar o backlog.
s = ceil(B / ( V * f))
Onde V é a velocidade do team e f o fator de foco do team. A função ceil encontra o próximo inteiro igual ao maior que o valor. Aqui há um arredondamento para cima porque o número de Sprints tem que ser inteiro. Então por exemplo 1.2 Sprints significa 1 Sprint completo e mais um pouco de outro, o que significa 2 sprints. Como a premissa é pegar o numero pessimista, então é sempre o arredondamento para cima.
Suponhamos um exemplo de um backlog de 100 pontos e uma velocidade de 10 pontos com um fator de foco de 1. Seriam necessários 10 sprints. Se o fato de foco fosse 1.1 ainda seriam necessários os mesmos 10 Sprints. Se o fator de foco fosse 1.2 seriam necessários apenas 9, mas seria necessários que o team realizasse 20% a mais de trabalho em todos os sprints o que significa ter uma velocidade de 12 em todos os sprints. Isto não é realista. Se isto fosse possível a sua velocidade já seria 12.
O uso das métricas ágil para fazer previsões pode parecer muito simples por causa da simplicidade da fórmula, contudo há várias nuances que afetam essas precisões:
Quando é necessário para esperar uma estabilização ? Baseado na minha experiencia é muito difícil atingir este patamar. Eu diria que são necessários pelo menos 10 Sprints com os mesmos valores para termos uma estabilidade que nos permita estimar. Previsões ágeis são boas no curto prazo. Menos boas no médio e longo prazo pois são muito sensíveis a fatores externos.
A velocidade e o fator de foco são as únicas métricas que interessam e que têm significado em ágil. Apresento aqui algumas medidas auxiliares que podem ser úteis em alguns cenários específicos.
O Valor é um número atribuído à história assim como o Tamanho. Também necessita de uma escala discreta e comparativa. O Valor tende a estimar o quanto mais o cliente/usuário vai “valorizar” o software após a história estar integrada no software.
O conceito de Valor é muito importante em ágil, mas é normalmente pouco quantificado porque depende da opinião do cliente e/ou do usuário.
Todas as analises feitas em cima do Tamanho pode ser replicadas para o Valor. Contudo não há nomes específicos para a quantidade de valor por sprint. O chamado “incremento de valor” não é muito bem definido. Não se sabe se estamos falado a soma do valor das histórias do sprint , ou esse valor comparado com o do sprint anterior.
É necessário cuidado quando trabalhando com métricas relacionadas ao valor. É preciso definir muito bem os nomes e os conceitos sendo usados.
Existem escalas baseadas em dinheiro. Assim como o Tamanho não deve ser confundido com tempo, valor não deve ser confundido com dinheiro. A percepção de valor do usuário e do cliente vão muito mais além do dinheiro que pagam pelo software.
A Atratividade não é uma media padrão em ágil mas ajuda a escolher que histórias fazer primeiro em caso de empate em outros critérios. A Atratividade , A , de uma história mede o quanto ela deve ser priorizada em relação às outras.
A = v / T
Onde T é o Tamanho da História e v, o seu valor da História. Esta métrica só pode ser usada quando ambas as métricas Valor e Tamanho estão disponíveis para a história. O artigo original considera a análise do risco também.
O tempo de ciclo em ágil é um múltiplo de um sprint. As histórias não são produzidas em menos tempo que um sprint. As histórias podem necessitar de mais de um sprint para serem completadas, mas normalmente valores acima de 2 não são comuns. Se fossem, um processo seria criado na retrospectiva para lidar com isso.
Se o sprint é de 3 semanas, um tempo de ciclo de uma semana não tem significado. Não é possível ter terminado o trabalho antes do fim do sprint. Entenda que em ágil, o trabalho realizado no sprint só é entregue no fim do sprint. Se for entregue antes então a metodologia que você está usando não e ágil e o que escrevi aqui não se aplica.
Em ágil o Tempo de Ciclo vai se resumir a saber quantos sprints uma história demorou. O valor esperado é claramente 1. Isto porque, pelo padrão INVEST, a história deve ser dividida de forma que caiba em um sprint (S = small, que cabe em um sprint). Se a história não foi completada em um sprint, o tempo de ciclo aumenta. A informação contida nesta variação pode ser lida da variação do fator de foco, pois se a história não foi completada no sprint, o fato de foco será menor que 1 nesse sprint, e será maior de 1 no sprint em que foi completada.
Em ágil o tempo de ciclo não é uma métrica muito relevante porque o seu valor é normalmente constante e igual a 1, pela definição de como a descretização acontece e a mesma informação está presente na analise das variâncias do fator de foco. Podemos até dizer que todo o processo ágil é baseado no conceito de que o Tempo de Ciclo é sempre 1 e as sua práticas existem para lidar com os casos em que não é. Então, podemos dizer que o conceito está embutido na metodologia.
Para resumir é importante lembrar que toda a matemática ágil é sempre:
Para que hajam número com quê produzir cálculos é necessário atribuir certos números às histórias como sejam o Tamanho. O Tamanho é uma estimativa do team sobre uma quantidade de trabalho intrínseca à história. Os valores são atribuídos usando um escala que:
Dois teams diferentes podem obter valores diferentes para o Tamanho das Histórias, contudo a ordem das histórias por tamanho deve ser a mesma, pois não depende do team nem da escala.
Todas as métricas são então obtidas pela soma de Tamanhos de Histórias e comparação dessas somas.
O Sprint backlog é o conjunto de todas as Histórias a serem realizadas. A Velocidade é a soma dos tamanhos de todas as Histórias realizadas. O Fator de Foco é a razão entre a Velocidade e o Tamanho do Sprint backlog.
A Velocidade informa sobre quanto trabalho pode ser realizado em um sprint.
O Fator de Foco informa sobre a saúde do processo e do team.
Porque os valores são discretos o conceito de média não é aplicável. Vários conceitos como Tamanho médio das Histórias, simplesmente não significam nada.
Porque os valores são discretos os valores não podem ser apresentados com demasiadas casas decimais e dígitos significativos. Especialmente o Fato de Foco não deve ser apresentado como uma percentagem.
Simples.