Agile tickets schreiben
Author: Simone Kohl
· 2 mins readWenn 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”
Brauchen Sie professionelle IT-Lösungen?
Holen Sie sich noch heute eine kostenlose Beratung!
Ob Sie Netzwerkprobleme, Sicherheitsbedenken haben oder Softwareintegrationen benötigen, unser Team von IT-Experten steht Ihnen zur Verfügung. Lassen Sie sich nicht von technischen Problemen aufhalten. Rufen Sie uns jetzt für eine kostenlose Ersteinschätzung an oder klicken Sie unten, um unser schnelles Kontaktformular auszufüllen. Lassen Sie Technologie für Sie arbeiten.
Share