# data[].attributes.body
Em 2015 li esse livro, e o ponto que achei mais interessante é que em 1985 o estudo Jeffery-Lawrence observou que não estimar aumenta a produtividade das equipes. Mas como? Uma das respostas é a Lei de Parkinson ("O trabalho expande-se de modo há preencher o tempo disponível para sua  realização."), geralmente se coloca "gordura" nas estimativas para diminuir o risco de não entrega no prazo.

# data[].attributes.body
Levantar as métricas do fluxo de forma manual, utilizando planilhas é uma tarefa muito árdua, sei disso porque trabalhei desta forma por bastante tempo. No entanto, para quem utiliza o  JIRA como ferramenta para gestão das demandas do projeto, existe a extensão do Navegador Chrome (Jira Flow Companion) que além de ser gratuita apresenta ótimos gráficos a respeito do fluxo de trabalho.
Importante: apesar do Método Kanban sugerir fortemente o acompanhamento das métricas de fluxo para melhoria contínua, as métricas podem ser capturadas e analisadas em processos onde os times utilizam o SCRUM.

# data[].attributes.attachment_link.description
Jira flow companion is a tool made to make powerfull analyses on Jira Data. The tool is triggered from the Jira CFD report page...

# data[].attributes.body
A simulação de Monte Carlo pode ser realizada pelo link abaixo ou pela planilha compartilhada Throughput Forecaster.XLXS. A página web do Rodrigo Rosauro foi elaborada a partir da planilha do Troy Magennis.

Página web - Project forecaster. Informe:

o tamanho do time (Team Size)

data de início (Start date)

tamanho do backlog (Number of tasks)

histórico do throughput (vazão) das últimas semanas (Weekly throughput)

Execute a simulação (Run the simulation)!!!

Planilha Throughput Forecaster.XLXS

a data de início

o tamanho do backog, o menor e o maior tamanho (Aba Forecast - item 2)

o histórico do throughput (Aba Throughput Samples - coluna Enter Samples Below): cada linha representa a vazão da semana

Acesse novamente a aba Forecast e observe as datas apresentadas na coluna M

Nota: Esse é um modelo estatístico, então quanto maior a amostra, melhor o resultado. Importante ressaltar que não se deve misturar Bugs, Histórias de usuário, incidentes na mesma simulação, pois o resultado pode enviesar.

# data[].attributes.attachment_link.readable_text
Forecast probabilities of a project's effort and duration using Monte Carlo simulations.
Read the online documentation if you have any questions using this tool. Your data is 100% safe and never leaves your browser.
(Fields marked with a red * are mandatory)
Risks

You can optionally model risks of your project, which will be added to the simulations.

# data[].attributes.attachment_link.description
Forecast probabilities of a project's effort and duration using Monte Carlo simulations. Read the online documentation if you have any questions using this tool. Your data is 100% safe and never leaves your browser. (Fields marked with a red * are mandatory) You can optionally model risks of your project, which will be added to the simulations.

# data[].attributes.headline
Estimando o data de entrega com Monte Carlo

# data[].attributes.subject
Estimando o data de entrega com Monte Carlo

# data[].attributes.body
No artigo em abaixo temos uma ótima explicação de como funciona o Monte Carlo e como é possível estimar o prazo de entrega de um projeto a partir do tamanho do backlog (número de itens) e o histórico de entregas (Throughput - Vazão do fluxo).

Nota: Esta é uma ferramenta para estimar duração, prazo de entrega do projeto e não esforço (custos). Para calcular custo podemos utilizar as técnicas do MVP ou Relative Mass Valuation ou Planning Poker com o objetivo de calcular o esforço de uma história.

# data[].attributes.attachment_link.readable_text
Ultimamente, temos usado uma abordagem mais probabilística do que determinística para gerenciar nossos processos. Isso significa que usamos diferentes métodos estatísticos para prever o futuro ao invés de estimativas cegas. Mas... imprevisibilidade não era exatamente uma das razões de termos mudado de Waterfall para Ágil?

Sim, imprevisibilidade é inerente ao desenvolvimento de software. Seria impossível prever todas as features de um sistema no começo de um projeto, por exemplo.

Mas e se nós pudéssemos prever como as próximas semanas se comportariam?

Isso é o que tentamos alcançar ao compilar métricas e rodar simulações de Monte Carlo.

Para entender mais sobre as métricas que utilizamos, veja:

A maioria das pessoas não usa métrica alguma para gerenciar projetos. Então, imagine quantas usam modelos estatísticos complexos para prever o fim de um projeto. No entanto, aplicar esse conhecimento em seu projeto ajudará entregar mais rápido e melhor.

Neste post, você verá como evoluímos de uma abordagem ingênua de predição para uma mais precisa e robusta utilizando a simulação de Monte Carlo. Mais ainda, explicarei de uma maneira fácil como esta simulação funciona, fazendo analogia entre um jogo de dados e projeto de desenvolvimento de software. Saber quando o projeto, provavelmente, vai acabar pode ajudar você a gerenciar as despesas da empresa, melhorar feedbacks a stakeholders e passar mais confiança de que você está no controle do projeto.

