Ainda usa Story Points? Sério? Deve ser pegadinha de primeiro de Abril!

Mas falando sério, este assunto sempre volta e não tem uma vez nos meus treinamentos que os meus alunos não querem discutir Story Points. Acho até engraçado, porque quando você de fato trabalha nesta posição vai se dar conta rapidinho que isso não faz muito sentido. Agora, para POs novatos este erro é perdoável. Vamos falar sobre isso então!

O Que São Story Points?

Primeiramente para deixar bem claro, Story Points não fazem parte de Scrum (Aliás nem User Stories e Epics) e quem inventou isso foi... Ron Jeffries, um dos inventores do XP (Extreme Programming). Só para lembrar que a turma do XP teve uma grande influência no movimento ágil - pelas suas práticas técnicas (As principais sendo Pair Programming, Integração Contínua, Testes de Clientes e TDD) e pela sua abordagem cultural (delineada no famoso Manifesto Ágil onde tanto Ron Jeffries e Kent Beck são signatários).

Ron inventou Story Points porque cansou de brigar com os clientes sobre estimativas. Clientes querem saber quando vai estar pronto e ponto final. Da para entender perfeitamente, imagina você pergunta para o organizador da sua festa de casamento quando vai estar pronto e te respondem "Não da para saber!" não é aceitável! E convenhamos, todos nos desenvolvedores já estivemos do lado do cliente quando nós éramos clientes!

A Simplicidade Sedutora de Story Points

O problema é dar estimativas sobre coisas que você não tem um controle perfeito. E foi para isso que Ron inventou estes pontos. Para poder evitar dar prazos específicos. Pontos são unidades abstratas que basicamente representam estimativas de esforço do time. De certa forma, isto acaba incluindo noções como tamanho, ordem de grandeza, complexidade e de tudo um pouco.

Na prática pode funcionar bem com frameworks como Scrum, porque permite começar a trabalhar de forma mais empírica. Nem tanto para projetar, mas para medir o quanto foi de fato entregue.

Aqui Cabe um Exemplo:

Imagine um time que estima que pode entregar itens A, B, e C. E estimaram o esforço em 3, 2 e 5 respectivamente. Quando o time de fato entregou estes itens podemos dizer que o time provou ser capaz de entregar 3+2+5 pontos, passaram a concluir que a velocidade do time é então 10 pontos por ciclo.

Veja só, os clientes podem agora concluir que no futuro, o time sempre deveria ser capaz de entregar pelo menos 10 pontos de esforço. A simplicidade disso realmente é sedutora!

Só que na prática não funciona! Com o tempo o business deu um jeito de driblar isso de novo. Hoje, Ron Jeffries lamenta ter inventado estes malditos pontos!

Vamos explorar isto um pouco.

Porque Usar Story Points Mesmo?

Nos meus treinamentos de Product Owner quando a gente discute Sprint Planning - ou seja, quando o time planeja um cíclo de trabalho, o assunto Story Points sempre é citado: "É aqui que vamos usar os Story Points?".

Faço questão de perguntar: "Porque?". As vezes, sinto que ficam sem graça, mas insisto. No final geralmente surgem 3 tipos de respostas:

1. Reporting para a liderança

2. Preocupação que o time faz corpo mole

3. Saber quanto trabalho cabe no ciclo de trabalho (Sprint)

Vamos explorar como Story Points podem (ou não) ajudar nestes cenários, e vou dar a minha opinião de Product Owner atuando em uma startup.

Reporting Para a Liderança

Usar Story Points, ou seja, estimativas de esforço para os nossos chefes, clientes, etc, é o pior dos usos de Story Points. A simplicidade de tudo isso seduz! Tudo fica reduzido a uns números simples, com a regra de três, da para fazer projeções e validar datas de entrega final. Só que com isso, os gestores vão ter uma alavanca (ou um chicote) na mão... muito sedutor de novo.

