Neben User Stories verwenden wir auch Business Stories und Technical Stories.
Anwendergeschichten
Wenn Sie in der digitalen Produktentwicklung tätig sind, dann kennen Sie User Stories. Sie sind Erklärungen einer Funktion für eine bestimmte Benutzerrolle, um ein bestimmtes Ziel zu erreichen. Und sie werden oft so geschrieben:
Als <Benutzerrolle> möchte ich <eine Aktivität oder Aufgabe> durchführen, um <einen Nutzwert> zu erreichen.
User Stories konzentrieren sich auf tatsächliche Benutzeraufgaben und zielen darauf ab, dem Benutzer einen Mehrwert zu liefern. Diese Benutzergeschichten sollten mit tatsächlichen Benutzern erstellt und validiert werden.
Business-Geschichten
"Im Backoffice erhält {Unternehmen} nur validierte Anträge." Diese reale Geschichte (die fälschlicherweise als Benutzergeschichte dargestellt wird) ist für das Unternehmen wichtig und nicht unbedingt für den Benutzer. Solange sein Antrag bearbeitet wird, ist es dem Benutzer wahrscheinlich egal, wie das geschieht.
Business Stories richten sich an das Unternehmen mit dem Ziel, einen Geschäftswert zu liefern. Business Stories sollten mit den relevanten Stakeholdern des Unternehmens geschrieben und validiert werden, die sich mit dem Thema der Story auskennen. Auf diese Weise können alle wichtigen Details herausgefunden werden, die für die erfolgreiche Gestaltung und Entwicklung des Produkts erforderlich sind.
Als <Stakeholder> möchte ich <Anforderung>, um <Geschäftswert> zu erreichen.
Technische Geschichten
Ein Backlog besteht aus User Stories. Allerdings finden wir darin oft Punkte, die die Entwickler auf ihrem Weg zur Fertigstellung der User Stories erledigen müssen. Und wenn sie nicht im Backlog stehen, kann man nicht an ihnen arbeiten. Das führt zu "User Stories" wie:
"Als Bewohner möchte ich mit einem Berater über die Cloud kommunizieren, damit ich weiß, dass mein Austausch sicher abgewickelt wird". Offensichtlich ist der Wunsch, mit einem Berater zu kommunizieren, berechtigt. Allerdings beinhaltet diese Geschichte das Mittel (die Cloud), das den meisten Nutzern egal ist oder an das sie nicht denken. Und dasselbe gilt wohl auch für die Sicherheit einer Börse.
Sollten wir diesen Teil der Geschichte streichen? Nein, natürlich nicht. Wenn die vorgesehene Lösung darin besteht, mit einer Cloud zu arbeiten, dann sollte dies Teil des Backlogs sein. Aber seien Sie sich darüber im Klaren und verstecken Sie es nicht in einer User Story.
In vielen Texten zu diesem Thema wird diese Art von Benutzergeschichte oft als "technische Benutzergeschichte" bezeichnet. Wenn Sie darüber nachdenken, bedeutet das, dass das Wort "Benutzer" in dieser Konstruktion seine Bedeutung verloren hat. Bob Galen, der Bücher wie "Agile Reflections" und "Scrum Product Ownership" geschrieben hat, definiert eine technische (User) Story als "...fokussiert auf nicht-funktionale Unterstützung eines Systems".
Bob Galen über technische (Benutzer-)Geschichten
Bob zieht es vor, diese Geschichten aufzuschreiben, ohne zu versuchen, sie in einen Satz vom Typ "Benutzergeschichte" zu pressen, sondern vielmehr "den Bedarf (technisch) zu quantifizieren, in klarem Englisch mit vielleicht ein paar Sätzen, und dann weiterzugehen".
Das richtige Produkt schaffen
Die Maskierung von geschäftlichen und technischen Geschichten als Anwendergeschichten führt dazu, dass der Anwender aus den Augen verloren wird. Dadurch wird sichergestellt, dass alle geschäftlichen und technischen Anforderungen erfüllt werden. Denn jeder Benutzerbedarf wird in den Kontext dieses einen Produkts gestellt.
Wir sehen oft, dass dieser Prozess auch zu vielen Annahmen über die Benutzer führt, die auf dem Wissen basieren, das die Leute über ihr eigenes Produkt haben.
Das ist aber nicht die Sichtweise der Nutzer. Sie leben in einer Welt, in der das Produkt nur ein Teil ihres täglichen Lebens ist. Sie verwenden das Produkt auch als Teil eines größeren Prozesses und Ökosystems, und daraus ergeben sich weitere Anforderungen. Anforderungen, die für die richtige Gestaltung Ihres Produkts entscheidend sein können und die Sie aus den Augen verlieren könnten, wenn Sie nicht mit "reinen" User Stories arbeiten.
Kurz und bündig
Bei Geschäftsberichten sprechen Sie mit den Beteiligten. Für technische Geschichten sprechen Sie mit Architekten und Entwicklern. Bei Anwenderberichten sprechen Sie mit den Anwendern.
