TICKET VORBEREITEN

Gute Entwicklungstickets anhand von Beispielen

Ein gutes Ticket macht Ziel, Umfang und offene Entscheidungen sichtbar. Es behauptet nicht, dass jede Antwort bereits feststeht.

3 Min. Lesezeit

Was ein Ticket mindestens leisten sollte

Beschreibe das Problem, die betroffene Person oder den betroffenen Prozess, das erwartete Verhalten und den Umfang. Ergänze relevante Quellen, Abhängigkeiten und überprüfbare Akzeptanzkriterien. Markiere offene Entscheidungen ausdrücklich und benenne, wer sie klärt. Die Länge ist kein Qualitätsmerkmal: Ein kleiner Fehler braucht keine umfangreiche Vorlage, eine riskante Integration dagegen mehr Kontext.

Funktion: Kundenexport

Vorher: „Export-Button für Kunden einbauen.“ Unklar bleiben Berechtigungen, Filter, Format und Datenumfang.

Nachher: „Im Bereich Kunden soll eine berechtigte Person die aktuell gefilterte Liste exportieren können. Der Export umfasst auch Treffer außerhalb der sichtbaren Seite. Nicht enthalten sind automatische E-Mails und wiederkehrende Exporte. Vor Beginn bestätigt Product Ownership, welche vorhandene Berechtigung gilt, welche personenbezogenen Spalten erlaubt sind und wie ein leerer Export aussieht. Die API-Dokumentation und der Entwurf für Lade- und Fehlerzustand sind verlinkt.“ Erst nach diesen Entscheidungen werden die konkreten Akzeptanzkriterien festgelegt.

Fehler: Formular speichert nicht zuverlässig

Vorher: „Speichern funktioniert manchmal nicht.“

Nachher: „Im Testsystem liefert die Bearbeitung einer Kundenadresse gelegentlich HTTP 409. Erwartet: neue Adresse und Bestätigung. Tatsächlich: alte Adresse ohne Fehlermeldung. Reproduktion: Kundendatensatz öffnen, Adresse ändern und innerhalb von fünf Sekunden zweimal Speichern wählen; drei von fünf Versuchen betroffen. Anfrage-ID und Browserversion sind beigefügt.“ Das ermöglicht Diagnose, ohne eine Ursache zu behaupten.

Technische Aufgabe: Framework-Upgrade

Vorher: „Laravel aktualisieren.“

Nachher: „Die Anwendung von Laravel 10 auf eine vereinbarte Version von Laravel 11 aktualisieren. Vor der Änderung PHP- und Paketkompatibilität prüfen. Öffentliche API-Verträge erhalten, Lockfile aktualisieren und Unit- sowie Integrationstests ausführen. Auf Staging Anmeldung und Rechnungserstellung prüfen. Nicht kompatible Pakete als separate Entscheidung festhalten.“ Eine künstliche User Story verbessert diese Aufgabe nicht.

UI-Änderung: Formularfehler sichtbar machen

Vorher: „Formular intuitiver machen.“

Nachher: „Auf Mobilgeräten wird der Fehler für die erforderliche Postleitzahl unterhalb des Kaufbuttons übersehen. Zeige die Meldung direkt am Feld nach bestehendem Designmuster und setze den Fokus darauf. Bei gültiger Eingabe läuft der Kauf weiter. Text und Entwurf müssen vor der Umsetzung bestätigt werden.“

Prüfe danach mit der Checkliste zur Aufgabenbereitschaft, ob wesentliche Lücken bleiben. Formuliere bestätigte Ergebnisse mit dem Leitfaden zu Akzeptanzkriterien und nutze das Tool zur Ticket-Bereitschaft als Vorbereitung für das Refinement.

← Zurück zu den Ressourcen