Por que não outros métodos?

Nós passamos por diferentes métodos de predição desde o início da empresa, e todos eles tinham algum ponto fraco. Aqui, listei alguns deles e o porque optamos por abandoná-los.

Throughput médio

Alguns podem pensar em um método simples, no qual usaria o throughput médio para prever o final de um projeto. No entanto, como você pode ver neste post Power of the metrics: Don't use average to forecast deadlines, isso seria um método ingênuo e não funcionaria.

Regressão Linear

Este foi nosso primeiro método. Regressão linear baseada no throughput acumulado para prever quando um projeto seria finalizado:

No entanto, identificamos dois pontos diferentes que não estávamos considerando quando fazíamos esse tipo de análise:

Nós mantínhamos o número de itens no backlog constante para que a predição funcionasse, o que causa muito viés.

Nós descobrimos, depois de algumas análises, que tanto o nosso throughput quanto lead times não seguem distribuição normal, portanto não faz sentido calcular regressão linear (veja em Looking at Lead Time in a different way e Assumptions of Linear Regression)

Configuração Manual

Primeiramente, focamos em evitar erros estatísticos, como o caso da regressão linear. Começamos a utilizar um modelo mais compreensível, que usa métodos que sabemos que estão enviesados, mas que podemos controlar de acordo com o contexto do projeto.

Adicionamos manualmente diferentes retas de predições de throughput baseados em percentis do histórico do projeto.

Nós tivemos melhores resultados com isso, já que podíamos mudar a previsão manualmente e, portanto, ajustá-la de acordo com o contexto específico do projeto. Porém, o fato de desconsiderarmos mudanças no backlog, nos motivou a dar um passo a mais e testar Simulações de Monte Carlo.
Planilha Simulação de Monte Carlo
BAIXAR PLANILHA GRÁTIS
Simulação de Monte Carlo

Wikipedia define Monte Carlo como:

Qualquer método de uma classe de métodos estatísticos que se baseiam em amostragens aleatórias massivas para obter resultados numéricos, isto é, repetindo sucessivas simulações um elevado número de vezes, para calcular probabilidades heuristicamente.

Pode parecer complexo ou difícil inicialmente, mas é muito mais simples do que parece. Você pode considerar que é o método de força bruta das previsões. Vou apresentar um simples exemplo, e então, mostrar como nós aplicamos na vida real. Existe uma simulação feita por Larry Maccherone, que pode facilitar o entendimento ainda mais.

Jogo de dados

Imagine que você está jogando um jogo de dados, no qual o objetivo é alcançar a soma de 12 pontos com o menor número de jogadas. A melhor jogada, no caso, seria jogar 2 dados consecutivos nos quais você tiraria o número 6 em ambos. A pior seria jogar o dado 12 vezes e caísse no 1 todas as vezes. O que queremos calcular com Monte Carlo é a probabilidade de finalizar o jogo depois de N rodadas.

Considerando que temos 6 possíveis resultados para cada jogada de dado (6 faces) qual é a probabilidade de terminar o jogo na primeira rodada?

Zero. Já que é impossível tirar 12 pontos se o dado vai até 6.

E na segunda rodada?

É a probabilidade de conseguir dois 6 consecutivos, e que, em estatística básica, é:

E na terceira rodada?

Você pode alcançar 12 pontos de diferentes maneiras: (3,3,6), (3,4,5), (3,5,4), (3,4,6), (5,5,2), (4,4,4), etc. Agora, o cálculo estatístico não são tão fáceis, certo? É aí que entra a simulação de Monte Carlo.

O que Monte Carlo faz é simular milhares de rodadas de dados, para então, analisar o resultado. Por exemplo, para saber a probabilidade de terminar o jogo na terceira rodada, a simulação rodaria o dado três vezes, somaria os pontos, e guardaria o resultado. Depois disso, iria repetir esses passos 5000 vezes e resumir quantas rodadas cada soma de pontos obteve:

Agora, o algoritmo soma todas as ocorrências que geraram soma maior do que 12 e divide o resultado pelo número total de ocorrências (5000). Neste caso:

O mesmo que fizemos para o terceiro round, faríamos para o quarto, quinto, etc.

Mundo Real

A solução do mundo real é muito similar ao exemplo dos dados. A única diferença é que o objetivo varia também (os 12 pontos no cenário do jogo), para considerar mudanças no backlog.

Então, o possível resultado de cada rodada (os lados do dado) são o histórico de throughput. E, do mesmo jeito que nós "rodamos dados" para o throughput , nós precisamos rodar os dados para o backlog, para dar chances do mesmo crescer também. Nesse caso, os possíveis resultados são chamados de Backlog Growth Rates (BGR).

Comecemos devagar. Digamos que nosso histórico do projeto é o seguinte:

