Wenn Sie in der Softwareentwicklung tätig sind, haben Sie sicher schon von User Stories gehört. Vielleicht schreiben Sie sie sogar als Manager. Oder vielleicht sind Sie ein Kunde und Ihr Softwareentwickler möchte, dass Sie Feature-Anforderungen als User Stories formulieren.

In diesem Beitrag finden Sie alles, was Sie schon immer über User Stories wissen wollten.

Was ist eine User Story in der Softwareentwicklung?

Eine User Story ist ein Format zur Formulierung von Software-Features und/oder Anforderungen. Wie der „Benutzer“-Teil vermuten lässt, werden User Stories in der ersten Person Singular geschrieben und beschreiben ein Feature so, wie es vom Benutzer der Anwendung wahrgenommen wird.

Eine typische User Story folgt dieser Struktur (wenn wir über den agilen Entwicklungsprozess sprechen):

Als ,
Ich möchte ,
So dass .

Der erste Teil (als…) gibt die Rolle des Benutzers in der Anwendung an, die normalerweise damit verbunden ist, was man dort tun darf.

Der zweite Teil (das Feature) verweist auf das Stück Funktionalität, das in diesem Fall verwendet wird.

Der dritte Teil (das gewünschte Ergebnis) ist der Wert, den der Benutzer aus dem Feature ziehen möchte. Hier sind einige Beispiele.

Beispiel 1

Als registrierter Benutzer
möchte ich benachrichtigt werden, wenn ein Freund zu einer Veranstaltung in der Nähe geht
damit ich auf die Nachricht reagieren oder mit ihm zusammen an der Veranstaltung teilnehmen kann.

Beispiel 2

Als Fahrer
möchte ich bei jeder 10. Fahrt einen Rabatt von 10% erhalten
So werde ich dafür belohnt, dass ich regelmäßig Geld für den Dienst ausgebe.

Es gibt gute Gründe für diese Art von Struktur. Wenn Produkt-/Projektmanager mit Softwareanforderungen umgehen, die aus unterschiedlichen Quellen stammen, ist es für sie manchmal schwierig, Einheitlichkeit zu erreichen. Es kann auch unklar sein, welche Kategorie von Benutzern die Funktion abdeckt oder wo der Geschäftswert liegt. Das User-Story-Format hilft dabei, diese kritischen Details zu erfassen.

Ansätze zum Verfassen von User-Stories

User-Stories können auf unterschiedliche Weise geschrieben werden, je nachdem, wer mit ihnen arbeiten soll.

The Gherkin Way

Gherkin ist eine Klartextsprache, die das Verhalten beschreibt, ohne seine Implementierung zu spezifizieren. Hier ist ein einfaches Beispiel für die Gherkin-Syntax:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Wie Sie vielleicht bemerkt haben, definiert der Einzug die Struktur in Gherkin. Die grundlegenden Parameter sind Given/When/Then, und diese können bei Bedarf durch mehrere And’s ergänzt werden. Die Syntax geht jedoch über diese grundlegenden Parameter hinaus. Wenn Sie Gherkin wirklich beherrschen wollen, finden Sie hier ein schönes Tutorial.

Während Gherkin vielleicht nicht die beste Wahl ist, wenn Sie die ersten Anforderungen für das Projekt sammeln, kann es bei der weiteren Entwicklung von User Stories von Vorteil sein (insbesondere für das QA-Team). In Gherkin geschriebene User Stories lassen sich leicht in Testfälle umwandeln.

The Agile Way

Viele agile Projektmanagement-Anwendungen bieten eine Funktion zur Eingabe von User Stories. Wir haben zum Beispiel die Taiga-App bei einigen unserer internen Projekte eingesetzt. Sie hilft Ihnen, die Arbeit rund um User Stories zu organisieren, die im Backlog in einzelne Aufgaben unterteilt werden können.

Quelle: Taiga.io interface

Wenn Sie darüber nachdenken, macht es durchaus Sinn, User Stories als Backlog-Elemente zu haben und dann mehrere Aufgaben zu einer User Story hinzuzufügen. Und warum? Weil Sie, sagen wir mal, eine Funktion (=Benutzergeschichte) haben und drei Leute daran arbeiten; Sie brauchen separate Aufgaben für diese Leute. Sie brauchen einen Designer, der die Schnittstelle entwirft, einen HTML/JavaScript-Programmierer, der die Schnittstelle programmiert, und einen DevOps, der die Schnittstelle für die Produktion freigibt.

Mit anderen Tools wie Pivotal Tracker (das das Konzept der „Epics“ einführt, um zusammenhängende Stories zu gruppieren) können Sie ebenfalls Stories erstellen, die von verschiedenen Typen sein können: Features, Chores, Bugs oder Releases.

Quelle: PivotalTracker.com

Abgesehen von den verschiedenen Ansätzen, die von verschiedenen Unternehmen verwendet werden, sollten Sie nicht vergessen, dass es eine einfache und geradlinige Art und Weise gibt, User Stories zu formulieren – Beispiele dafür haben Sie am Anfang dieses Beitrags gesehen.

Wer sollte User Stories schreiben?

Wer ist also dafür verantwortlich, User Stories zu schreiben? Nun, das kommt darauf an. Wenn Ihr Team zugestimmt hat, Features in Form von User Stories zu erfassen, werden diese höchstwahrscheinlich von den Gesellschaftern über den Product Owner kommen. Es könnte also der PO sein, der sie aufschreibt.

Es könnte auch ein Projektmanager oder ein QA sein, der mit dem Kunden zusammenarbeitet, um Funktionen und Anforderungen zu besprechen. Oder vielleicht sind Sie ein Startup mit 15 Mitarbeitern und Sie sind der CEO, CTO und CMO? In diesem Fall könnten Sie mit gutem Beispiel vorangehen und anfangen, User Stories zu verwenden, um Features zu dokumentieren.

Viele IT-Experten sprechen auch von „User Story Development“, d.h. dem Prozess, bei dem zunächst High-Level-Details erfasst werden (z.B. beginnend mit einer einfachen Liste von Features) und diese dann durch Hinzufügen von Aufgaben, Szenarien usw. zu detaillierteren Stories weiterentwickelt werden.

Zusammenfassend

Am Ende hilft Ihnen die Formulierung von Features in Form von User Stories, sich auf die Geschäftsziele zu konzentrieren. Außerdem hilft es Ihnen, die Anforderungen zu vervollständigen. Und, wie gesagt, die genauen Vorlagen/Felder, die Sie verwenden, können je nach Situation unterschiedlich sein.