A Story Foi Arrastada Por Quatro Sprints

Sprint 1: arrastada.

Sprint 2: arrastada.

Sprint 3: arrastada.

Segunda de manhã.

Sprint 4.

E lá está ela de novo.

ABC-142.

Mesmo título.

Mesma pontuação de story.

Mesma sensação levemente incômoda quando alguém pergunta:

“O que falta nessa aí?”

Alguém diz:

“Está quase pronta.”

O que é interessante.

Porque também estava quase pronta há três semanas.

Nesse ponto, eu não perguntaria:

“Como a gente termina essa story?”

Eu perguntaria:

“Por que essa story sobreviveu quatro sprints?”

Porque uma story que fica sendo arrastada geralmente está te dizendo alguma coisa.

O erro é tratar o próprio arrasto como o problema.

Vamos abrir o ticket.

Primeiro, pare de chamar de “quase pronta”

A ABC-142 diz:

Status: In Progress

O último comentário diz:

“Desenvolvimento quase completo. Aguardando validação final.”

Parece razoável.

Mas “quase pronta” não é particularmente útil.

Então pergunte:

O que exatamente está inacabado?

Não:

“Quanto falta?”

Não:

“Que porcentagem está completa?”

Nomeie de verdade o que resta.

A gente pergunta ao desenvolvedor.

Acontece que:

• A UI está pronta.
• As mudanças de backend estão prontas.
• A integração de API está pronta.
• O teste unitário está pronto.

Então o desenvolvimento não é realmente o problema.

O QA está esperando.

Certo.

Agora temos onde procurar.

A story não está bloqueada por tudo

Essa é uma distinção útil.

Uma story pode parecer travada como um objeto único.

Mas geralmente só uma parte está realmente travada.

A ABC-142 está sentada em “In Progress” há semanas.

Isso dá a impressão de que a story inteira está inacabada.

Não está.

A maior parte está pronta.

O problema que resta é:

O QA não consegue completar um cenário de teste.

Bem melhor.

Agora pergunte:

Por quê?

O QA diz que o comportamento esperado não está claro

O cenário é simples.

Um serviço upstream normalmente retorna dados de risco do cliente.

Mas às vezes o serviço não retorna nenhum registro.

O QA pergunta:

“O que deveria acontecer quando nenhum registro de risco é retornado?”

Os critérios de aceitação dizem:

O sistema deve tratar a resposta de forma apropriada.

Essa palavra ali.

Apropriada.

O desenvolvimento interpretou isso como:

Continuar o processamento.

O QA interpretou como:

Parar o processamento e mostrar um erro.

O negócio não confirmou nenhuma das duas.

Então agora sabemos algo importante.

A ABC-142 não está realmente esperando o QA.

O QA está esperando um requisito.

Então a gente checa o requisito

Talvez a resposta já esteja em algum lugar.

A gente olha o ticket inteiro.

Descrição.

Nada.

Critérios de aceitação.

Nada.

Página do Confluence linkada.

Nada.

Depois chegamos nos comentários.

Comentário #38:

“Precisa de confirmação do negócio sobre o comportamento esperado quando nenhum registro de risco é retornado.”

Postado há 13 dias.

Sem resposta.

Ali está.

Quatro sprints de arrasto.

E o bloqueio real é uma pergunta sem resposta dentro de um comentário do Jira.

A story não estava bloqueada pelo desenvolvimento.

Também não estava realmente bloqueada pelo QA.

Estava bloqueada por uma decisão que ninguém tinha tornado visível.

É por isso que o arrasto é uma informação útil

É tentador tratar o arrasto como um problema de planejamento.

Talvez a estimativa tenha sido ruim.

Talvez o time tenha assumido trabalho demais.

Talvez a velocidade esteja caindo.

Às vezes é exatamente isso que aconteceu.

Mas o arrasto repetido merece uma pergunta diferente.

Não:

Por que estamos lentos?

Pergunte:

Que tipo de trabalho inacabado continua sobrevivendo ao limite do sprint?

Porque “inacabado” pode significar coisas muito diferentes.

Existem pelo menos seis tipos de inacabado

Quando vejo uma story sendo arrastada repetidamente, tento classificar o bloqueio.

1. Inacabado técnico

Genuinamente ainda falta trabalho de implementação.

O código está incompleto.

A integração está incompleta.