Então, as possíveis jogadas para cada rodada de throughput seria o conjunto {2,3,0,2,5,0,1,3,3} e para backlog seria {0,2,1,1,2,1,0,2,0}. Não excluímos números repetidos, pois com eles mantemos a maior probabilidade de sair esses números, ao invés de outros.

Podemos aplicar o mesmo racional que esta por trás do jogo dos dados. Qual a probabilidade do throughput acumulado alcançar a mesma quantidade que o backlog, ou mais, na primeira semana? Alguns dos possíveis resultados são os seguintes:

Então, rodaríamos muitos como esses e veríamos quantos deles tem soma de throughput maior do que a soma do backlog, e dividiríamos o resultado pelo número de simulações. Fazendo isso, teríamos a probabilidade do projeto ser finalizado na primeira semana. Para a próxima semana, nós faríamos a mesma coisa, mas rodando dois dados em cada simulação (dois para BGR e dois para throughput) somando-os.

Um problema que esse método tem é que o backlog, no começo do projeto, se comporta diferente do que no meio ou final do mesmo. No começo, o backlog cresce muito mais rápido pois estamos tendo melhor conhecimento dos problemas e nuances do projeto. Já no final, o crescimento é de basicamente por causa de refinamento de histórias.

Para resolver este problema, ao invés de considerar todo o histórico de backlog para os cálculos, nós consideramos apenas os últimos 10 pontos, o que nos dá melhor perspectiva de como o backlog está se comportando ultimamente.

O resultado para as próximas 10 semanas, utilizando a abordagem acima, é representada no gráfico:

Como podem ver, realcei três áreas do gráfico para ilustrar o que poderia ser o entendimento do mesmo:

A primeira área, a vermelha, são as semanas nas quais temos 50% ou menos probabilidade de terminar o projeto. O que significa que seria arriscado demais dizer aos stakeholders que seu projeto seria finalizado nessas 4 semanas.

A próxima área, laranja, ilustra as semanas que têm probabilidade entre 50% e 75% de terminar o projeto. Eu diria que, se os stakeholders estão te pressionando para entregar rápido, seria possível terminar nessas semanas, mas alguns ajustes de processos seriam necessários.

A área verde é a mais livre de riscos, onde a probabilidade de terminar o projeto é maior do que 75%. Eu sugiro que você sempre dê preferência para estimar o fim do seu projeto baseado nesta área. No entanto, sabemos que nem sempre podemos ser tão flexíveis assim.

Nós testamos Monte Carlo em projetos passados, e parece funcionar muito bem, no entanto, como em todo método estatístico, ele se torna melhor depois de algumas semanas que o projeto já começou, por ter mais dados para trabalhar.

Conclusão

Prever quando um projeto irá acabar parece muito mágico, mas este método é extremamente simples de ser implementado; aumenta nosso entendimento e predição em relação ao projeto. É importante deixar claro que este método é estatístico e heurístico, portanto, não é a prova de falha. O objetivo principal é adicionar mais um elemento ao seu conjunto de ferramentas e deixar o gerenciamento de projetos um pouco mais fácil.

Para executar simulações sem muito trabalho, disponibilizamos uma versão simples da nossa planilha para você baixar.

Se quiser aprender mais sobre simulações de Monte Carlo, recomendo essas referências:

Como você faz sua projeção de fim de projeto? Qual sua opinião sobre nossa abordagem? Compartilhe seus pensamentos conosco nos comentários abaixo!

Planilha com Simulação de Monte Carlo

Método estatístico para calcular probabilidade (realista, otimista e pessimista) de data de término de projetos. Basta inserir os dados e você terá o gráfico com as projeções!

BAIXAR PLANILHA GRÁTIS

# data[].attributes.attachment_link.title
Por que usamos Simulações de Monte Carlo para gerenciar projetos

# data[].attributes.attachment_link.description
Ultimamente, temos usado uma abordagem mais probabilística do que determinística para gerenciar nossos processos. Isso significa que usamos diferentes métodos estatísticos para prever o futuro ao invés de estimativas cegas. Mas... imprevisibilidade não era exatamente uma das razões de termos mudado de Waterfall para Ágil? Sim, imprevisibilidade é inerente ao desenvolvimento de software.

# data[].attributes.body
No workshop Lean Inception a estimativa do MVP é realizada de forma amostral considerando que o tamanho das ondas é parecido. Desta forma, escolha 2 ou 3 ondas para detalhar o esforço, tempo e custo (sugere-se selecionar as ondas que tenham uma boa combinação de nível de incertezas e de esforço) e siga os seguintes passos:

1. Para cada funcionalidade das ondas selecionadas, descreva as histórias / tarefas da funcionalidade e marque com o número da funcionalidade (Ex. F1 para Funcionalidade 1, F2 para funcionalidade 2, etc).

2. Para cada história / tarefa classifique com P - pequeno, M - médio ou G - grande utilizando as outras para comparação.

3.  Selecione uma história / tarefa classificada como pequena e verifique qual é o tempo necessário para concluí-la, selecione outras duas ou três histórias / tarefas do mesmo tamanho e faça a média com o resultado de cada uma. Ao final desse trabalho teremos o tempo médio para cada classificação P, M e G.

