Viele Teams diskutieren Ticketgrößen mit Bauchgefühl: „zu groß“, „zu klein“, „das gehört doch zusammen“. Hilfreicher ist eine andere Frage: Kann dieses Ticket als eigenständige, nachvollziehbare Änderung umgesetzt, reviewed und abgenommen werden? Genau daran lässt sich ein guter Schnitt erkennen.
Am fachlichen Ergebnis beginnen
Ein Ticket sollte ein sichtbares Ziel haben. Das kann eine neue Nutzerfunktion, eine klar abgegrenzte Fehlerbehebung oder ein technisches Ergebnis mit nachvollziehbarer Wirkung sein. Wenn der Titel nur eine Tätigkeit beschreibt – etwa „Backend umbauen“ – fehlt meist noch die eigentliche Abgrenzung.
Beispiel: „Kunde kann eine abgelaufene Einladung erkennen und eine neue anfordern“ ist leichter zu schneiden als „Einladungsprozess überarbeiten“.
Nicht nach Dateien oder Komponenten schneiden
Frontend, Backend und Datenbank sind technische Schichten, aber selten sinnvolle fachliche Tickets. Werden sie getrennt geplant, entsteht schnell eine Kette halbfertiger Aufgaben, bei denen keine einzelne abnahmefähig ist. Besser ist ein vertikaler Schnitt: nur so viel durch alle benötigten Schichten ändern, wie für einen konkreten Anwendungsfall nötig ist.
Ein Ticket sollte reviewbar bleiben
Ein guter Schnitt berücksichtigt nicht nur Entwicklungszeit, sondern auch Reviewaufwand. Wenn ein Pull Request mehrere unabhängige Konzepte gleichzeitig verändert, wird es schwerer, Fehler von reinen Nebeneffekten zu unterscheiden. Ein brauchbarer Test ist: Kann ein Reviewer das Ziel, die wichtigsten Änderungen und das Risiko in einem zusammenhängenden Durchgang verstehen?
Abhängigkeiten sichtbar machen
Manche Änderungen lassen sich nicht vollständig unabhängig umsetzen. Dann sollte klar dokumentiert sein, welches Ticket Voraussetzung ist und was danach folgt. Versteckte Reihenfolgen führen dazu, dass Aufgaben formal „offen“ sind, praktisch aber nicht bearbeitet werden können.
Abhängigkeiten sind kein Grund, alles in ein Riesenticket zu packen. Sie sind ein Grund, die Reihenfolge sauber zu beschreiben.
Warnzeichen für ein zu großes Ticket
Mehrere unabhängige Nutzerziele, unterschiedliche Berechtigungsmodelle, mehrere Datenmigrationen, zahlreiche „wenn wir schon dabei sind“-Änderungen oder ein Pull Request, dessen Beschreibung selbst schon mehrere Teilprojekte aufzählt, sind typische Warnzeichen.
Warnzeichen für zu kleine Tickets
Das Gegenstück sind Aufgaben, die nur technische Handgriffe abbilden: „DTO anlegen“, „Button hinzufügen“, „Repository-Methode schreiben“. Solche Tickets erzeugen Statusbewegung, aber keinen eigenständigen Wert. Sie können als Subtasks nützlich sein, sollten aber nicht automatisch zu separaten fachlichen Arbeitspaketen werden.
Ein praktisches Schneideschema
1. Welches konkrete Ergebnis entsteht?
2. Kann dieses Ergebnis eigenständig getestet oder abgenommen werden?
3. Enthält das Ticket mehrere voneinander unabhängige Ziele?
4. Ist die Änderung in einem Review noch gut erfassbar?
5. Welche Abhängigkeiten müssen ausdrücklich genannt werden?
Die Größe ist kein Selbstzweck
Teams brauchen keine starre Stunden- oder Story-Point-Grenze. Ein Ticket ist gut geschnitten, wenn Ziel, Risiko und Abnahme klar bleiben. Kleine Änderungen dürfen klein sein; komplexe fachliche Fälle dürfen größer sein. Entscheidend ist, ob die Aufgabe noch als eine zusammenhängende Entscheidung verstanden werden kann.