Um problema técnico não foi resolvido.

Direto ao ponto.

2. Inacabado de requisito

O time não sabe de verdade o que o sistema deveria fazer.

Talvez:

• os critérios de aceitação não estão claros
• uma exceção não foi definida
• uma regra está faltando
• dois stakeholders interpretam o requisito de formas diferentes

O código pode estar esperando por entendimento.

3. Inacabado de dependência

Seu time terminou a parte dele.

Mas vocês estão esperando por:

• outro time
• uma API
• infraestrutura
• ambiente de teste
• fornecedor
• dado de referência
• aprovação

A story está tecnicamente “em andamento”, mas o trabalho que resta está em outro lugar.

4. Inacabado de teste

O desenvolvimento pode estar completo.

Mas o comportamento ainda não foi comprovado.

Talvez:

• falta dado de teste
• o ambiente de QA está quebrado
• os casos de teste não estão claros
• defeitos permanecem
• a validação do negócio não aconteceu

Problema diferente.

Responsável diferente.

5. Inacabado de escopo

Esse é traiçoeiro.

Toda vez que alguém mexe na story, mais alguma coisa é adicionada.

“Já que estamos aqui, dá pra gente também…”

Depois:

“Esse caso extremo provavelmente deveria estar incluído.”

Depois:

“A gente deveria dar suporte para outro mercado também.”

A story não termina porque a linha de chegada continua se movendo.

6. Inacabado de decisão

Alguém precisa escolher.

Opção A ou B.

Aprovar ou rejeitar.

Incluir ou excluir.

Falhar ou continuar.

Mas ninguém decidiu isso claramente.

Foi o que aconteceu com a ABC-142.

E isso é incrivelmente comum.

Se uma story continua voltando, isso é a primeira coisa que eu tentaria identificar.

Voltando à ABC-142

Agora que sabemos o bloqueio, o próximo passo fica óbvio.

Em vez de dizer:

“Ainda pendente de QA.”

a gente atualiza a story:

Bloqueio

O comportamento esperado não está definido para quando o Serviço de Risco upstream não retorna nenhum registro do cliente.

Decisão necessária

A transação deveria:

A. Continuar o processamento sem dado de risco?

ou

B. Parar o processamento e mostrar um erro?

Responsável pela decisão

Operação de Risco

Impacto

O QA não consegue completar o Cenário AC-07 até o comportamento esperado ser confirmado.

Responsável

Business Analyst

Agora o problema está visível.

Isso sozinho já é uma melhoria.

Um status vermelho vago virou uma decisão específica.

Depois pergunte se isso ainda deveria ser uma story só

Existe outra pergunta que vale a pena fazer depois de vários arrastos:

Isso ainda é de verdade um único pedaço coerente de trabalho?

Imagine que a ABC-142 contém:

• UI nova
• serviço de backend
• integração de API
• migração de dados
• mudança de relatório
• log de auditoria
• cinco regras específicas por mercado

E seis dessas coisas estão prontas.

Em algum momento, manter tudo dentro de uma story só para de ajudar.

Talvez o escopo concluído possa ser separado.

Talvez a parte inacabada mereça o próprio ticket.

Talvez a story original fosse simplesmente grande demais.

O ponto não é dividir stories só para melhorar métricas.

A pergunta é:

Manter tudo isso junto ainda nos ajuda a entender e entregar o trabalho?

Se não, reestruture.

Verifique se a story mudou enquanto as pessoas estavam construindo ela

Agora olhe o histórico.

Como era a ABC-142 no Sprint 1?

Como ela é agora?

Talvez critérios de aceitação tenham sido adicionados durante o Sprint 2.

Outro mercado foi adicionado no Sprint 3.

Uma exceção apareceu durante o QA.

Uma mudança de relatório foi adicionada semana passada.

Isso é útil porque às vezes uma story não “levou quatro sprints”.

Quatro versões diferentes da story levaram quatro sprints.

Isso é um problema diferente.

Olhe:

• histórico da descrição
• mudanças nos critérios de aceitação
• escopo recém-adicionado
• comentários contendo decisões
• defeitos linkados
• novas dependências

Se o requisito continua mudando depois que a implementação começa, aponte isso.

Não esconda dentro do número de arrasto.

Pergunte se o QA encontrou um defeito ou um requisito faltando

Essa distinção importa.