4. Some os esforços das funcionalidades de cada onda e calcule a média da onda.

5. Com o tempo médio de uma onda, agora é possível estimar o esforço do MVP (Média de tempo por onda X quantidade de ondas).

Nota: a duração do MVP depende do tamanho da equipe e a quantidade de horas de trabalho por dia. No exemplo abaixo considerando uma equipe de 2 desenvolvedores e 6 horas de trabalho por dia, o  primeiro MVP pode ser entregue em até 12 dias.

# data[].attributes.attachment_link.description
The version of the browser you are using is no longer supported. Please upgrade to a supported browser. Dismiss

# data[].attributes.body
Técnica muito parecida com a utilizada para estimar um MVP do Paulo Caroli. Classifique todas as histórias do Backlog em P, M e G e depois atribua Story Points ou quantidade de horas/dias para cada uma delas.
Importante ressaltar que estimativas, são estimativas, não há garantia de acerto, mas é uma boa forma bom chute
Nota: Ao invés de utilizar uma mesa, utilize o Jamboard para fazer a estimativa com o seu time de forma virtual.

# data[].attributes.attachment_link.readable_text
Nesse artigo vou te ensinar uma técnica de estimativa ágil muito útil para estimar seu backlog!

Também é útil para pontuar uma larga quantidade de histórias de usuário encalhadas no Product Backlog.

Quando adotamos algum método ágil, como um novo modelo para o projeto, é normal haver um grande acúmulo de histórias de usuário para serem estimadas de uma única vez em seu backlog.

Passar pela situação de ter que estimar uma lista enorme de histórias acaba se tornando assustador para qualquer equipe, principalmente, as mais inexperientes.

A técnica Relative Mass Valuation é uma maneira rápida e inteligente de passar por um grande acumulo de histórias de usuário.

Portanto, vamos entender como aplicar essa técnica de estimativa ágil, que pode ser bastante útil para o nosso dia a dia.

Relative Mass Valuation? Como funciona?

Para você entender melhor, fiz um passo a passo, rápido e direto. Vamos a ele!

Passo #1: Tenha em mãos todas as histórias de usuário que devem ser estimadas

A primeira coisa a se fazer é levantar todas as histórias que deverão ser estimadas. Eu aconselho que elas estejam escritas em cartões, assim será mais fácil trabalhar com elas.

Você precisa considerar os épicos e temas (ou, qualquer outro nível de rompimento) também, como eles são itens de alto nível, normalmente se encontram na parte inferior do seu Product Backlog.

Passo #2: Coloque todas as histórias em uma mesa

Após levantar todas as histórias que estavam estacionadas em seu Backlog, coloque elas em uma mesa para que possam ser movimentadas facilmente.

A mesa é legal, pois todos podem ficar em volta dela para discutir e confirmar a utilidade e prioridade de cada história de maneira mais fácil e eficaz.

Passo #3: Escolha qualquer história

Escolha qualquer história para começar, faça a equipe estimar o esforço dela em "pequena", "média" ou "grande".

Usar P, M ou G é uma forma simples e rápida para atribuir esforço em torno do trabalho nesse primeiro momento.

Para atribuir peso, faça o seguinte:

- Se for uma grande história (ou seja, a equipe acredita que aquela história irá demandar um esforço grande) a coloque em uma extremidade da mesa, lado esquerdo, por exemplo;

- Se for uma pequena história coloque na outra extremidade da mesa;

- Se for uma história média, coloque no meio.

Passo #4: Estime por esforço relativo

Agora pegue uma 2° história e pergunte para a equipe se o esforço para faze-la é mais ou menos o mesmo da história que está na mesa.

Por exemplo, supondo que a 1° história foi considerada de tamanho G (grande), pergunte a equipe se o esforço para implementar essa 2° história selecionada é similar a 1° história que é do tamanho G.

Se a resposta for sim, a coloque sobre a mesa na mesma extremidade das cartas de esforço grande.

Usando esta técnica, é possível passar por 100 ou mais histórias de usuário dentro do Product Backlog e estimar o seu esforço relativo em menos de uma hora.

Passo #5: Pontue as histórias

Agora vamos pontuar as histórias, você pode preferir trabalhar apenas com a medida P, M ou G. Se for seu caso, pode parar por aqui! 🙂

Agora, se você prefere utilizar Story Points, siga o que vou lhe explicar agora!

Pegue um grupo de histórias, pode ser o com esforço "pequeno" (P) que são, teoricamente, mais fáceis.

Junto com a equipe, comece dando a pontuação de 1 para todas daquele grupo, depois passe uma por uma e analise se a pontuação está coerente.

Por exemplo, se você avaliou a primeira história e deu 2 pontos para ela, a segunda você irá comparar com essa, se você perceber que a história atual é duas vezes mais trabalhosa, você dá a pontuação de 4 pontos para a mesma, se for três vezes mais trabalhosa você dá a pontuação de 6.

E assim você vai pontuando por comparação, pois é mais rápido e eficiente.

