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 três guias gerais a respeito de métricas em geral 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.

O título da minha palestra será ‘Abraçe as incertezas: A Ilusão do Controle no Mundo Ágil’, falarei um pouco sobre o que realmente importa na gestão de projetos ágeis. A organização do evento me autorizou a gravar a palestra, então ela estará aqui no blog no mais tardar até quarta-feira, e os slides, no slideshare, como sempre!

Site do evento: http://www.scarduatec.com.br/pmipe2011/

Divulgação na mídia: http://ubas.us/qtVcxH

No ano passado, dei uma entrevista à Flávia Freire, da Revista TI Digital, sobre Scrum. Na época, eu ainda não estava trabalhando na Globo.com, mas o Guilherme Chapiewski, que estava na Globo.com a época, e o Danilo Bardusco, que é o nosso Gerente de Desenvolvimento, também foram entrevistados pela revista, juntamente com membros da comunidade Scrum Brasil, como  o Nelson Abu. Depois de alguns desencontros, finalmente consegui uma edição em papel da revista onde saiu esta matéria, mas até então não havia conseguido a matéria em formato digital – até que hoje pela manhã me deparei com o PDF da matéria, publicado no próprio site da revista. A matéria ficou muito rica, e acho que vale à pena utiliza-la como referência, principalmente para quem está começando e tentando entender do que se trata o Scrum.

Link alternativo para download: Desvendando o Scrum - Revista TI Digital - (582.52 KB)

Vendo este cenário, já rolaram na lista Scrum Development, do Yahoo! Groups, inúmeras discussões a respeito do tópico. O que fazer para garantir a realização das cerimônias no horário certo? Quais penalidades aplicar aos atrasados/ausentes?

O James Brett, do site ScrumMaster.com.au, escreveu um artigo bem interessante sobre essas penalidades para os atrasados – que traduzo aqui pois acredito que será de grande ajuda, pois pelo menos a mim o artigo ajudou bastante. Vamos lá:

Penalidades de atraso nas daily Scrums

Um componente chave do processo do Scrum é a reunião diária, o Daily Scrum. Esta reunião deve acontecer no mesmo local/horário todos os dias, de preferência próximo ao espaço onde o time trabalha, onde o taskboard do time fica. Cada membro do time responder à três perguntas nesta cerimônia:

• O que você fez desde a última reunião?
• O que você vai fazer até a próxima reunião?
• Você tem algum impedimento?

O daily scrum permite que o time entenda o que cada membro está fazendo, e é essencial para o trabalho em equipe necessário para a entrega da Sprint. Eu já experienciei também um time que quis adicionar uma quarta questão à lista das três acimas, que era “Qual a sua confiança (nota de 1 a 10) de que o time irá entregar o objetivo da Sprint?”. Isso ajuda o ScrumMaster à identificar problemas escondidos no time.

Da mesma forma, é usual que o time escolha as penalidades por atraso para os membros que, ou chegaram atrasados na daily scrum, ou não compareceram à reunião. É essencial que o time decida a sua própria penalidade, e quais “desculpas” são aceitáveis para chegar atrasado (se houver). Um dos meus times passou por este processo recentemente, e como um time chegou a um acordo: qualquer um dos atrasados iria suprir o restante do time com Donuts no próximo dia, como uma forma de “punição”. Aí, um dos membros do time protestou: “eu não vou entrar nessa! E se eu ficar preso por causa de uma solicitação do suporte?”. Então o time debateu mais um pouco, e definiu o que era e o que não era admissível como desculpas por atrasos. Depois disso, todos concordaram que a penalidade deveria ser trazer donuts. Um acordo com 100% de adesão foi feito entre o time.

O ponto importante para lembrar é que o time é que deve chegar à penalidade, e que TODOS no time devem se comprometer com antecedência à obedecer às regras do time e pagar as penalidades por chegar atrasado. Pessoas de fora do time não devem forçar penalidades ou condições no time, pois dessa forma o time não terá mais o compromisso, um princípio-chave em tudo que é relacionado ao Scrum.

Para finalizar, eu estava interessado em ouvir quais penalidades haviam sido implementadas no mundo afora, apenas por diversão. Eu coloquei esta questão no user-group de Scrum do Yahoo! Grupos, e recebi diversas respostas, que combinei com as que eu presenciei e compilei a lista abaixo.

Várias penalidades por atraso

• Cantar uma música de preferência do time (Noite feliz, My Way, Balão mágico, etc)
• Donuts
• Usar orelhas de coelho cor de rosa e brilhantes por 20 minutos
• Usar um cartão “Eu me atrasei” por algumas horas
• Pagar uma penalidade de R$ 2,00. Colocar numa caixa selada, e depois de alguns meses, ao abrir a caixa, o ScrumMaster dobra a quantia e o time gasta em conjunto. Se estiver vazia, o Scrum Master parabeniza o time, colocar R$ 100,00 na caixa, e o time decide como gastar a grana: sorvete, pizzas, ingressos para festas, cerveja, uma nova máquina de café, etc.
• Encher o refrigerador do time com caixas de sorvete
• Fazer a daily Scrum em um escritório vazio, e trancar a porta no horário combinado para início. A penalidade de perder a Daily Scrum e se sentir de fora do time é tão grande que as pessoas param de se atrasar.
• Humilhação pública sem pena, com muita risada
• “Nossos desenvolvedores são muito anti-sociais, comparados ao restante da empresa. Então, quando eles se atrasam, nos forçamos que eles andem por aí e colham relatos de experiência ou melhoria com nossos usuários. Isso só aconteceu uma vez, desde então ninguém nunca mais se atrasou!“

Um grande obrigado a todos que responderam a thread original no Yahoo Groups!

Brincadeiras à parte, vale à pena dar uma olhada nas penalidades, e usar esse artigo como um “guideline” sobre como ter sucesso nas suas Daily Scrums.

Boa sorte!

Para o artigo original, em inglês, clique aqui.