Lo scopo è evitare il lavoro non necessario costringendo l'utente / cliente a fornire un vantaggio aziendale solido e tangibile come ragione per l'esistenza di questa funzionalità.
Non è raro che le funzionalità vengano aggiunte solo perché qualcuno ha pensato che suonasse interessante, o perché altri software ce l'hanno, quindi anche il nostro deve averlo. Più spesso, quelli sono almeno completamente inutili, se non addirittura dannosi.
Tuttavia, di solito è facile individuare tali caratteristiche, perché le persone che le propongono generalmente avranno difficoltà a fornire loro un motivo aziendale convincente.
Esiste una tecnica chiamata Popping The Why Stack , dove prendi la parte "so that" e chiedi "Perché?", poi prendi quella risposta e chiedi "Perché?" di nuovo, in modo ricorsivo. Se, dopo (diciamo) da tre a cinque "Perché", non sei arrivato nemmeno a "perché ci farà guadagnare soldi" o "perché ci farà risparmiare denaro" (preferibilmente con una descrizione precisa di esattamente come succederà), quindi la funzionalità non vale la pena implementarla.
Alcuni credono che questo sia così importante da metterlo in pratica prima nel modello di storia:
In order to [...]
As a [...]
I want to [...]
C'è un grande esempio da un discorso di alcune persone di Thoughtworks: uno dei loro clienti voleva che i report stampati fossero formattati in un modo molto particolare. Quando il consulente ha chiesto "Perché", hanno detto che in quel modo erano più facili da digitare. Quindi, invece di implementare la funzione di formattazione del report, hanno semplicemente trasferito i report sulla rete. Senza la clausola "so that", avrebbero ancora stampare i fogli in un reparto, spedirli all'altra parte e inserirli nuovamente.