Não se apegue aos detalhes!

A ideia é obter uma estimativa do ponto áspero, não do ponto preciso.

É isso, agora você não tem mais desculpas para deixar o seu Backlog com histórias sem estimativas. Até mais! 😉

# data[].attributes.attachment_link.title
5 Passos para estimar seu backlog em menos de 1 hora - Cultura Ágil

# data[].attributes.attachment_link.description
Nesse artigo vou te ensinar uma técnica de estimativa ágil muito útil para estimar seu backlog! Também é útil para pontuar uma larga quantidade de histórias de usuário encalhadas no Product Backlog. Quando adotamos algum método ágil, como um novo modelo para o projeto, é normal haver um grande acúmulo de histórias de usuário para serem estimadas de uma única vez em seu backlog.

# data[].attributes.body
No caso do framework Scrum, a ferramenta mais popular para estimar esforço é o Planning Poker, ela possibilita estimar esforço de uma história durante um Sprint Planning utilizando o conceito de Story Points (SPs).

Ainda no caso do Scrum, para calcular a duração do projeto, podemos utilizar a Velocidade do time. Velocidade do time é a quantidade de Story Points que o time consegue entregar dentro de uma Sprint. Então considerando que o backlog do produto esteja estimado em 200 SPs e a velocidade do time é 50 SPs, significa que o time levará 4 sprints para finalizar o backlog estimado. Se neste exemplo, uma Sprint possui 2 semanas, então o projeto poderá ser entregue em até 8 semanas (2 meses).
Nota: um time que acabou de iniciar o uso do Scrum, precisará de algumas Sprints para definir a sua velocidade.

# data[].attributes.attachment_link.readable_text
Você já parou pra pensar por que Planning Poker?

Se tem algo em que todos nós somos péssimos é em estimar, principalmente esforço.

É estranho ler isso né? Poxa, se somos tão ruins assim, porquê continuamos a estimar sem parar? Já que nosso índice de acerto é ridículo.

Tentando adivinhar o futuro

O cenário comum que existe é : Estimar todo o projeto, detalhando o máximo possível e assim se "crava" a estimativa de esforço.

Com o projeto estimado o que acontece é um verdadeiro desastre.

Tudo acontece de maneira diferente, o time descobre pedras no caminho e não consegue ter o ritmo que foi previsto.

A primeira dica é: Não tente planejar tudo de uma vez, isso é um erro.

Não conseguimos ser assertivos em estimar atividades pequenas, imagina então um projeto inteiro de uma vez. Você deve estar pensando, mas então como dou um prazo?

A resposta é simples, do mesmo jeito que você sempre fez, estime!

Mas leve em consideração que seu plano vai mudar. E o principal, não descarte o realizado ao invés disso, utilize os indicadores do realizado para calibrar as suas estimativas.

Está gostando do conteúdo? Então você gostar muito mais do que estar por vir, continue lendo, confira sobre o que ainda vamos falar:

A incerteza das estimativas

Qualquer que seja o tipo de atividade que você vai fazer, seja ela complexa demais ou simples demais vai existir uma variação da estimativa para o realizado.

Em alguns momento você pode ter uma atividade muito complexa que você estima gastar 8 horas e na realidade durante a atividade você descobre alguma técnica ou procedimento e faz ela em 2 horas. E o contrário também pode acontecer, você estimar algo em 15 minutos e gastar 2 ou 3 horas porque surgiu algo não esperado.

De uma vez por todas isso vai acontecer sempre.

O cone da Incerteza

Em 1958 os fundadores da American Association of Cost Engineers criaram o conceito de Cone da Incerteza. Onde basicamente todas as estimativas realizadas levavam em conta ranges de incerteza.

Em 1981, Barry Boehm trouxe para o desenvolvimento de software um modelo que ele mesmo batizou como Modelo Espiral, mas esse modelo era baseado no Cone da Incerteza criado pelos engenheiros da AACE.

O Cone da Incerteza prevê que estimativas iniciais de um projeto podem varia de 0% a 400%, ou seja, a estimativa máxima pode chegar a ser 16 vezes maior que a mais baixa. Como você pode ver no gráfico de cone da incerteza abaixo:

O cone da incerteza mostra que as estimativas tendem muito a variar no inicio do projeto, mas que ao longo do tempo elas vão se estabilizando até deixarem de ser estimativas e passarem a ser realidade.

Quando você está utilizando Métodos Ágeis como o Scrum por exemplo, o que você vai ter é ao final de cada duas semanas, além de software pronto, informações de REALIZADO e isso vai te ajudar a calibrar o seu plano e ir ajustando as demais estimativas ao longo do projeto.

Planning Poker: Estime pelo tamanho relativo

Como já disse, somos péssimos em estimar esforço. Mas somos bons em estimar com base no tamanho relativo.

Isso quer dizer que somos muito mais assertivos utilizando, por exemplo, P, M e G ao invés de pensar em quantas horas utilizar.

