Ideia principal

Uma entrevista com cliente não fica aproveitável só por virar um cartão. Ela fica aproveitável quando é transcrita, dividida em temas, ligada às dores expressas, aos desafios do cliente, aos desafios do produto, às funcionalidades existentes e às que faltam, cruzada com outras entrevistas e depois verificada nos dados do produto. Todo esse trabalho é sobre relações; uma lista, por construção, só conhece elementos e a ordem deles.

Por isso a expressão "backlog de discovery" aponta um recipiente ruim, e não uma prática ruim. A discovery manipula um material rico que precisa ser comparado, ligado, cruzado, reformulado e sintetizado. O que a discovery produz pode obviamente acabar em cartão — mas só no fim, quando um resultado está maduro o bastante para uma colaboração estruturada.

Por que isso importa

Isso dá um critério para escolher um recipiente: antes de perguntar se a ferramenta tem os campos certos, olhe se o material vale pelos seus elementos ou pelas ligações entre eles. Só a resposta a isso decide a forma.

Isso também explica por que uma entrevista despejada direto em tickets se perde: cada cartão sobrevive, mas a estrutura que os ligava nunca foi escrita em lugar nenhum.

Nuances e limites

Uma lista pode se aproximar da relação com tags, links entre cartões ou epics. O custo de manter essas ligações cresce mais rápido que o número delas, e são as primeiras a ceder.

E nem todo material é relacional: uma fila de execução — corrigir, entregar, verificar — é bem descrita por uma lista ordenada.

Questões em aberto

• Em que momento um resultado de discovery está estável o bastante para perder suas relações sem perder o sentido?