Na minha visão de PO que já trabalhou muito tempo como desenvolvedor em times ágeis e tradicionais, o que acaba acontecendo é pressão. Pode ser de forma mais ou menos sutil, isso acaba tirando a utilidade destes pontos. Tem dois problemas aqui, estes pontos são chutes! E quanto maior o número maior o chute! O tipo de trabalho que estamos discutindo é knowledge work, trabalho intelectual, e não trabalho braçal. Trabalho intelectual não é bem planejável, nem previsível. A palavra técnica que gostamos de usar é variabilidade. Uma certa tarefa pode durar uma hora, mas de repente vira 10 horas.

O outro problema aqui é que acham que desenvolvedores são burros. Imagina a seguinte situação: um time estimou 5 pontos para uma tarefa, mas na hora de executar ela, resultou que o esforço real, acabou sendo de uma coisa de 13 pontos. Quando a liderança faz cara feia, nós desenvolvedores percebemos isso. É desagradável, e nós desenvolvedores acabamos nos sentindo culpados. Eu me lembro perfeitamente disso. Por que não pensei nesta eventualidade? Nossa, por que demorei tanto para isso ou tal? Estas mensagens das caras feias (As vezes mais ou menos sutis) acabem minando a nossa confiança, autoestima e no final também a motivação.

Agora, fala a verdade, o que você faria na próxima rodada de estimativa? Continuaria estimando um 5, ou aumentaria (Só para ter mais certeza) para um 13? (eu sei o que eu faria).

O resultado geralmente é que o time vai inflar os pontos, vai se proteger, e assim se perde aos poucos a transparência e confiança. Os pontos acabam deixando o time mais lento pelo efeito da lei de Parkinson (Mas isso é assunto para outro Post).

PO Pode Fazer Projeções Com Story Points?

Tudo isso pode funcionar, porém precisa ter uma base de confiança entre o time ágil (e eu falo da perspectiva de times Scrum) e a liderança.

Fala a verdade, você colocaria o destino da tua empresa nas mãos de um time que você não conhece? Eu não! confiança se constrói, passo a passo, e precisa ser merecida!

Um bom PO precisa ter um diálogo constante com os seus Stakeholders, e sair da micro-gestão para uma gestão mais abrangente. Uma forma melhor de fazer reportings para os Stakeholder talvez seja usando Release-Burnup Diagrams, com a granularidade de User Stories entregues, não Story Points, e não em toda Sprint Review, mas a cada mês, ou cada 2 meses. Com esta ferramenta, podemos ver padrões que permitem discussões interessantes. Perguntas interessantes são: "Para uma certa data, quais funcionalidades podem estar prontas?", ou por outro lado: "Quantos ciclos de trabalho (Sprints) provavelmente serão necessários para entregar tal ou tal funcionalidade?". É importante ter um diálogo honesto, baseado na realidade, sem cair na armadilha do blame game, o jogo de apontar dedos.

Story Points Para Sanar Times que Fazem Corpo Mole?

Vamos aqui abordar mais uma típica preocupação (E ela vem geralmente de gerentes de projeto tradicionais que estão interessados em virar Product Owners).

"Como vou saber se o time faz corpo mole? Como posso ter certeza que o time faz o máximo possível?"

Se essa é a preocupação, no fundo no fundo a discussão aqui tem a ver com motivação. Usar Story Points para isso é fútil, porque como já vimos, o próprio time vai acabar se protegendo, e inflando as estimativas.

Mas eu entendo a preocupação!

Para um desenvolvedor é fácil fazer chacota disso! Posso te dizer uma coisa: na hora de você, querido desenvolvedor, pagar o custo de um time, a história geralmente muda! Imagina que você contrata um time para construir a sua casa, e ai você da uma olhada nos pedreiros. E pegou eles parados, fumando um cigarro, ou tomando café... e ai você pensa: "nossa, estou pagando eles, para fumar ou tomar café!!!". Mas antes que você for pegar o seu chicote, vamos refletir.

Mas eu entendo a preocupação!

O segredo da motivação de times Scrum é encontrar o equilíbrio certo entre liberdade/autonomia e disciplina. Autonomia é um gatilho forte de motivação, ter objetivos claros (Em forma de um Sprint Goal), é outro. Um Scrum Master competente sabe como criar um ambiente onde esta motivação intríncisa funciona - sem necessidade de um chicote.