Um bom exemplo é quando vamos comprar roupas. Antes de experimentar o que você faz? Compara os tamanhos das peças e assim leva para experimentar. O interessante dessa experiência, é que ao conhecer mais a marca da roupa, na próxima compra provavelmente você irá acertar de primeira o tamanho certo.

Esse é um exemplo de dimensionamento relativo. Nós somos bons nisso!

Story Points: O que é afinal?

Para jogar Planning Poker a primeira coisa que você irá precisar é: Definir qual a unidade de medida.

Eu sugiro fortemente que você utilize Story Point. Ok, mas o que é Story Point?

Bom, talvez seja a definição mais difícil de se fazer. Quantas vezes alguém já me perguntou o que é Story Point e eu não soube explicar? Inúmeras! Eu tentava colocar Story Point no lugar da estimativa de esforço e definitivamente não é só isso.

Existem algumas definições de Story Point, mas gosto muito desse definição do Mike Cohn:

"um story point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma feature, a complexidade desse desenvolvimento e o risco contido nele".

Ficou confuso? Vou tentar simplificar: Story point é uma medida relativa de esforço, complexidade e risco. Ou seja, quando você for estimar algo leve em consideração essas três variáveis.

Como estimar com dimensionamento relativo

Estimar com base na comparação e triangulação é algo bem simples, e não exige muito esforço do time. A única coisa que é necessária é um conhecimento prévio do que vai ser desenvolvido. Veja o exemplo abaixo:

Se as estimativas não existissem, estimar em Story Point em uma Planning Poker seria algo muito simples.

Comece sempre estimando o menor itens de todos, no caso dessa planta acima é a varanda.

Varanda é de tamanho 1, se comparar com o banheiro que aparentemente é o dobro do tamanho, logo ele vai ser o tamanho de 2 Story Points.

Seguindo nessas comparações, observe que o Quarto 01 é 4 vezes maior que o banheiro, assim ele é 8 Story Points. Logo, assumimos que a sala de jantar é maior que o quarto e assim ela seria um tamanho de 13 Story Points.

Dessa maneira vamos estimar até o final, ou seja, comparando e triangulando os itens.

Perceba, que a diferença entre o Quarto e a Sala não é quase o dobro como estimamos (quarto = 8 SPs e sala 13 SPs). É exatamente nesse ponto que entra a incerteza e o risco das estimativas com Story Points.

E se a incerteza for grande como nesse exemplo, uma dica é tentar quebrar os itens (no caso a sala) em dois ou mais itens e assim tornar a incerteza menor.

Jogando o Planning Poker

Jogar o planning poker é muito simples e objetivo.

Vamos assumir que a partir de agora estamos em uma Sprint Planning e seu time é composto por 04 pessoas e iremos estimar os itens do topo do Product Backlog.

Antes algumas regras:

Só jogam as pessoas que forem participar efetivamente da construção dos itens.

Scrum Master deve ser o facilitador do jogo.

Product Owner deve estar disponível para retirar dúvidas.

Todos devem ter os baralhos de Planning Poker.

Product Owner deve apresentar os itens priorizados ao time.

Com as regras claras vamos ao jogo.

Selecionando o menor item

Como o PO já apresentou os itens priorizados os membros do time em consenso devem definir qual o menor item dentre os selecionados para a planning. Será a partir desse menor item que o time irá começar a sua comparação.

Um sugestão é buscar um item já desenvolvido pelo time em uma sprint passada (se existir) e utilizar ele como referência de comparação. Com algo já realizado as estimativas serão mais assertivas.

Comparando e pontuando os itens

Vamos assumir que o time pontuou o menor item como 2 Story Points.

Na sequencia o time pega o próximo item do backlog, como já conhecem o que é o item irão jogar via planning poker os pontos que cada um dos membros acreditam ser o ideal para esse novo item.

Todos devem escolher sua carta sem mostrar para outra pessoa do time e jogar ao mesmo tempo.

Ao jogarem as cartas apresentadas pelos 04 membros do time foram: 5, 3, 3, 8.

Após jogarem, a pessoa que colocou o menor e maior valor apresentam os motivos que os levaram a colocarem essa carta.

Perceba, que nesse momento existe uma defesa de idéias e que as vezes os demais membros do time não se atentaram para algum detalhe.

Após a apresentação dos motivos de cada um, os membros do time jogam novamente e nesse momento são viradas as seguintes cartas: 5, 5, 5, 8

Já na segunda rodada já quase existe um consenso entre os membros do time. Apenas uma pessoa colocou diferente das demais e nesse momento é importante entender mais detalhadamente os motivos dessa diferença.

É indicado que se jogue novamente até existir o consenso, mas entenda que em alguns momentos não vai ter consenso, afinal de contas são pessoas que estão ali. Então, seu time pode definir algumas regras para determinadas situações, como essa que se apresentou.

Dicas e regras que vão te ajudar

Eu mesmo já vi algumas regras interessantes como:

Quando apenas uma pessoa estiver com a pontuação diferente, se faz a média e nesse caso daria 5,75.

