Wie wähle ich die richtige Perspektive in User Stories?

Ein wesentlicher Teil des Zwecks einer User Story besteht darin, den Bedarf aus der Perspektive des Benutzers zu verstehen. Als solches möchten Sie ihre Bedürfnisse erkunden. Dies sollte ihre Perspektive sein und sich auf ihre Bedürfnisse konzentrieren, nicht auf die Lösung. Zum Beispiel könnte ich eine User Story schreiben, die lautet:

Als neu registrierter Vertriebspartner für ACME Corp möchte ich eine Bestätigung meiner Registrierung per E-Mail erhalten, damit ich weiß, dass sie ordnungsgemäß durchgeführt wurde.

Es ist auch wichtig, daran zu denken, dass nicht alle Backlog-Elemente User Stories sein müssen. Ich könnte einfach sagen:

Formatieren Sie die Bestätigungs-E-Mail neu, damit sie mit dem neuen Branding-Leitfaden übereinstimmt.

So etwas kann nützlich sein, wenn Sie etwas mit einer bestimmten Lösung wiederholen müssen. Wenn ich alternativ ein neues Projekt mit E-Mails durchführen würde, würde ich wahrscheinlich etwas in meine Definition von erledigt aufnehmen, das besagt:

Die gesamte Kommunikation entspricht dem Branding Style Guide.

und es wäre niemals ein Backlog-Item, sondern würde für alle Backlog-Items gelten.

Ich frage mich, welche der beiden Perspektiven für das Entwicklungsteam, das meine Geschichten implementieren wird, am nützlichsten ist?

Ganz ehrlich? Keiner. Am nützlichsten ist das Gespräch, das Sie (als PO) mit dem Entwicklerteam über die User Story führen , indem Sie ihnen erklären, was getan werden muss und was die Akzeptanzkriterien für diese spezielle Funktionalität sind.

Eine einen Satz lange Aussage darüber, was Sie wollen, reicht meist nicht aus, um alles zu verstehen, was umgesetzt werden muss. User Stories sind keine detaillierten Anforderungen . Sie drücken aus, was die Anwendung für den Benutzer tun soll. Sie stammen aus der „Benutzer“-Perspektive, deshalb werden sie „Benutzergeschichten“ genannt.

Anhand Ihres Beispiels könnte meine Vorstellung einer User Story etwa so aussehen:

Als Benutzer der Anwendung möchte ich relevante Marketing-E-Mails erhalten, damit ich von den besten Angeboten profitieren kann

... oder Wasauchimmer.

Nirgendwo in meinem Beispiel ist "wie" angegeben. Wie ist die E-Mail formatiert? Wie ist die E-Mail gestaltet? Wie wird die E-Mail versendet? Diese sind Teil der Diskussionen, die der PO und das Entwicklerteam über die User Story führen müssen, wenn es an der Zeit ist, sie zu implementieren. Als Benutzer ist mir das wirklich egal, ich möchte nur, dass die Anwendung es irgendwie macht. Es ist geschäftlich sinnvoll, dass die E-Mail das Branding Ihres Unternehmens trägt, aber das ist Ihr Akzeptanzkriterium als Anbieter der Anwendung, nicht unbedingt meins als Benutzer der Anwendung (dies zeigt ein weiteres Problem mit User Stories, manchmal werden sie nicht geschrieben von echte Benutzer, sondern von jemandem aus der Wirtschaft, der "denkt", zu wissen, was die echten Benutzer wollen).

Dann muss nicht alles im Backlog eine User Story sein. Wie wäre es mit Fehlern? Schreiben Sie Bug Issues aus der Perspektive des Benutzers? Es ist lächerlich, oder? Irgendwie versuchen die Leute jedoch, alle Features, Funktionen, Anforderungen, technischen Änderungen und Implementierungen usw. in User Stories zu zwingen, und denken, dass dies in Ordnung ist. Aber es ist nicht. Es erzeugt nur Verwaltungsaufwand, da die Leute viel Zeit damit verbringen, „die perfekte User Story“ nach einem einschränkenden Muster zu schreiben, anstatt zu spezifizieren, was in einer natürlichen Sprache benötigt wird, und dann darauf basierend weitere Details zu diskutieren. Manchmal geht das über Bord und man endet mit Anomalien wie „Als Entwickler möchte ich eine Back-End-API, damit ich ein reichhaltiges Front-End implementieren kann“, was als User Story formuliert ist, aber keine User Story ist.

Ein Artikel wie der folgende ist in Ordnung:

Alle E-Mail-Kommunikationen mit Benutzern sollten ordnungsgemäß gestaltet/formatiert sein

Denk nicht darüber nach . Solange jeder versteht, was es bedeutet und was gebaut werden muss (was selten aus nur einem Satz verstanden wird - also das Gespräch, das Sie führen müssen), muss es nicht in ein "Als [Benutzertyp] bin ich gezwungen werden will [etwas], damit [irgendein Grund]"-Muster.

Wenn es Ihnen schwer fällt, es aus der Perspektive des Benutzers auszudrücken, dann schreiben Sie es vielleicht nicht als User Story .

In der Regel werden User Stories unter dem Gesichtspunkt des Endnutzerwerts geschrieben.

Als Empfänger einer E-Mail-Benachrichtigung möchte ich, dass meine neuen Nachrichten alle so gestaltet sind, dass sie leicht als von ACME Corp. gesendet identifiziert werden können.

Das würde funktionieren, wenn es für den Endbenutzer wertvoll ist, E-Mails einfach zu identifizieren.

Ich als Brand Manager von ACME Corp. möchte, dass alle per E-Mail gesendeten Nachrichten unsere Corporate Style Guides anwenden?

Dies würde normalerweise nicht funktionieren, da ich vermute, dass es den meisten Endbenutzern egal ist, ob eine E-Mail dem Corporate Style Guide folgt.

Es mag sich anfühlen, als wäre der Markenmanager ein Kunde für die User Story, aber in diesem Fall glaube ich nicht, dass er das ist. Dies liegt daran, dass der Markenmanager keinen direkten Wert aus der Geschichte zieht und kein echter interner Kunde ist.

Es gibt Produkte, die intern einen direkten Mehrwert liefern. Angenommen, Sie haben eine interne Anwendung geschrieben, mit der der Marketingleiter seine Marketingkampagnen koordinieren kann. Das ist ein internes Produkt und somit ist der Endbenutzer eine interne Person.

Ich würde empfehlen, dass Sie Benutzergeschichten aus der Perspektive beider Benutzer schreiben, da beide Benutzer unterschiedliche Bedürfnisse haben, aber sie sind motiviert. Ich würde dann die 2 Geschichten verknüpfen, damit die Entwickler Bescheid wissen.