Backlog ready: gerenciando o risco do seu planejamento

Recebi o Juan Bernabó na Globo.com, para dar uma volta no nosso ambiente de desenvolvimento. O Juan se surpreendeu com um indicador que temos usado há algum tempo para gerir os riscos do planejamento (ou da falta dele), o Backlog Ready. Esse indicador foi criado dentro da Globo.com, pelo Danilo Bardusco, e não estava documentado em lugar nenhum fora da Globo.com – então espero que esse post sirva para esse propósito.

Motivação

Um problema comum em organizações ágeis é o fenômeno de esvaziamento do product backlog. Isso pode acontecer porque o PO entrou de férias, licença médica, ou porque o mesmo estava muito ocupado fazendo outras coisas (esse é um sintoma de um outro problema, assunto para outro post!). Quando isso acontece, o time normalmente fica ‘faminto’ por histórias. Vão para o planning sem histórias definidas, e o processo de planning fica realmente sofrido.

Além disso, é saudável que o time conheça o seu terreno alguns sprints à frente – mesmo que o backlog mude. Evita o FUD (fear, uncertainty & doubt – medo, incertezas e dúvidas) que normalente se instala quando o time não conhece o seu futuro de curto prazo, minando a motivação e o ambiente de trabalho.

O conceito de ready

Há algum tempo atrás, o Serge Beaumont criou o conceito de READY, em conjunto com o Jeff Sutherland. É basicamente um checklist que serve para identificar itens de backlog que estão prontos para entrarem no sprint. O Serge criou esse conceito para garantir que as histórias que vão para o sprint planning tiveram três perguntas respondidas: Why? (porque), What? (o que) e How? (como), e além disso são pequenas o suficiente e foram estimadas. Nas palavras dele:

 READY is when the team says: ‘Ah, we get it’ ”. […] In the end a User Story is READY if a team can implement it, and a Product Owner can prioritize it.