Outro exemplo, que já vivenciei e acredito ser o melhor é:

Depois de jogar 3 vezes o mesmo item e o consenso não existir, pegamos o que mais de 70% do time acredita, nesse exemplo seria 5 Story Points.

Se não existir uma maioria de 70%, é o momento de quebrar o item.

Quebrar o item, vai ajudar o time a entender ainda mais profundamente a story que estão discutindo e com certeza isso vai ajudar em novas rodadas de planning poker.

Fibonacci, por que logo essa sequência?

Antes de tudo, você deve conhecer a sequência de Fibonacci, certo? Para garantir vou explicar rapidamente.

Sequência de Fibonacci, nada mais é do que a partir dos dois primeiros números 0 e 1 os seguintes serão obtidos pela soma dos antecessores.: 0, 1, 1, 2, 3, 5, 8, 13 , 21, 34 e etc....

Dessa sequência, ao se dividir qualquer número pelo anterior o resultado é um "número irracional algébrico" conhecido como número de ouro.

Ok, mas por que Fibonacci?

Se utiliza Fibonacci devido aos "saltos" que se tem entre os números, esse espaços entre eles é o que vai medir a incerteza de uma estimativa e também retirar as pessoas de irem no número do meio.

Quando o time está estimando itens menores de tamanho como 1, 2 e 3, a assertividade da estimativa tende a ser enorme. Pelo fato do item ser pequeno ele se torna mais simples de se ter o total entendimento.

Se o item está entre 5 , 8 e 13, perceba que existe um salto grande do 8 para o 13. Esse salto é justamente para provocar a discussão entre as pessoas, e evitar que escolham por exemplo, o tamanho 10, que nada mais é que o meio termo entre 8 e 13.

Resumindo, a Sequencia de Fibonacci foi escolhida para o planning poker para tirar as pessoas do status comum e discutirem em volta dos itens a serem estimados.

Os Benefícios de Jogar o Planning Poker

É comum que muitos times deixem de jogar planning poker ao longo dos projetos que estão, vejo isso acontecendo por que as pessoas acabando não entendendo os benefícios que o jogo vai trazer.

Os benefícios que o Planning Poker traz são claros e vão trazer muita informação que não devem ser descartadas pelo time.

Acabe com o Efeito Manada

Efeito Manada é o que chamo de quando alguém mais experiente vai estimar alguma atividade e por essa pessoa ser a referência do time, todos os demais acabam estimando igual ou muito próximo ao que foi jogado.

O Planning Poker definitivamente acaba com esse efeito manada, uma vez que as estimativas jogadas só são esclarecidas no momento que se viram as cartas.

Embate de ideias e conceitos

Talvez o principal benefício do planning poker são os embates de ideias.

É muito rico quando os membros do time discutem soluções e ideias para um item que está sendo estimado. O embate de ideias só vai melhorar o conhecimento do time frente ao item.

Mede a qualidade do Ready

A Planning Poker gera um indicador que poucas pessoas medem, que é a qualidade do Ready.

Se na sua planning muitos itens são quebrados, é um sinal muito forte de que as estórias que o seu Product Owner está criando estão com a cobertura de Ready baixa. E talvez seja a hora de rever como está o seu conceito de Ready e melhora-ló.

Outro indicador importante é que se as histórias estão ficando com as estimativas altas é sinal de que a incerteza está alta. E nesse caso, pode ser que seja necessário refinar melhor suas estórias.

Conclusão

Acredito que todo time que vá construir algo deva utilizar o Planning Poker, por ser uma prática muito simples e que gera muito engajamento das pessoas. Além de gerar alguns indicadores que podem ser extremamente uteis para o seu time.

E você o que acha do Planning Poker? Gosta de utilizar? Compartilhe com a gente a sua opinião nos comentários abaixo.

# data[].attributes.attachment_link.title
Planning Poker: Tudo que você NÃO sabia sobre a melhor técnica de estimativa

# data[].attributes.attachment_link.description
Você já parou pra pensar por que Planning Poker? Se tem algo em que todos nós somos péssimos é em estimar, principalmente esforço. É estranho ler isso né? Poxa, se somos tão ruins assim, porquê continuamos a estimar sem parar? Já que nosso índice de acerto é ridículo.

# data[].attributes.body
Para o Método Kanban, não há cerimônias de estimativas de esforço ou duração, por ser um método onde as demandas são realizadas a medida que o sistema tem capacidade para entregar (fluxo contínuo - sistema puxado), a previsibilidade do projeto pode ser realizado utilizando estatísticas das métricas do processo de trabalho. As principais métricas são o Throughput (Vazão: número de itens entregues em uma semana) e o Lead Time (Tempo de entrega: diferença entre o comprometimento de fazer a demanda e a conclusão).
Nota: caso não haja registro do lead time e da vazão, se faz necessário capturar essas métricas por algumas semanas e depois calcular a previsibilidade do projeto.