Comparando com times tradicionais, acho que Scrum é muito mais transparente. Gosto de comparar um time Scrum como uma casa de vidro. A transparencia é brutal: o progresso do time pode ser acompanhado pelo Sprint Backlog, e o dia do juízo final está próximo de qualquer forma. Na Sprint Review todo o time - incluindo o PO, junto com os Stakeholders examinam do progresso - avaliando o resultado do trabalho.

Saber Quanto Trabalho Cabe no Ciclo de Trabalho (Sprint)

Claro, você pode usar Story Points para tentar planejar a sua Sprint. Se você sabe, por exemplo, que em média o seu time entrega, digamos 10 pontos por Sprint, basta selecionar itens do Product Backlog até atingir estes 10 pontos. (agora, fala verdade, quando isso realmente funcionou na prática? Quantas vezes conseguiram entregar o Sprint Goal assim?)

Eu considero esta forma de planejar preguiçosa... e na minha própria experiência não vale a pena o tempo que se gasta para chegar aos Story Points. Em vez disso, sugiro usar este tempo para analisar mais fundo todos os detalhes do trabalho. A prática que o nosso time usa se baseia em BDD: Behavior Driven Development. De forma bem simplificada funciona assim:

1. O time pega um item do Product Backlog para análise

2. Discutem diversos exemplos de como funcionaria, focando em exemplos concretos e não genéricos. Uma regra de negócio geralmente pode ser descrita assim por vários exemplos diferentes.

3. Cada exemplo ilustra um "comportamento" e representa uma fina fatia de valor (O nome técnico para isso é um cenário)

4. Cenários são a seguir especificados por uma descrição em Gherkin. Estes cenários são escritos como se fossem em português, com algumas palavras padronizadas como "Dado... Quando... Então..."

O que a gente vê, em geral é que cada Item do Backlog assim examinado contem uma série de cenários. Cenários facilitam muito o fatiamento do trabalho. Cada cenário pode ser desenvolvido e entregue separadamente!

Quando o time faz esta análise com cada item vai ficar bem mais claro se o trabalho cabe ou não na Sprint. Se um requisito inteiro for julgado como grande demais, então o Product Owner pode escolher quais dos cenários seria o mais importante e pode deixar os cenários menos importantes para futuros Sprints.

Para criar ainda mais clareza, recomendo como passo seguinte, uma técnica chamada de Task Mapping:

Task Mapping

A partir de um cenário (uma fina fatia de um requisito que representa valor), o time inteiro faz um Brainstorming silencioso para descobrir as tarefas técnicas. Tarefas técnicas são atividades como: testar, programar, criar design, trabalhos Front-End, trabalhos Back-End, tarefas de deploy, etc. O truque é entrar em detalhes mesmo. Por exemplo na hora de testar: que tipo de testes: unitários, aceitação, integração, carga, tempo de resposta, etc. A mesma coisa vale para tarefas de programação: quais componentes: entidades, controladores, serviços, etc.

Outro aspecto importante: todos os integrantes tentam esmiuçar não-somente as próprias tarefas, mas também as tarefas dos outros!

Depois de um ciclo que pode durar 5 a 10 minutos, o time discute um a um as tarefas. Tarefas duplicadas são eliminadas, tarefas diferentes são explicadas, etc.

Esta discussão é muito valiosa porque o time se alinha sobre o trabalho, discute design e assim pode descobrir oportunidades de colaboração.

Sprint Backlog

Surge o Sprint Backlog

Depois deste planejamento, o time decidiu assim:

1. O Sprint Goal (o objetivo da Sprint)

2. Os itens do Product Backlog para implementar o objetivo da Sprint

3. Quais os cenários de cada item

4. Quais as tarefas de cada cenário

Parte do Sprint Backlog são todos os diagramas, desenhos, rabiscos, imagens que foram feitos durante o planejamento.

Agora ficou bem mais claro se todo este trabalho cabe na Sprint. O time pode decidir de novo, remover cenários, ou até simplificar design, tarefas, etc.

Isso sim, é um plano, que vale 1000x mais do que alguns números mágicos chamados Story Points.

Sprint Planning é trabalho sim! É trabalhoso sim! Não é a toa que o Scrum Guide recomenda até 4 horas para uma Sprint de 2 semanas. Na minha experiência, sempre valeu o investimento.