Suponha que o QA diga:

“O sistema não mostra um aviso quando a resposta upstream vem vazia.”

O aviso era obrigatório?

Se sim:

Defeito.

A implementação não atendeu a um requisito acordado.

Se ninguém nunca decidiu o que deveria acontecer:

Lacuna de requisito.

Isso não deveria ser tratado como a mesma coisa.

Do contrário os times acabam registrando defeitos contra um comportamento que ninguém nunca especificou.

E isso cria um ciclo estranho:

Nomeie o problema real.

Encontre o responsável pelo bloqueio

“Esperando o negócio” não é responsabilidade.

“Bloqueado por outro time” não é responsabilidade.

“Pendente de esclarecimento” não é responsabilidade.

Pergunte:

Quem é a pessoa responsável por conseguir a próxima resposta ou ação?

Não necessariamente a pessoa que precisa tomar a decisão.

Para a ABC-142:

A Operação de Risco é dona da decisão.

Mas o BA pode ser dono de conseguir essa decisão.

Isso significa:

Responsável pela decisão

Operação de Risco

Responsável pela próxima ação

BA

Próxima ação

Marcar a decisão com a Operação de Risco

Prazo

Terça-feira

Agora alguma coisa consegue andar.

O teste de arrasto de cinco minutos

Da próxima vez que uma story chegar em outro sprint, faça essas cinco perguntas.

1. O que exatamente está inacabado?

Seja específico.

Não:

“Teste.”

Em vez disso:

“O QA não consegue completar o AC-07 porque o comportamento esperado para resposta vazia não está definido.”

2. Por que está inacabado?

Encontre o tipo de bloqueio.

Técnico?

Requisito?

Dependência?

Teste?

Escopo?

Decisão?

3. Quem ou o que estamos esperando?

Nomeie.

Pessoa.

Time.

Sistema.

Ambiente.

Decisão.

4. A parte concluída pode ser separada?

Talvez sim.

Talvez não.

Mas pergunte.

Manter trabalho concluído preso dentro de uma story enorme pode não ajudar ninguém.

5. Qual é a próxima ação concreta?

Não:

“Fazer follow-up.”

Algo real.

“Operação de Risco confirma o comportamento de falha-vs-continuação até terça-feira.”

Agora dá pra gerenciar isso de verdade.

O que aconteceu com a ABC-142?

A Operação de Risco eventualmente confirma:

Se nenhum registro de risco do cliente for retornado, o processamento deve parar e a transação deve entrar em Revisão Manual.

Ótimo.

Agora atualizamos o requisito.

Regra de Negócio

Transações sem um registro de risco do cliente disponível não devem prosseguir automaticamente.

Critério de Aceitação

Dado que nenhum registro de risco do cliente é retornado
Quando a validação da transação roda
Então o processamento para
E a transação entra em status de Revisão Manual.

O QA testa.

Passa.

A ABC-142 fecha.

O trabalho de desenvolvimento não foi o que levou quatro sprints.

O comportamento sem resposta foi.

Essa distinção importa.

Uma story pode estar verde e ainda estar travada

Essa é outra armadilha.

Times costumam usar o status do Jira como atalho para saúde.

To Do.

In Progress.

Testing.

Done.

Mas o status não diz se o entendimento está avançando.

Uma story pode ficar em “In Progress” enquanto absolutamente nada útil acontece por dez dias.

Então, quando alguma coisa é arrastada repetidamente, ignore o status por um minuto.

Pergunte:

O que mudou nessa story durante o último sprint?

Uma decisão foi tomada?

Um bloqueio foi removido?

Uma dependência foi entregue?

Algo foi testado?

O escopo foi esclarecido?

Se a resposta é basicamente nada, mover para outro sprint não vai mudar isso magicamente.

Não culpe a estimativa automaticamente

Às vezes o time simplesmente subestimou o trabalho.

Claro.

Mas o arrasto repetido também pode ser sintoma de:

• requisitos vagos
• dependências escondidas
• decisões atrasadas
• aumento de escopo
• divisão ruim de stories
• dado de teste faltando
• problemas de ambiente
• responsabilidade pouco clara

Se você tratar todo arrasto como “estimativa ruim”, pode acabar gastando horas ajustando pontos de story enquanto o bloqueio real fica intocado.

Por isso o diagnóstico vem primeiro.