# data[].attributes.attachment_link.readable_text
Os números no nosso dia-a-dia podem nos revelar muitas coisas, e existem dois em especial que nos ajudam a verificar a saúde das entregas e a termos mais previsibilidade, eles são o Lead Time e o Throughput.
O LeadTime Tempo que uma demanda demora para percorrer todo o fluxo até chegar no estado de Done.
Para coletar esse tipo de informação costumo anotar a data que a demanda entra no fluxo e a data que ela sai.

E conforme o volume dos dados vai aumentando conseguimos montar um gráfico e fazer algumas análises.

Exemplo quando o Lead Time tem muita variação existem diversas possibilidade, mais algumas prováveis causas são:

1. Fluxo não está otimizado - Recomendo limitar o WIP(Work in Progress).

2. Variação muito grande no tamanho das demandas - Recomendo separar o que é Stories de Tasks, evitando assim comparar elefante com formiga.

Porém, como disse podem ser N causas, recomendo fazer uma investigação a fundo para tentar diminuir essa variabilidade porque assim que a variação estiver mais estável podemos extrair dados importantes como, ter a previsão de entrega de uma demanda.

Olhando o gráfico acima e utilizando o percentil 90 podemos dizer que com 90% de confiança entregamos uma demanda em até 7 dias. Acredito que essa informação será muito útil no seu dia-a-dia quando precisa responder perguntas do tipo:

Quando aquela demanda que te pedi ficará pronta?

Se você começar a mexer nisso hoje quando você me entrega?

O Throughput Conjunto de demandas entregues em um ciclo de tempo.
Normalmente gosto de medir semanalmente conforme a gráfico a seguir, esse tipo de dados nos ajuda a responder algumas perguntas como:

Em um desenvolvimento com 12 demandas em quanto tempo ficará pronto?

Nesse caso se quiser dar um data pessimista pode falar que em 4 semanas ficará pronto, já que no gráfico acima mostra que em nenhuma semana foi entregue menos que 3 demandas, então 12/3 = 4 semanas , porém se for mais otimista pode dizer que será entregue em 3 semanas já que existe uma grande probabilidade de entregarmos 4 ou mais demandas por semana.

Na teoria parece muito fácil aplicar, porém no dia-a-dia a outras informações que precisam ser observadas, por exemplo:

Quando analisamos o tipo de demandas entregues podemos nos deparar com um cenário parecido com o do gráfico acima onde existe uma grande quantidade de demandas de falhas sendo entregues.

Nesse caso recomendo usar apenas as demandas de valor para passar uma previsão assim ficando mais assertivo. Também recomendo usar esse gráfico como uma ferramenta para auxiliar na melhoria continua tentando entender o porque a taxa de demandas de falha estão alta e procurar formas(kaizen) de reparar isso, caso possível.
Dica
Nos dois gráficos é importante fazer anotações toda vez que houver uma alteração no time ou uma discrepância no gráfico, assim ficando mais fácil a interpretação ao longo do tempo, exemplo:

A Companhia marcou um evento de alinhamento estratégico e o time ficará 3 dias fora

Provavelmente o Throughput da semana do evento será impactado, e caso não tenha uma narrativa explicando o porque, qualquer outra pessoa poderia interpretar de uma forma equivocada essa oscilação ou com o passar do tempo o time esquecer o motivo e também ter uma má interpretação.
Conclusão
Tanto o Lead Time quanto o Throughput são dados importantes para nos auxiliar no dia-a-dia na hora de tomar algumas decisões e ter uma ideia de previsibilidade, mas também é uma ferramenta que ajuda a enxergar melhorias no fluxo e a medir os impactos dos kaizens realizados.

E agora que você aprendeu é só colocar a mão na massa, ou melhor nas planilhas...

# data[].attributes.attachment_link.title
Métricas Ágeis: O que o Lead Time e o Throughput revelam para nós?

# data[].attributes.attachment_link.description
Os números no nosso dia-a-dia podem nos revelar muitas coisas, e existem dois em especial que nos ajudam a verificar a saúde das entregas e a termos mais previsibilidade, eles são o Lead Time e o Throughput. O LeadTime Tempo que uma demanda demora para percorrer todo o fluxo até chegar no estado de Done.

# data[].attributes.body
O #NoEstimates é uma outra corrente na comunidade Ágil que está ganhando força. A simulação de Monte Carlo é uma ferramenta que não precisa estimativas para calcular o prazo de entrega. Compartilho o podcast  Bora Estimar, ou #NoEstimates? da Plataformatec que discutem sobre esse assunto.

Esse videocast da Aspercom

Flow Review #4 - Por que estimativas não funcionam? apresenta um ótimo debate sobre estimativas. Assistam!!!

# data[].attributes.attachment_link.readable_text
We and our partners use cookies to personalize your experience, to show you ads based on your interests, and for measurement and analytics purposes. By using our website and our services, you agree to our use of cookies as described in our Cookie Policy.

# data[].attributes.attachment_link.description
We and our partners use cookies to personalize your experience, to show you ads based on your interests, and for measurement and analytics purposes. By using our website and our services, you agree to our use of cookies as described in our Cookie Policy.