Baseado nessa definição, é possível criar o nosso próprio conceito de READY. Na Globo.com, uma história está READY quando:

  • Está escrita no formato de user-story (Como <ator> quero <funcionalidade> para <valor de negócio>
  • Foi estimadas pelo time utilizando planning poker
  • Possui valor de negócio
  • Está priorizada
  • Possui critérios de aceite

O objetivo é garantir o entendimento das histórias pelo time. Na definição do Serge, qualquer item de backlog que não se encaixa nessas características não é faz parte do Product Backlog – e sim de um Product Parking Lot, pois está esperando que time em conjunto com o PO terminem de entender e discutir a história. Esse conceito foi criado como um complemento da Definition of Done.

A mecânica

Eu estou sempre preocupado com o custo de coleta das métricas. É preciso ser o mais pragmático e crítico possível em relação à métricas, pois uma relação custo x benefício ruim pode minar completamente o propósito de uma medição – além de que os números podem ser manipulados (gamed).

Esta métrica tem um custo de coleta baixíssimo: é só contar a quantidade de pontos que estão no seu backlog no antes do planning de cada sprint (pois inclusive as histórias que vão para o Sprint Backlog ainda são backlog, pois ainda não foram entregues), registrar esse número, e seguir em frente. Tem o custo de alguns segundos de atenção ao quadro.

O backlog ready está acoplado à velocidade do time, então para que o mesmo funcione direito, você também precisa medir a velocidade do seu time. A velocidade do time é determinada pela média aritimética dos pontos entregues nos 3 últimos sprints. É uma métrica básica do Scrum, que você inclusive já deve coletar.

Por exemplo:

Sprint n: entregamos 43 pontos
Sprint n+1: entregamos 30 pontos
Sprint n+2: entregamos 45 pontos

Sua velocidade no Sprint n+2 será:
(43 + 30 + 45) / 3 = 39 pontos (desprezando os decimais).

O gráfico de velocidade desse time ficaria assim:

Considere que antes do planning de cada sprint, esse era o status do backlog desse time:

pré-Sprint n: 150 pontos
pré-Sprint n+1: 107 pontos
pré-Sprint n+2: 77 pontos

O Backlog READY é um indicador numérico, com uma escala percentual de 0% a 100%, indicando o volume de histórias que estão prontas para entrar no Sprint Backlog e serem desenvolvidas, onde:

  • 0% significa que não existe nenhuma estória em estado READY;
  • 100% significa que há um volume adequado de estórias bem conhecidas e entendidas pelo time;

Toda vez que o indicador está abaixo de 100%, é um sinal que o buffer de segurança está esvaziando e em breve o time pode ficar faminto, sem histórias para trabalhar. Hora de crescer o backlog!

Na Globo.com, convencionamos que 100% é o equivalente a 3 vezes a velocidade do time, ou seja, temos histórias bem escritas e conhecidas pelo time, suficientes para alimentar 3 Sprints. Menos que isso costuma gerar falta de visão de curto prazo, enquanto que mais do que isso costuma gerar desperdício e re-trabalho pelas mudanças inerentes ao negócio.

Portanto, é válido analisar o contexto do seu negócio e descobrir o número ótimo para o seu caso, de acordo com a sua realidade de planejamento, disponibilidade do PO, envolvimento do cliente etc.

A equação para cálculo desse indicador é:

A fórmula acima definida é a que utilizamos na Globo.com. O número 3 destacado é o que define os três Sprints que convencionamos, e que define o mínimo do nosso backlog ready. Para o time utilizado no exemplo acima, essa seria a evolução do seu backlog ready:

No exemplo acima, o backlog ainda estava num nível aceitável no Sprint 2, porém no Sprint 3 ele precisa ser urgentemente trabalhado.

O ministério da saude adverte: métricas podem causar estragos gigantes! Use com moderação!

Cuidado! Eu tenho quatro guias gerais a respeito de métricas que gostaria de compartilhar:

  1. Não seja escravo delas. As métricas devem trabalhar pra você, e não o contrário;
  2. Use o bom senso;
  3. Questione sempre a validade da medição. Porque e para que estou medindo?
  4. Números podem e sempre serão manipulados (gamed). Se vacine contra isso usando as regras anteriores.

Transformando isso num sistema pull

Uma forma simples de utilizar esse número é criar um sistema pull de manutenção de backlog. Nos times em que trabalhei, uma reunião de estimativa era disparada sempre que o número de backlog ready caia para abaixo de 90%.

E foi dessa forma que a métrica foi criada, e é assim que a utilizamos na Globo.com. Espero que seja útil para você também! Qualquer dúvida/sugestão ou comentário, por favor faça abaixo.

Tags: , , , , ,

4 comments

  1. noaldo – Programador web há 4 anos, estudante de redes de computadores no CEFET-PB, atua como programador PHP, DBA MySQL.
    Noaldo

    Show de bola! Parabéns pelo post.

    Só uma pergunta: essa revisão do backlog para deixá-lo ready acontece em qual momento? No sprint planning?

    Vlw, até mais!

  2. macaubas – Rio de Janeiro, Brazil – I'm an Agile Coach & Scrum Master, passionate about people, agile and technology. A software developer at heart, enthusiast of open-source and modern programming languages. Deep understanding of agile methods, project management, portfolio and program management, coaching, mentoring, and team-building, without overlooking the technical aspects of software development. Recently, I have been working in creating high-volume web applications and portals for a big media conglomerate.
    Macalendas

    Opa Noaldo, é normal que durante o Sprint se planeje uma ou duas reuniões de estimativa. Esse é o momento para se revisar o backlog!
    Essas reuniões de estimativa acontecem para deixar os plannings mais curtos, pois as histórias já irão chegar no planning com entendimento do time e estimativa feitas. Mas nada impede que esse tipo de coisa ocorra no início do planning também, só que você corre o risco de ter um planning extremamente longo!

  3. Leandro Guimarães – http://about.me/leguimas
    Leandro Guimarães

    Cara, muito legal o post, o indicador, tudo! Muito massa mesmo! Tire-me uma dúvida: nos projetos que vocês utilizam isso, a frequência de repriorização das atividades é muito alta?

    Não acontece de vocês fazerem “ready” em um monte de histórias e elas serem despriorizadas e nem serem tratadas nos próximos “80” sprints?

    Tenho a impressão de que sim, isso deve acontecer, mas pouco importa. O objetivo é a equipe ter uma visibilidade boa, um buffer bom de atividades a serem feitas.

    Por outro lado, parece-me que em cenários onde ocorram repriorizações mais frequentes pode ser que o número dê uma sensação ilusória.

    Mais uma vez, parabéns! Ficou muito legal!

  4. macaubas – Rio de Janeiro, Brazil – I'm an Agile Coach & Scrum Master, passionate about people, agile and technology. A software developer at heart, enthusiast of open-source and modern programming languages. Deep understanding of agile methods, project management, portfolio and program management, coaching, mentoring, and team-building, without overlooking the technical aspects of software development. Recently, I have been working in creating high-volume web applications and portals for a big media conglomerate.
    Macalendas

    Opa Leandro, acontece de tudo! Temos 25 equipes que usam o indicador, então esse tipo de coisa não é comum, mas já aconteceu sim. O product backlog é justamente isso: uma visão de curto prazo (alguns sprints à frente) do trabalho da equipe. Se a visão de curto prazo muda e as coisas são repriorizadas, tudo muda também 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.