Ideia principal

A user story foi concebida como uma promessa de discussão: uma frase curta, deliberadamente incompleta, cuja função é trazer as pessoas certas para perto do assunto. Tratada como um contrato, ela vira o oposto — um texto que se executa sem falar com quem o escreveu, e que depois serve para estabelecer quem estava errado.

A consequência prática recai sobre quem recebe o cartão. Um desenvolvedor não deve aceitar um ticket que não entende: se faltam elementos para avaliar a viabilidade, ele os pede; se falta o contexto de negócio, ele o pede; se não enxerga o valor, ele diz. Essa recusa não é uma objeção de princípio, é o modo de usar o artefato.

Por que isso importa

Isso desloca a responsabilidade pela qualidade de um ticket. Ela não está inteiramente do lado de quem escreve: o cartão é um ponto de partida, e quem o pega tem o dever de fazê-lo ser completado.

Isso também explica por que a melhoria contínua dos modelos não resolve nada. O que falta a um ticket incompreendido não é um campo a mais, é uma conversa que não aconteceu.

Nuances e limites

Nem todas as organizações podem contar com a conversa: time distante em vários fusos, fornecedor externo, relação contratual. A escrita carrega ali um peso para o qual não foi feita, e isso precisa ser assumido como um custo, não como uma norma.

E um desenvolvedor que questiona cada cartão também pode travar o fluxo: o pedido de esclarecimento pressupõe saber distinguir a falta real do desconforto.

Questões em aberto

• O que acontece com a exigência de conversa quando a execução é entregue a um terceiro sob contrato?