Wie man eine gute User Story für sauberen Code schreibt

Was macht eine gute User Story aus?

In ihrer einfachsten Form sollen User Stories den Zweck der Story für den Endbenutzer ausdrücken. Die Beschreibung der User Story sollte drei grundlegende Fragen beantworten:

• Für wen ist sie gedacht?
• Wie lautet sie?
• Warum wird sie benötigt?

Dies sind allerdings nicht die einzigen wesentlichen Elemente, die beim Schreiben einer User Story beachtet werden müssen. Sie sollte auch Elemente zu detaillierten Akzeptanzkriterien oder Mindeststandards enthalten. Entwicklungsteams, die allgemeine Stories schreiben, vergessen oft die detaillierten Akzeptanzkriterien, was wiederum zu erheblichen Nacharbeiten und Abwanderungen im Team führt.

Für unser Beispiel zum Schreiben einer User Story verwenden wir einen Gliederungs-/Checklisten-Ansatz. Obwohl es sich um einen agilen Prozess handelt, müssen Entwicklungsteams nicht unbedingt ein strenges Format einhalten. Verwenden Sie stattdessen die Teile, die für Ihr Team funktionieren – und lassen sie weg oder ändern sie, was Ihr Team nicht braucht, um Ihre Ergebnisse zu verbessern.

Anstatt detaillierte, strenge Formulierungen in Ihrer User Story zu verwenden, sollten Sie mit dem Wortschatz entspannter umgehen. Das ist meistens genauso effektiv, um die Absicht der User Story zu kommunizieren. Eine einfache Formulierung ist oft genauso effektiv, um die allgemeine Absicht einer User Story zu kommunizieren.

Eine Methode besteht darin, die Beschreibung der User Story zu formulieren, eine Designdiskussion mit Mitgliedern des Teams zu führen und dann die Akzeptanzkriterien und andere Details auszufüllen, die für die Entwicklung und den Test der Funktion notwendig sind.

User Story als Beispiel

Formate für eine User Story sind nicht in Stein gemeißelt. Sie müssen nur für das Entwicklungsteam passen. Eine gute User Story muss die drei wichtigsten Fragen beantworten: Für wen ist sie gedacht? Wie lautet sie? Und warum wird sie benötigt? Unabhängig davon, ob Sie einen Absatz, eine Gliederung oder eine Checkliste verwenden – hier sind einige Zwischenüberschriften, die jede User Story enthalten sollte, um diesen Zweck zu erfüllen:

Beschreibung oder Zielsetzung. Dies ist eine verallgemeinerte Aussage, die das Ziel oder den Grund für das Feature oder die Änderungen definiert. Sie enthält die folgenden Teile:

• Was ist der Zweck der Funktion?
• Warum wird diese Funktion benötigt?
• Wessen Bedarf befriedigt diese Funktion?

Persona oder Benutzerbeschreibung. Bei diesem Punkt geht es darum, wer dieses Feature oder diese Änderung verwenden wird. Für ein Team, das beispielsweise medizinische Anwendungen zur Unterstützung von Patienten oder Personal entwickelt, wird die User Story vielleicht geschrieben, um eine notwendige Funktion für einen Patienten oder einen medizinischen Dienstleister bereitzustellen. Beide Benutzergruppen haben unterschiedliche Bedürfnisse, wenn sie diese Anwendung verwenden. Es ist wichtig, in diesem frühen Stadium genau zu definieren, wer der Endbenutzer sein wird.

In vielen Diskussion zeigen sich Kontroversen, wie man eine gute User Story schreibt. Viele Agile-Enthusiasten glauben beispielsweise nicht an die Notwendigkeit detaillierter Beschreibungen in der User Story. Um das beste Ergebnis zu erzielen ist es aber in ihrem Interesse, spezifische Details, wie zum Beispiel technische Belange und Akzeptanzkriterien, in ihre User Story aufzunehmen.

Technische Details. Der technische Unterabschnitt beschreibt Backend-Anliegen, die während der Codierungs- und Testphasen berücksichtigt werden müssen. Dazu können Datendefinitionen, API-Informationen oder andere Backend-Elemente gehören, die eine wesentliche Rolle bei der Arbeitsweise der gewünschten Funktion spielen. Vergessen Sie nicht, Informationen zu bekannten Integrationspunkten hinzuzufügen, die sich auf die Funktion auswirken können.

