Agile tickets schreiben

Wenn man anfängt agil zu arbeiten, merkt man schnell, dass es wichtig ist, einen Wert für Endanwender und Stakeholder zu schaffen. Die Tickets sind ein wichtiger Teil davon, denn sie beschreiben, welchen Wert das Produkt für die Benutzer bringt. Was es mit agil auf sich hat, erfahren Sie in unserem Blogbeitrag Agile Softwareentwicklung. Hier zeigen wir Ihnen, wie Sie ein agiles Ticket schreiben:

User story

Eine User Story ist das kleinste Element eines Use Cases und beschreibt konkret die kleinstmögliche Aufgabe, was der Benutzer mit dem erstellenden System tun soll und wie es reagieren soll.

Sie sollten die User Story in Alltagssprache formulieren und so kurz wie möglich halten:

• Sei genau
• Klar sein – erkläre so, dass andere die Aufgabe verstehen können
• Nur eine Aufgabe pro User story
• Eine User Story muss unabhängig sein
• User Stories sollten mit Kunden und Entwicklern besprochen werden, damit Fragen und Entscheidungen einbezogen werden können
• Eine User Story muss überschaubar sein, damit die Entwickler die Einschätzungen vornehmen können
• Eine komplette Implementierung sollte mindestens 4 Stunden und maximal 80 Stunden dauern
• Sie müssen getestet werden können
• Abhängige Stories müssen sich in Epics und unabhängige User Stories unterteilen können

Eine User Story sollte die folgenden Punkte enthalten:

• Eine ID-Nummer, die dieselbe ist wie im Product Backlog und die vom Product Owner vergeben wird, wenn ein Eintrag zum Product Backlog hinzufügt wird
• Kurzer Titel
• Eine User Beschreibung
• Was der User erreichen möchte
• Der Grund, wieso der User diesen Task ausführen möchte

Beispiel: Als Website-Betreiber möchte ich, dass die Nutzer meine Produkte online kaufen können, damit ich mehr Umsatz generieren kann.

Wie Sie sehen, müssen Sie jede User Story aus der Ich-Perspektive formulieren: Wenn ich dies tue, erhalte ich dies. Die Verwendung der ersten Person versetzt den Autor in die position des Benutzers oder Kunden.

Epics

Epics sind Aufgaben auf Feature-Ebene, die viele User Stories umfassen. Es gilt folgendes:

• Ein Epic kann mehrere Komponenten enthalten
• Epics laufen normalerweise über mehrere Sprints
• Epics können jederzeit um User Stories erweitert werden

Ein Epic besteht aus mehreren User Stories über verschiedene Benutzerrollen und Szenarien.

Beispiel: 

Name des Epics: Landingpage X

Zusammenfassung: Implementierung einer Möglichkeit zur Verwaltung von Artikellayouts im Backend. Beschreibung: Benutzer sollten die Möglichkeit haben, Artikellayouts im Backend zu verwalten.

Bugs beschreiben

Wenn Sie die Meldungen genau beschreiben, können sie schneller korrigiert werden.

Das müssen die Bugs auch:

• Sei genau
• Sei klar – beschreibe so, damit andere dein bug verstehen können
• Beschreibe immer nur ein bug
• Kein Bug ist zu trivial, um gemeldet zu werden – hinter kleinen Fehlern können sich größere Fehler verbergen
• Fakten von Annahmen klar trennen
• Schreibe den Fehlerbericht – wenn möglich – auf Englisch

Eine gute Zusammenfassung sollte einen Fehlerbericht schnell und unmissverständlich beschreiben. Sie sollten das Problem erklären, nicht Ihren Lösungsvorschlag.

Beispiel: “Wenn der Kopiervorgang einer Datei abgebrochen wird stürzt das Dateisystem ab” oder “Pfeil-nach-unten-Scrollen funktioniert nicht in <textarea>, das mit overflow:hidden gestylt ist”