Was ist der Zweck der "so dass" -Klausel in der User Story-Definition?

Eine User Story kann in einem Satz wie folgt definiert werden:

As a <type of user> I want <some goal> so that <some reason>

Nur Google für "User Story Formel" und erste Links schlagen alle diese Formel vor.

Meine Frage ist, was ist der Zweck dieser Klausel? Ist es für Manager da? Gibt es diese Möglichkeit, damit Projektmanager und Stakeholder die Priorität des Elements besser verstehen können? Warum ist es dort?

Hinweis: Ich habe mit as a <type of user> I want <some goal>Formeln gearbeitet und es funktioniert einfach gut. Ich habe kein Problem in meiner Arbeit bemerkt, als ich dieses Format implementiert habe, das kurz ist.

Der Zweck besteht darin, unnötige Arbeit zu vermeiden, indem der Benutzer / Kunde gezwungen wird, einen soliden, greifbaren Geschäftsnutzen als Grund für das Vorhandensein dieser Funktion bereitzustellen.

Es ist nicht ungewöhnlich, dass Funktionen hinzugefügt werden, nur weil jemand dachte, dass sie cool klingen, oder weil andere Software sie hat, also müssen auch unsere sie haben. Meistens sind diese zumindest völlig unnötig, wenn nicht sogar aktiv schädlich.

In der Regel ist es jedoch leicht, diese Funktionen zu erkennen, da die Personen, die sie vorschlagen, im Allgemeinen Schwierigkeiten haben, einen überzeugenden Geschäftsgrund für sie anzugeben.

Es gibt eine Technik namens Popping The Why Stack , bei der Sie den Teil "so dass" nehmen und "Warum?" Fragen. Dann nehmen Sie diese Antwort und fragen "Warum?" wieder rekursiv. Wenn Sie nach (sagen wir) drei bis fünf "Warum" entweder "weil es uns Geld bringt" oder "weil es uns Geld spart" (vorzugsweise mit einer genauen Beschreibung, wie das genau ist) nicht angekommen sind wird passieren), dann lohnt es sich nicht, die Funktion zu implementieren.

Einige Leute glauben, dass dies so wichtig ist, dass sie es tatsächlich an die erste Stelle in der Story-Vorlage setzen:

Damit [...]

Als ein [...]

Ich will [...]

Es gibt ein großartiges Beispiel aus einem Vortrag einiger Thoughtworks-Leute: Einer ihrer Kunden wollte, dass die gedruckten Berichte auf eine sehr eigenartige Weise formatiert werden. Als der Berater nach dem "Warum" fragte, sagten sie, dass sie auf diese Weise einfacher wieder einzugeben seien. Anstatt die Berichtsformatierungsfunktion zu implementieren, haben sie die Berichte einfach über das Netzwerk übertragen. Ohne die "so dass" -Klausel würden sie immer noch die Papiere in einer Abteilung ausdrucken, sie an die andere Abteilung senden und sie wieder eingeben.

Das "so dass" liefert einen Grund für das Ziel.

Das Ziel könnte beispielsweise sein, die Verkaufszahlen des letzten Monats anzuzeigen. Sie könnten damit arbeiten, aber ein Grund, warum Sie wissen müssen, warum Sie sie anzeigen möchten, damit Sie die tieferen Anforderungen erfüllen können. Was wollen sie mit den Verkaufszahlen oder Interessenten machen? Wenn Sie diese Informationen kennen, erhalten Sie mehr Einblick in die Anwendung und haben mehr Möglichkeiten, eine Benutzeroberfläche zu entwerfen, mit der der Kunde das tun kann, was er möchte.

Eine andere Verwendung aus diesem Grund ist die Priorisierung von Geschichten. Wenn Sie zwei Geschichten haben:

Ich möchte die Verkaufszahlen des letzten Monats anzeigen.
Ich möchte eine Liste mit potenziellen Kunden anzeigen.

aber haben Sie nur die Ressourcen, um eine zu tun - welche tun Sie? Ohne den Grund würden Sie nur raten und möglicherweise nicht rechtzeitig den richtigen liefern. Dies ist zwar weniger wichtig, da der Kunde Ihnen zuerst sagen sollte, was zu tun ist, aber gelegentlich ist dies nicht der Fall.

Zusätzlich zu dem Gesagten können Sie anhand der Angabe eines Grundes für die Anforderungen die Gültigkeit der Anforderung beurteilen. Der Benutzer möchte möglicherweise Dinge aus dem falschen Grund. Wenn das "so dass" den Grund klarstellt, kann der Analyst überprüfen, ob die Anfrage auf diese Weise am besten erfüllt wird.

Beispiel:

AI möchte Mitarbeiter aus einer Liste aller Mitarbeiter des Unternehmens auswählen können

BI möchte Mitarbeiter aus einer Liste aller Mitarbeiter des Unternehmens auswählen können, damit ich diejenigen löschen kann, die das Unternehmen vor 5 Jahren verlassen haben.

(B) ist selbst in einer mittleren Organisation nicht sinnvoll, aber Sie können die Benutzeranforderung validieren und dem Kunden eine andere Möglichkeit vorschlagen, die Anforderung zu erfüllen.