Scrum poker em times Scrum

Em muitos times, “scrum poker” é só o apelido do planning poker: as cartas, o voto secreto e a revelação simultânea são os mesmos, e o passo a passo com uma rodada de exemplo está no guia de planning poker. Dentro de um time Scrum, a técnica precisa caber no calendário da sprint, alguém precisa conduzi-la, e às vezes a melhor decisão é nem estimar.

Story points não fazem parte do Scrum

Imagine uma retrospectiva em que alguém reclama que o scrum poker virou uma hora perdida por semana, e outra pessoa responde que “no Scrum tem que estimar”. Tem mesmo? O Scrum Guide pede que os itens do Product Backlog sejam refinados até ficarem pequenos o bastante para caber numa sprint, e atribui o dimensionamento a quem vai fazer o trabalho, os Developers. Como dimensionar, o guia não diz. Pontos, cartas, velocity e Fibonacci não aparecem no texto.

Isso muda o tom da discussão na retro. A pergunta útil passa a ser o que o time ganha com os números que produz. Se a planning usa os pontos para fechar uma sprint realista, a sessão se paga. Se não usa, dá para ajustar o formato antes de abandonar: votar só as histórias novas, só as que alguém acha grandes, ou fazer uma rodada rápida de tamanhos de camiseta e deixar os pontos para as que vão entrar na próxima sprint.

Refinamento ou Sprint Planning?

Pense numa sprint de duas semanas de um time que mantém o site de agendamento de atendimento de um órgão público, com login pelo gov.br. A Sprint Planning é na segunda de manhã. O refinamento é na quarta da primeira semana, das 14h às 15h, e olha as histórias que devem entrar na sprint seguinte: remarcação de horário, fila de espera por agência, envio do comprovante por e-mail.

O que se estima no refinamento

É aqui que a maior parte da votação deveria acontecer. Entre a quarta do refinamento e a planning da sprint seguinte há quase duas semanas, então um “?” não trava nada: a PO tem tempo de falar com a área de atendimento, alguém testa a API do gov.br, e a história gigante vira três menores sem correria. Refinamento, aliás, é o que alguns times ainda chamam de grooming.

O que sobra para a planning

Na segunda de manhã, com os pontos já dados, a Sprint Planning pode se concentrar no que é dela: definir o objetivo da sprint e conferir se o conjunto escolhido cabe na faixa de velocity do time. Estimar ali vira exceção, reservada para a história que mudou depois do refinamento, como quando uma portaria nova altera a regra de remarcação.

Times que deixam toda a votação para a planning pagam duas vezes. A reunião toma a manhã inteira, e as dúvidas que aparecem durante a votação não têm mais tempo de ser respondidas antes de a sprint começar. A história entra com a dúvida ainda em aberto.

O que o Scrum Master faz durante a votação

Em times onde o Scrum Master também programa, ele vota como qualquer dev. Quando não é o caso, uma carta dele teria pouca base, e o lugar dele na sessão é o de facilitador. Vale acompanhar uma quarta-feira de refinamento no time do agendamento para ver o que isso significa na prática.

Na véspera, o Scrum Master passa pelas histórias da pauta e devolve para a PO a que ainda não tem critérios de aceite. Na abertura da sessão, lembra em uma frase as regras combinadas: votam devs e QA, no máximo duas rodadas por história. Durante a história da fila de espera, percebe que a Bianca, do QA, não abriu o microfone e pergunta a ela como a fila deveria se comportar quando a agência fecha mais cedo. A pergunta vira a principal dúvida da rodada.

Depois da revelação, ele segue a regra de sempre, com o maior e o menor voto explicando primeiro, e presta atenção em quem muda de voto na segunda rodada sem ter ouvido argumento novo. Quando uma história não fecha, ele a tira da pauta sem drama; a regra das duas rodadas está no guia de planning poker. No fim, manda no canal do time a lista de dúvidas abertas, cada uma com um nome ao lado, para que o próximo refinamento comece com as respostas.

Quando a estimativa vira negociação

Um cenário frequente: o time vota 13, e a PO ou alguém da gestão responde que “isso precisa entrar nessa sprint, não dá para ser 5?”. Aqui o Scrum Master tem uma função que nenhuma ferramenta cumpre. A estimativa é do time. O que pode ser negociado é o escopo: tirar o envio do comprovante da história, deixar a fila de espera para depois, entregar primeiro só para uma agência. Se o número for reduzido na conversa, sem o trabalho ter diminuído, a sprint estoura e a velocity passa a mentir.

O mesmo vale para bug, spike e débito técnico. Cada time decide se pontua ou não esses itens, mas precisa manter a decisão de uma sprint para outra. Mudar o critério no meio do trimestre para “caber mais” é outra forma de negociar o número.

“?” e ☕ na mesa

Para o Scrum Master, as duas cartas também dizem algo sobre o processo: muitos “?” na mesma sessão costumam indicar que as histórias chegaram cruas, e ☕ em toda sessão, que ela está longa demais. O que fazer com cada carta durante a rodada está em as cartas especiais.

Quando o scrum poker não compensa

Algumas situações pedem outro tipo de conversa.

Trabalho medido por tempo, não por tamanho. Descoberta de produto, protótipo para validar com usuários, apoio à homologação de um cliente. Nesses casos o time decide quanto tempo quer investir, por exemplo três dias, e o tamanho da tarefa é esse limite. Votar pontos para ela só cria um número que ninguém vai usar.

Time de sustentação. Quando a sprint é quase toda atendimento a incidentes, como notas fiscais rejeitadas ou conciliação bancária que não bate, a demanda chega todo dia e não espera refinamento. Kanban com acompanhamento do tempo de ciclo costuma servir melhor que estimar item a item.

Mudança obrigatória com data marcada. Um novo leiaute exigido pela SEFAZ ou uma regra do Banco Central com prazo definido: essa mudança vai ser feita de qualquer jeito. Uma estimativa de ordem de grandeza, feita em cinco minutos, basta para saber quanto sobra de espaço na sprint; uma sessão completa de cartas raramente muda alguma decisão.