Wenn ein Ticket drei Sprints offen bleibt, fehlt meist kein Fleiß.
Es fehlt eine Entscheidung.
Drei Sprints.
Das Ticket ist noch „In Progress“.
Der Code ist halb fertig.
Das Pull Request wartet.
Im Review sagt jemand: „Ist ja fast durch.“
Solche Situationen sind kein Ausnahmefall.
Sie sind ein Symptom.
Und sie haben selten mit individueller Produktivität zu tun.
Definition of Done ist kein Ritual
Viele Teams haben eine Definition of Done.
Weniger Teams haben eine belastbare Definition of Ready.
Und noch weniger nutzen sie als Steuerungsinstrument.
Ein Ticket wird gestartet, obwohl:
- Akzeptanzkriterien vage sind
- API-Verträge nicht finalisiert wurden
- Security noch prüfen muss
- ein anderes Team den betroffenen Service besitzt
Das Ticket ist technisch begonnen, aber organisatorisch nicht startfähig.
Definition of Ready ist kein Prozessdetail.
Sie ist eine Entscheidung darüber, was startklar bedeutet.
Wenn diese Entscheidung fehlt, beginnt Arbeit im Nebel.
Unklare nächste Schritte sind ein Strukturproblem
„Authentifizierung verbessern“ ist keine Aufgabe.
„Auth-Fehler der letzten 24 Stunden analysieren“ schon.
Vage Formulierungen sind oft kein Denkfehler einzelner Entwickler.
Sie sind Ausdruck fehlender Entscheidungstiefe.
Wenn nicht klar ist, welches Ergebnis erwartet wird,
kann auch der nächste konkrete Schritt nicht klar sein.
Präzision entsteht durch Klarheit im Mandat.
Abhängigkeiten entstehen nicht zufällig
Viele Tickets altern wegen Abhängigkeiten:
- Architekturfreigaben
- Security-Reviews
- Pipeline-Zyklen anderer Teams
- ungeklärte Zuständigkeiten
Das wird häufig als Koordinationsproblem behandelt.
Tatsächlich ist es ein Ownership-Problem.
Wenn Prioritäten kollidieren, entscheidet das System selbst.
Dann gewinnt, wer gerade lauter ist oder weniger Risiko trägt.
Reife Organisationen klären:
- Wer entscheidet bei Zielkonflikten?
- Welche Risiken sind akzeptabel?
- Welche Abhängigkeiten sind strukturell notwendig – und welche selbst gebaut?
Abhängigkeiten sind kein Naturgesetz.
Sie sind Ergebnis von Strukturentscheidungen.
Effektivität vor Effizienz
Viele Teams optimieren ihre Effizienz:
- schnellere Pipelines
- bessere Templates
- sauberere Refactorings
Wichtiger ist die Frage:
Arbeiten wir am richtigen Problem?
Refactoring kann notwendig sein.
Es kann aber auch ein Ausweichen vor unbequemen Entscheidungen sein.
Wenn der Nutzer keinen Unterschied merkt
und das Betriebsrisiko unverändert bleibt,
ist es möglicherweise nicht die prioritäre Baustelle.
Effizienz ohne Prioritätsklarheit beschleunigt nur die falsche Richtung.
Mikro-Regeln ersetzen keine Führungsentscheidung
Produktivitätstipps helfen im Alltag.
Sie ersetzen keine strukturelle Klärung.
Wenn Teams ständig:
- Follow-ups timeboxen müssen
- informelle Deadlines setzen
- selbst Abhängigkeiten umgehen
dann fehlt nicht Disziplin.
Dann fehlt eine klare Entscheidungslinie.
Organisationen werden nicht stabil,
weil Individuen besser priorisieren.
Sie werden stabil,
wenn Verantwortung explizit verteilt und gelebt wird.
Was ein altes Ticket wirklich signalisiert
Ein Ticket, das drei Sprints offen ist, sagt nicht:
„Der Entwickler ist ineffizient.“
Es sagt:
- Das Ziel ist nicht eindeutig definiert.
- Die Startbedingungen waren unklar.
- Abhängigkeiten wurden nicht entschieden.
- Ownership ist diffus.
Das sind keine operativen Details.
Das sind Führungsfragen.
Die eigentliche Frage
Statt zu fragen:
„Wie bekommen wir dieses Ticket endlich fertig?“
ist die relevantere Frage:
Welche Entscheidung haben wir vermieden?
Denn unfertige Tickets sind selten Zufall.
Sie sind die sichtbare Oberfläche eines Systems,
das sich vor klaren Festlegungen drückt.
Und genau dort beginnt echte Verbesserung.