Benutzer-Workflow. Behalten Sie immer den Endbenutzer im Auge. Im Abschnitt Benutzer-Workflow sollten Entwicklungsteams Elemente der Designdiskussion einbeziehen. Auch sollten spezifische Details des erwarteten Benutzer-Workflows hinzugefügt werden, damit sie während der Designphase nicht übersehen werden.

Lassen Sie uns noch einmal auf unser Beispiel für eine medizinische Support-Anwendung zurückkommen. Wenn wir der Anwendung eine Funktion hinzufügen möchten, mit der ein Patient Medikamentendosen aufzeichnen und Nachfüllungen bestellen kann, muss die User Story den erwarteten Arbeitsablauf skizzieren.

Zum Beispiel:

• Der Patient füllt das Formular aus, um sich über seinen Arzt für das Medikamentenmanagement-Programm anzumelden.
• Der Patient erhält die Einverständniserklärung, unterschreibt sie und sendet sie elektronisch zurück.
• Das Medikamentenmanagement-Programm prüft den Patienten und akzeptiert oder verweigert seine Teilnahme.
• Wenn der Patient angenommen wird, erhält er eine Willkommens-E-Mail oder einen Brief und einen Anruf von einem Manager des Patientenprogramms.
• Der Patient erhält seine Erstausstattung an Medikamenten.
• Der Patient zeichnet die Medikamenteneinnahme für drei Monate auf.
• Der Patient überprüft seine medizinischen Unterlagen auf Richtigkeit. Er überprüft die Termine, an denen er teilgenommen hat, und alle Ergebnisse dieser Termine.
• Bei Ablehnung erhält der Patient eine E-Mail oder einen Brief, in dem er darauf hingewiesen wird, dass er für das Programm nicht in Frage kommt.
• Sobald der Patient die letzten 30 Tage des dreimonatigen Programms erreicht hat, erhält er automatisch eine Nachfüllpackung.
• Die Nachfüllpackung wird am zweiten Tag per Kurier verschickt und erfordert die Unterschrift des Patienten.
• Die Nachfüllpackung enthält einen patientenspezifischen Barcode.
• Der Patient erhält seine Nachfüllpackung und lädt den Barcode hoch.
• Der Patient verfolgt die Dosiseinnahme für die nächsten drei Monate weiter.
• Der Patient überprüft seine Krankenakte auf Richtigkeit.
• Der Zyklus wiederholt sich, solange der Patient im Medikamentenmanagement-Programm aktiv bleibt.

Wenn Sie dem Benutzer-Workflow Details hinzufügen, wird sichergestellt, dass der entworfene Code und der Testaufwand die Workflow-Elemente erfüllen. Mit anderen Worten: Wenn der Benutzer Ihre Codefreigabe erhält, kann er die Schritte des Benutzer-Workflows wie erwartet ausführen.

Akzeptanzkriterien und Mindeststandards. Jeder Endbenutzer oder Kunde definiert Mindestfunktionen, die er von einem Feature erwartet. Entwicklungsteams können Zeit sparen, indem sie diese Standards in jede Story einbauen. Technisch ist dies jederzeit möglich, aber zumindest sollten die Akzeptanzkriterien vor Beginn der eigentlichen Entwicklung eingearbeitet werden.

Warum eine gute User Story wichtig ist

Es ist besser, zu viele Details in einer User Story zu haben als zu wenige. Ein Mangel an Details kann dazu führen, dass Ihr Team härter arbeiten muss, nur um herauszufinden, was sich der Endkunde von der Funktion erhofft. Details wie die Beschreibung des Endbenutzers und technische Elemente sind in einer User Story nicht zwingend erforderlich, aber sie können im Nachhinein Zeit und Mühe sparen.

Denken Sie daran, dass User Stories agil sind. Sie können sie ändern, um Ihren Anforderungen gerecht zu werden. Wenn Ihre Anwendung keine integrierte Konnektivität hat, dann benötigt die User Story den Abschnitt mit den technischen Details nicht. Das Gleiche gilt für den Abschnitt über den Benutzer-Workflow. Wichtig ist eine klare, prägnante und spezifische Formulierung, die die grundlegendsten Fragen beantwortet.