Die Kunst des Ticket-Schneidens: Best Practices und häufige Fehler - Agile Methoden

“These are really nice stories!”

Eine Entwicklung anhand von Tickets ist heute keine Seltenheit. Fast jedes Projekt aus unserer Erfahrung wurde in den letzten Jahren von Ticket-Systemen in der Entwicklung begleitet. Jedes Ticket-Tool bringt seine Vor- und Nachteile, welche wir in diesem Beitrag jedoch nicht weiter bewerten möchten.

Vielmehr möchten wir den Fokus auf das Format der Tickets (im Speziellen auf User Stories) setzen und wer diese schreibt. Dabei gilt es generell zwischen zwei Sichten der Stories zu differenzieren:

Was und Warum?
Wie?

Wir kennen einige Probleme, die immer wiederkehren, und versuchen diese meist so früh wie möglich zu mitigieren. Ein Problem, das sich bereits in vielen Projekten abgezeichnet hat, ist das Schreiben und Schneiden von User Stories in Form von Tickets in der Entwicklung. Doch warum ist es weiterhin ein Problem, dem wir uns so oft wieder entgegenstellen müssen?

Die häufigste Ursache – User Stories werden bereits vom fachlichen Aspekt viel zu technisch beschrieben. Man muss sich immer wieder vor Augen führen, dass es sich um User Stories handelt, die die Sicht der Anwender vertreten und nicht die der Technik.

Die Auswirkungen solcher „User Stories“ sind, dass wichtige fachliche Faktoren auf der Strecke bleiben. Ebenfalls nicht auszuschließen sind die daraus resultierenden Auswirkungen auf Budget und Zeitplanung sowie möglicher Frust beim Kunden und dem gesamten Entwicklerteam.

Wie schreibe ich gute Tickets (User Stories) für die Softwareentwicklung?

Gute User Stories sind essenziell für eine effiziente Softwareentwicklung. Sie helfen dabei, Klarheit zu schaffen, Prioritäten zu setzen und sicherzustellen, dass alle Teammitglieder das gleiche Verständnis des zu lösenden Problems oder der zu implementierenden Funktionen haben.

Der Fachbereich kennt das Was und Warum, das interdisziplinäre Team das Wie!

Was und Warum!

Meist kennen Anwender und Fachbereiche sich am besten mit ihren Prozessen und Anforderungen aus, und daher müssen diese frühestmöglich mit einbezogen werden. Das bedeutet nicht, dass jeder Anwender die Tickets schreibt. Dies übernimmt zumeist der Product Owner oder Business Analyst. Dieser steht im engen Austausch mit der Entwicklung und eben dem Fachbereich sowie weiteren Stakeholdern. Der Fachbereich und Stakeholder schildern ihre Prozesse, Vorgehen und Anforderungen an das Produkt. Wichtig ist immer, dass es (technisch) lösungsneutral formuliert wird. Hier helfen die Fragen „Was muss gemacht werden?“ und „Warum muss es gemacht werden?“.

Durch das „Was“ wird der Prozess oder die eigentliche Anforderung ermittelt. Mit dem Fragen nach dem „Warum“ wird eine erste Priorität und vor allem der Sinn der Umsetzung hinterfragt.

Nichts ist teurer als etwas, das nicht benötigt wird.

Wie!

Das „Wie“, also die Umsetzung, obliegt der Entwicklung. Durch ein gut spezifiziertes Ticket (User Story) können die Entwickler gemeinsam auf Basis des Was und Warum ein Wie formen und es beschreiben. Dabei hilft es, dass das Team spätestens zum Story Refinement das tatsächliche Doing in Tasks oder Sub-Tasks festhält. Eine weitere Möglichkeit ist das Beschreiben in der User Story als neues Kapitel für eine angedachte technische Lösungsbeschreibung.

Tickets richtig schreiben

Darüber hinaus ist eine klare und stringente Struktur ein ausschlaggebender Punkt für gute Tickets. Es ist wichtig, sich auf entscheidende Details zu fokussieren, die wesentlich zum Erfolg von guten Tickets beitragen.

Titel:
Jede User Story sollte bereits vom Titel her das Hauptthema beschreiben.
- Beispiel: "Anzeige des Warenkorbs im Checkout-Prozess"
Beschreibung:
Die Beschreibung oder auch der Kern der User Story gibt den relevanten Kontext des Tickets. Das Problem bzw. die Anforderung wird klar dargestellt und das erwartete Verhalten wird beschrieben.
Akzeptanzkriterien:
Sie stellen die konkreten Bedingungen dar, die erfüllt sein müssen, damit das Ticket als abgeschlossen betrachtet werden kann.
- Beispiel: "Der Warenkorb zeigt alle Artikel korrekt an, und der Gesamtpreis wird ohne Fehler berechnet."
Priorität:
Eine Angabe der Dringlichkeit, z.B. "hoch", "mittel", "niedrig", hilft bei der Einschätzung, zu wann das Ticket umgesetzt werden sollte.
Schätzung:
Aufwandsabschätzung, falls zutreffend, oft in Story Points oder Stunden.
Anhänge:
Screenshots oder andere relevante Dokumente, die zur weiteren Erklärung helfen (bisherige Excel-Makros, prozessuale Beschreibungen etc.).

Do’s beim Schreiben von Tickets

Folgende Tipps helfen zusätzlich bei der Erstellung der User Stories:

Klarheit: Tickets sollten präzise beschrieben und Mehrdeutigkeiten vermieden werden.
Detailgenauigkeit: Genügend Informationen geben, um das Problem oder die Anforderung zu verstehen und zu lösen.
Konsistenz: Verwenden einer einheitlichen Struktur und Sprache in allen Tickets.
Kollaboration: Mit dem Team zusammenarbeiten, um sicherzustellen, dass das Ticket gut verständlich ist.

Dont’s beim Schreiben von Tickets

Folgende Punkte sollten vermieden werden, da diese zumeist zu Ungenauigkeiten führen und die Stories in ihrer Qualität einschränken:

Zu wenig Details: Vermeiden von unklaren oder zu allgemeinen Beschreibungen.
Zu technisch: Technische Details vermeiden, die nicht für alle Teammitglieder verständlich sind.
Ignorieren von Feedback: Offen für Rückfragen und Korrekturen sein und diese entsprechend einarbeiten.
Überladung: Nicht zu viele Probleme oder Anforderungen in einem Ticket zusammenfassen. Wenn möglich, sollten „zu große“ Tickets / User Stories kleiner geschnitten werden.

Wie schneide ich Tickets (User Stories) für die Softwareentwicklung?

Ein wesentlicher Punkt, den wir bereits betrachtet haben, ist, dass Tickets nicht überladen und entsprechend kleiner geschnitten werden sollen.

Das Aufteilen von Tickets in kleinere, handlichere Einheiten, auch bekannt als "Schneiden", ist entscheidend, um die Arbeit effektiv zu planen und transparent zu gestalten. Dabei ist es wichtig, die Tickets so zu strukturieren, dass sie zwar klein, aber dennoch in sich wertvoll sind und innerhalb eines Zeitrahmens von ein bis maximal drei Tagen abgeschlossen werden können. Dieser Leitfaden dient als Orientierung, um die Effizienz und Produktivität bei der Umsetzung von Aufgaben zu steigern.

Dabei haben sich in der Vergangenheit drei Prinzipien des Ticket-Schneidens etabliert:

Vertikales Schneiden:
Dabei werden Tickets so unterteilt, dass jedes kleinere Ticket einen vollständigen Mehrwert bietet.
Beispiel: Statt "Checkout-Prozess implementieren" kann das Ticket "Warenkorbseite erstellen" und "Zahlungsseite erstellen" lauten.

Horizontales Schneiden:
Aufgaben werden auf die unterschiedlichen Schichten der Anwendung getrennt, wie z.B. UI, Backend oder Datenbank.
Beispiel: "UI für die Warenkorbseite" und "Backend-Logik für den Warenkorb".

Feature-basiertes Schneiden:
Das Schneiden nach Funktionalitäten, die dem Benutzer in der Anwendung zur Verfügung stehen.
Beispiel: "Artikel hinzufügen", "Artikel entfernen" oder "Gesamtpreis berechnen".

Fazit

Es gibt kein Richtig und kein Falsch. Jedes Team und Projekt muss für sich selbst herausfinden, wie es ein Produkt entwickelt, das auch den Anforderungen der Anwender entspricht und dabei möglichen Regularien, Prozessen und Vorgaben gerecht wird – dennoch sollte immer darauf geachtet werden, dass man in kleine Stücke investiert.

Das Projekt gewinnt dadurch, dass selbstorganisierte, interdisziplinäre Teams befugt sind, in enger Zusammenarbeit mit den Stakeholdern die Lösung zu entwickeln. Das Team trägt dabei die Verantwortung für die Erarbeitung und Anpassung der Lösung, basierend auf kontinuierlichem Feedback und den sich ändernden Anforderungen des Kunden.

Gute Tickets sind präzise, klar und gut strukturiert. Sie sollten genügend Details enthalten, um den Entwicklern zu ermöglichen, das Problem zu verstehen und effizient zu lösen, ohne sie mit unnötigen Informationen zu überfordern. In agilen Projekten ist das kontinuierliche Überprüfen und Schneiden von Tickets besonders wichtig, um Flexibilität und schnellen Wert für den Anwender zu gewährleisten.

Dabei kann darauf zurückgegriffen werden, dass Stories meist nur das „Was“ und „Warum“ behandeln – sprich von Fachseite/Sicht beschreiben. Das Entwicklerteam erstellt dazu seine (Sub-)Tasks bzw. erweitert die Stories jeweils um einen Abschnitt, um das „Wie“ zu beschreiben. Basierend auf der Beschreibung kann eine Einschätzung auf Basis von Story Points oder anderen Messwerkzeugen viel einfacher durchgeführt werden.

Das Feature-basierte, horizontale oder vertikale Schneiden von Tickets kann dem Team eine wertvolle Orientierung bieten und sicherstellen, dass bereits in der Dokumentation der Aufgaben eine hohe Qualität gewährleistet ist.

Feedback ist ein wichtiger Bestandteil des Prozesses und sollte kontinuierlich eingeholt werden, um sicherzustellen, dass die Tickets optimal auf das Team zugeschnitten sind. Es ist entscheidend, eine klare Trennung zwischen fachlicher und technischer Beschreibung zu wahren, damit das Team effektiv arbeiten kann. Die Fachseite sollte darauf achten, das „Wie“ nicht zu sehr zu betonen.