Wenn Sie die Scrum Rolle des Product Owners innehaben, dann sind Sie unter anderem dafür verantwortlich, dass Sie die Anforderungen der Stakeholder in die Sprache der IT übersetzen. Für neue Funktionalitäten der Software (Features) eignen sich besonders gut User Stories und Epics. Wie Sie diese formulieren und auf was sie achten müssen, wenn Sie Bugs (Fehler) beschreiben, erkläre ich Ihnen in diesem Artikel.
User Stories für neue Anforderungen
User Stories eigenen sich besonders, um neue Anforderungen an Funktionalitäten zu formulieren. Wahrscheinlich fragen Sie sich: „Wie schreibe ich gute User Stories?“ oder „Was ist User Story Mapping“? Diese Fragen werde ich Ihnen gern beantworten.
Was ist eine Scrum User Story?
Bei einer User Story wird eine Anforderung in Alltagssprache formuliert. Dabei kann folgendes Template oder Muster verwendet werden:
Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>
Ein Beispiel wäre: Als lokaler Admin möchte ich einen Zugriffsreport der Nutzer generieren können, um die Nutzung der Applikation analysieren zu können.
User Stories sind meiner Meinung nach die beste Möglichkeit, um Aufgaben zu definieren. Sie lassen dem Entwickler genügend Freiraum, um eine Lösung umzusetzen, ohne die technischen Grenzen zu eng zu setzen. Die Rolle definiert die Sicht auf die Anforderung. Die Aufgabe würde komplett anders umgesetzt werden, wenn der Nutzer der Applikation anstelle des Admins die Anforderung formuliert hätte. Besonders wichtig ist es für den Entwickler, den Grund oder Nutzen für die Anforderung zu kennen.
Wenn Sie Ihre User Stories in Jira verwalten, dann haben Sie auch die Möglichkeit, Dateien anzuhängen. Hier hat es sich bewährt, die Idee als Skizze in einem Screenshot anzuhängen oder wenn Ihnen ein Whiteboard zur Verfügung steht, dann fotografieren Sie die darauf erstellte Skizze einfach und hängen Sie das Foto an das Ticket.
Zu einer vollständigen User Story zählen auch die Akzeptanzkriterien. Dazu müssen Sie diese Frage beantworten: Welche Kriterien müssen erfüllt sein, damit die User Story als erledigt gilt und getestet werden kann?
Was ist User Story Mapping?
Die einzelnen User Stories können Epics zugeordnet werden. Dabei handelt es sich um eine übergeordnete Abstraktionsebene mit geringerem Detailgrad, also sozusagen die Überkategorie. Das sorgt für mehr Übersichtlichkeit und bessere Einordenbarkeit der User Stories. Das Zuordnen von User Stories zu Epics nennt man auch „User Story Mapping“. Häufig ist es sinnvoll, ein Epic einem Sprint zuzuordnen, damit das Überthema in einem Stück entwickelt und ggf. releast wird.
Eine weitere Vorgehensweise ist das Runterbrechen von Epics in User Stories. Zuerst werden die groben Anforderungen an die Software in Form von Epics formuliert und im Anschluss in detailliertere User Stories zerlegt.
Fehlerbeschreibungen für Bugs
Wenn Bugs auftreten, ist es besonders wichtig, diese ausreichend zu dokumentieren, damit ohne unnötige Rückfragen mit der Lösungsfindung begonnen werden kann.
Was ist ein Bug?
Bei einem Bug handelt es sich um einen Softwarefehler, d.h. die Software arbeitet nicht wie erwartet. Wenn Bugs auftreten, dann sollte der Product Owner diese bestmöglich beschreiben und dokumentieren.
Bei mir hat sich dazu folgende Vorgehensweise bewährt:
Steps to Reproduce, um den Bug nachvollziehbar zu machen
Der Bug muss reproduzierbar sein. Das heißt, dass der Fehler immer auftritt, wenn ich eine bestimmte Abfolge von Schritten durchführe. Wenn der Bug mal auftritt und mal nicht, dann ist er im Moment nicht reproduzierbar. In diesem Fall führt ggf. eine abweichende Abfolge von Schritten zum Fehlverhalten.
Wenn Sie die richtigen Schritte identifiziert haben, dann Schreiben Sie diese akribisch, vollständig und stichpunktartig nieder. Es ist sehr hilfreich, wenn Sie Screenshots anfügen, wo es sich anbietet. Ein gutes, kostenloses Tool, um schnell Screenshots zu erstellen und zu bearbeiten ist Greenshot. An diesem Tool gefällt mir besonders, dass sich Screenshots anonymisieren, schnell editieren und abspeichern lassen. Die Screenshots fügen Sie dann an der jeweiligen Stelle in der Schrittfolge des Bugs ein.
Wenn Sie diese Tipps befolgen, sind Sie auf einem guten Weg bessere User Stories und Fehlerbeschreibungen zu erstellen.