Januar 23, 2018
von Ron Yang

Geschichten. Sie haben Hunderte von ihnen, wenn Sie ein Produktmanager sind. Jeder beschreibt die großartigen Erfahrungen, die Ihre Kunden mit Ihrem Produkt machen sollen. Und wie jeder gute Geschichtenerzähler müssen Ihre Geschichten klar und wirkungsvoll sein.

Alle der besten Produktmanager, die ich kenne, sind dafür verantwortlich, durch User Stories zu teilen, was Kunden wirklich wollen.

Aber hier ist es harte Arbeit, Produktmanager zu sein. Es gibt auch Zeiten, in denen von Ihnen erwartet wird, dass Sie die Anforderungen für das definieren, was Ihre Entwicklungsteams erstellen müssen — ohne das „Warum“ aus der Sicht des Benutzers anzugeben.

Während die meisten neuen Funktionen aus der Sicht des Benutzers definiert werden sollten, ist dies nicht immer machbar oder sogar hilfreich. Berücksichtigen Sie beispielsweise Sicherheitsfunktionen oder Infrastrukturanforderungen, die nicht immer kundenorientiert sind.

Die Frage wird also: Wann benutzt du diese verschiedenen Gefäße? Bevor Sie das beantworten können, müssen Sie verstehen, was sie unterscheidet.

Es gibt einen großen Unterschied zwischen User Stories und Anforderungen: das Ziel.

Die User Story konzentriert sich auf die Erfahrung — was die Person, die das Produkt verwendet, tun möchte. Eine traditionelle Anforderung konzentriert sich auf die Funktionalität — was das Produkt tun soll. Die verbleibenden Unterschiede sind subtil, noch wichtig, Liste von „wie,“Wer,“Und „wann.“

So unterscheiden sich User Stories und Anforderungen:

Wie ist es geschrieben?

User Stories sollten in ein oder zwei Sätzen geschrieben werden und erfassen, wer der Benutzer ist, was er will und warum. Eine einfache Struktur zum Definieren von Features oder User Stories kann ungefähr so aussehen: Als ____ möchte ich ____ erreichen, damit ich den folgenden Vorteil von ____ erkenne.

Beispiel: Als Benutzer möchte ich mein Passwort zurücksetzen können, damit ich wieder in das System gelangen kann, wenn ich es vergesse.

Anforderungen sind in der Regel sehr detailliert und dauern länger. Diese gehen oft ins Detail (manchmal sehr technisch), wie die Software funktionieren sollte. Diese Details leiten das Entwicklungsteam dann beim Erstellen einer neuen Funktion oder Funktionalität an.

Beispiel: Der Benutzer darf sein Passwort zurücksetzen, sobald er eine E-Mail zum Zurücksetzen des Passworts erhalten hat. Die E-Mail sollte einen eindeutigen Link zum Zurücksetzen des Kennworts enthalten und dieser Link sollte nach zwei Stunden ablaufen.

Wer schreibt es?

User Stories können von fast jedem geschrieben werden, der der Software nahe steht — Entwickler, die Probleme aufwerfen, ein QA—Tester, der einen Fehler in der UX entdeckt – solange er die Perspektive des Endbenutzers darstellt. Aber es ist der Produktmanager oder Eigentümer, der das Backlog der User Stories verwaltet.

Anforderungen werden vom Produktmanager, Product Owner oder Business Analyst geschrieben. Technische Leiter sind häufig ebenso beteiligt wie die Ingenieure, die für die Arbeit an den Funktionen oder Verbesserungen verantwortlich sind.

Wann werden sie geschrieben?

User Stories werden während des gesamten Aufbaus eines Produkts geschrieben. Und die Aktualisierung der Geschichten (oder das Hinzufügen neuer) kann jederzeit erfolgen. Für agile Teams dient das Product Backlog als priorisierte Liste der Funktionen, die entwickelt werden müssen. Hier werden die User Stories aufbewahrt, bis sie bearbeitet werden – typischerweise während der Entwicklungssprints.

Anforderungen können auch jederzeit hergestellt werden. Es ist jedoch am besten, zuerst zu definieren, was aus Benutzersicht gewünscht wird, wenn sowohl Storys als auch eine Anforderungsdefinition erforderlich sind. Je weiter ein Team mit seiner Planung vorankommt, desto besser versteht es die Nutzer- und Geschäftsanforderungen. Wenn Sie also zu früh harte Anforderungen definieren, müssen Sie diese später ändern — oder etwas erstellen, das das gewünschte Ergebnis des Kunden nicht vollständig liefert.

Obwohl sich das Ziel einer User Story oder Anforderung unterscheidet, ist das Ziel immer dasselbe – ein Produkt zu entwickeln, das Kunden lieben.

Egal, ob Sie eine User Story oder eine Anforderung schreiben, Sie müssen sich auf das konzentrieren, was am wichtigsten ist: das gewünschte Ergebnis für den Kunden beschreiben und der Entwicklung das geben, was sie brauchen, um es erfolgreich aufzubauen.

Ich weiß, dass es verwirrend sein kann, zu entscheiden, was ich schreiben soll. Also hier ist eine einfache Anleitung, um diese Wahl zu treffen.

Wenn das, was Sie erstellen möchten, einen direkten Nutzen für Ihre Endbenutzer hat, schreiben Sie eine User Story. Wenn es für den Kern eines Produkts oder einer Infrastruktur zentraler ist, gehen Sie zur Definition von Anforderungen über.

Welche Unterschiede würden Sie der Liste hinzufügen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.