Warum Ticket-Intake und Backlog-Hygiene wichtig sind
Als eingebetteter IT-Freelancer arbeite ich oft mit gewachsenen Backlogs: unklare Tickets, veraltete Einträge, fehlende Priorisierung. Das kostet Zeit und Fokus. Ein klarer Intake-Prozess und regelmäßige Hygiene verhindern, dass das Backlog zur Müllhalde wird.
Für wen der Workflow passt
Für IT-Freelancer in agilen Teams, die mit Ticket-Systemen arbeiten (Jira, Linear, GitHub Issues, etc.) und einen strukturierten Umgang mit eingehenden Anfragen und dem Backlog etablieren wollen.
Teil 1: Ticket-Intake – Neue Tickets sauber aufnehmen
Jedes neue Ticket durchläuft bei mir drei Prüfschritte, bevor es ins Backlog kommt. Wichtig ist ein klarer Intake-Kanal: Neue Tickets landen entweder über ein Formular, eine feste Inbox oder ein definiertes Label im System. So geht nichts unter und der Prozess wird nicht umgangen.
1) Vollständigkeit prüfen
Ein Ticket braucht mindestens:
- Titel: Klar und spezifisch, nicht "Bug" oder "Feature".
- Beschreibung: Was genau ist das Problem oder die Anforderung?
- Akzeptanzkriterien: Woran erkenne ich, dass das Ticket fertig ist?
- Kontext: Wer hat es erstellt, warum ist es wichtig?
Ich nutze dafür eine einfache Definition of Ready (DoR). Wenn einer der Punkte fehlt, bleibt das Ticket im Intake:
- Klarer Problem- oder Ziel-Satz
- Grober Scope (was gehört dazu, was nicht)
- Erwarteter Impact (z.B. Umsatz, Risiko, UX)
- Verantwortlicher Owner
- Mindestens ein Akzeptanzkriterium
Wenn etwas fehlt, frage ich nach, bevor ich das Ticket annehme. Das spart später Rückfragen.
2) Duplikate und Überschneidungen checken
Bevor ich ein neues Ticket ins Backlog aufnehme, suche ich kurz nach ähnlichen Einträgen. Duplikate verlinke ich oder schließe das neue Ticket mit Verweis auf das bestehende.
3) Einordnung und Label
Ich vergebe sofort:
- Typ: Bug, Feature, Task, Spike
- Priorität: Kritisch, Hoch, Normal, Niedrig
- Komponente/Bereich: Wo im System ist das relevant?
- Größe: S/M/L als grobe Schätzung, damit das Backlog planbar bleibt.
Prioritäten bewerte ich pragmatisch: Impact x Dringlichkeit. Kritisch sind nur Tickets, die echte Risiken, Ausfälle oder Blocker erzeugen.
Damit ist das Ticket sortierbar und ich kann es später schnell finden.
Teil 2: Backlog-Hygiene – Regelmäßig aufräumen
Ein Backlog ohne Pflege wächst und wird unbrauchbar. Ich plane feste Hygiene-Slots ein.
Wöchentlich: Kurzer Scan (10 Minuten)
Einmal pro Woche schaue ich auf:
- Tickets ohne Zuweisung: Braucht das jemand oder kann es weg?
- Alte Tickets ohne Aktivität: Seit 4+ Wochen nichts passiert? Nachfragen oder schließen.
- Blocker: Gibt es Tickets, die auf etwas warten? Status aktualisieren.
Monatlich: Tiefenreinigung (30 Minuten)
Einmal im Monat gehe ich das Backlog systematisch durch:
- Veraltete Tickets schließen: "Won't fix" oder "Obsolete" mit kurzer Begründung.
- Priorisierung prüfen: Stimmen die Prioritäten noch?
- Große Tickets aufbrechen: Epics ohne klare Subtasks in kleinere Einheiten teilen. Wenn nötig, vergebe ich eine grobe Größe, damit die Reihenfolge nachvollziehbar bleibt.
Mein Intake-Template
Für neue Tickets nutze ich dieses Kurzformat:
## [Ticket-Titel]
**Typ**: [Bug / Feature / Task / Spike]
**Priorität**: [Kritisch / Hoch / Normal / Niedrig]
**Erstellt von**: [Name]
**Datum**: [YYYY-MM-DD]
### Beschreibung
[Was genau ist das Problem oder die Anforderung?]
### Reproduktion (für Bugs)
- Schritte zur Reproduktion
- Erwartet vs. Ist-Zustand
- Umgebung (Browser/Version, Gerät, System)
### Akzeptanzkriterien
- [ ] [Kriterium 1]
- [ ] [Kriterium 2]
### Kontext
[Warum ist das wichtig? Gibt es Abhängigkeiten?]
Automatisierung: Stale-Tickets und Reminder
Ich automatisiere zwei Dinge:
- Stale-Ticket-Warnung: Tickets ohne Aktivität nach 4 Wochen bekommen automatisch ein Label oder einen Kommentar.
- Hygiene-Reminder: Wöchentlicher Task erinnert mich an den Backlog-Scan.
In GitHub funktioniert das über Actions oder Bots. In Jira gibt es Automation Rules. In Linear kann ich Filter mit Benachrichtigungen kombinieren. Wichtig: Stale-Regeln gelten nicht für Tickets mit Status "Blocked" oder "In progress".
Den allgemeinen Automatisierungs-Rahmen habe ich hier beschrieben: Workflow-Automatisierung für Solo-Freelancer
Typische Fehler und wie ich sie vermeide
| Fehler | Lösung |
|---|---|
| Tickets ohne Akzeptanzkriterien | Nicht annehmen, nachfragen |
| Backlog als Wunschliste | Regelmäßig schließen, was nicht priorisiert wird |
| Zu viele Labels | Auf 5-7 Kernlabels beschränken |
| Keine Verantwortlichkeit | Jedes Ticket braucht einen Owner |
Verbindung zu anderen Workflows
Ticket-Intake ist eng verbunden mit dem Onboarding, wenn ich neu ins Team komme, kläre ich zuerst, wie der Intake-Prozess aussieht: Team-Onboarding-Workflow
Und die wöchentliche Hygiene passt gut zum Status-Update, beides mache ich freitags: Team-Status-Updates
Kurzfazit
Ein klarer Ticket-Intake und regelmäßige Backlog-Hygiene verhindern Chaos und sparen Zeit. Der Aufwand ist gering: 10 Minuten pro Woche, 30 Minuten pro Monat. Das Ergebnis ist ein Backlog, mit dem ich wirklich arbeiten kann.
FAQ
Wer ist für Backlog-Hygiene verantwortlich? Im Idealfall das ganze Team, aber oft bleibt es am PO oder Tech Lead hängen. Als Freelancer übernehme ich gerne einen Teil, weil ein sauberes Backlog mir selbst hilft.
Wie gehe ich mit Tickets um, die niemand will? Wenn ein Ticket seit Monaten unbearbeitet liegt und keine Priorität hat, schließe ich es mit Begründung. Bei Bedarf kann es jederzeit neu geöffnet werden.
Was mache ich bei unklaren Anforderungen? Ich erstelle einen Spike (Recherche-Ticket) mit dem Ziel, die Anforderungen zu klären. Erst danach kommt das eigentliche Feature-Ticket.
Wie viele Tickets sollten im Backlog sein? Keine feste Zahl, aber als Faustregel: Wenn ich das Backlog nicht in 5 Minuten überblicken kann, ist es zu voll.