Idea principale

La user story è stata concepita come una promessa di discussione: una frase breve, volutamente incompleta, che serve a riunire le persone giuste attorno al tema. Trattata come un contratto, diventa il contrario — un testo che si esegue senza parlare con chi l'ha scritto, e che poi serve a stabilire chi aveva torto.

La conseguenza pratica riguarda chi riceve la scheda. Uno sviluppatore non dovrebbe accettare un ticket che non capisce: se mancano elementi per valutare la fattibilità, li chiede; se manca il contesto di business, lo chiede; se non vede il valore, lo dice. Questo rifiuto non è un'obiezione di principio, è il modo in cui l'artefatto va usato.

Perché è importante

Sposta la responsabilità della qualità di un ticket. Non sta interamente dalla parte di chi scrive: la scheda è un punto di partenza, e chi la prende in carico ha il dovere di farla completare.

Spiega anche perché il continuo miglioramento dei template non risolve nulla. A un ticket non compreso non manca un campo in più: manca una conversazione che non c'è stata.

Sfumature e limiti

Non tutte le organizzazioni possono contare sulla conversazione: team remoto su più fusi orari, fornitore esterno, rapporto contrattuale. Lì lo scritto si fa carico di un peso per cui non era pensato, e va accettato come un costo, non come una norma.

E uno sviluppatore che mette in discussione ogni scheda può anche bloccare il flusso: chiedere chiarimenti presuppone di saper distinguere una mancanza reale da un semplice disagio.

Domande aperte

• Chi paga la conversazione che non c'è stata, quando la consegna è conforme a ciò che era scritto?