Wie ich meine Projektplanung in Jira komplett automatisiert habe – und die „Original Estimate“-Falle umgangen bin.
Termin verschiebt sich, Dutzende Vorgänge müssen nachgezogen werden: Wie ein selbstheilender Projektplan in Jira funktioniert – mit eigenem Zahlenfeld statt Original Estimate.
Es gibt eine Frustration, die nur Jira-Power-User kennen: Du hast einen sauber strukturierten Projektplan, verknüpfte Epics, Stories, Sub-Tasks – und dann verschiebt sich ein Termin. Plötzlich ziehst du Datumsänderungen manuell durch Dutzende Vorgänge und fragst dich, warum du die Struktur überhaupt aufgebaut hast. Ich war oft genug an diesem Punkt und habe mir lange eingeredet, das sei der Preis für echte Projektplanung in Jira. Ist es nicht. Hier ist, wie ich es gelöst habe.
Das Problem: kaskadierende Datumsänderungen fressen Zeit
In jedem nicht-trivialen Projekt stehen Vorgänge nicht für sich. Epics haben Stories, Meilensteine blockieren andere Meilensteine. Verschiebt sich ein Fälligkeitsdatum – und das passiert immer – muss alles Nachgelagerte mitwandern.
Manuell heißt das:
- Jedes verknüpfte Ticket erneut öffnen.
- Neue Termine im Kopf aus den Schätzungen zurückrechnen.
- Hoffen, dass keine Abhängigkeit übersehen wurde.
- Das Ganze bei jeder Änderung wiederholen.
Warum ich „Original Estimate“ für Smart Values meide
Bevor ich zeige, was ich gebaut habe, kurz zu dem, was ich bewusst nicht gebaut habe. Der erste Reflex ist, Jiras eingebautes Feld „Original Estimate“ für zeitbasierte Smart-Value-Berechnungen zu nutzen. Klingt naheliegend: Das Feld existiert, es speichert Zeitwerte, Smart Values sollten damit umgehen können.
Wer es versucht hat, kennt die Wand. Das Feld wird intern in Sekunden gespeichert und verhält sich in Smart-Value-Ausdrücken inkonsistent. Berechnungen, die auf dem Papier korrekt aussehen, liefern falsche Ergebnisse – oder scheitern still. Die Community-Threads dazu sind lang, schmerzhaft und ungelöst.
Meine Lösung: ein eigenes numerisches Feld. Ich habe ein Zahlenfeld „Estimate“ angelegt und speichere Schätzungen dort als schlichte Ganzzahlen – 5 für eine Fünf-Tage-Aufgabe, 10 für zwei Wochen. Keine Zeitformatierung, keine Sekundenumrechnung, keine Überraschungen. Diese eine Entscheidung hat alles Weitere möglich gemacht.
Ebene 1: Datumsänderung erkennen und Startdaten kaskadieren
Trigger: Feldwert geändert → Fälligkeitsdatum. Die erste Automation feuert, sobald das Fälligkeitsdatum eines Vorgangs aktualisiert wird – egal ob Epic, Meilenstein oder ein anderer Vorgang, von dem etwas abhängt.
Eine Bedingung prüft zuerst, ob die Änderung überhaupt relevant ist (Filter nach Vorgangstyp, Projekt oder weiteren Kriterien halten das Ganze chirurgisch). Danach läuft eine Schleife über „verknüpfte Vorgänge – alle Verknüpfungstypen“ mit drei Schritten:
- Vorgang bearbeiten → Startdatum: Das Startdatum jedes abhängigen Vorgangs wird auf das neue Fälligkeitsdatum des übergeordneten Vorgangs gesetzt. Rutscht das Epic auf den 15. Oktober, startet alles Nachgelagerte ab dem 15. Oktober.
- Vorgangsdaten neu laden (Re-fetch): Klein, aber entscheidend – vor der Berechnung wird der aktuelle Zustand inklusive des eigenen Schätzfelds neu geholt. Sonst rechnet die Automation mit veralteten Werten.
- Vorgang bearbeiten → Fälligkeitsdatum: Aus dem neuen Startdatum plus Schätzung entsteht automatisch das korrekte neue Fälligkeitsdatum.
Der Smart Value, der es möglich macht
{{duedate.plusDays(Estimate)}}
duedate ist das Feld mit dem Fälligkeitsdatum in unserer Instanz. .plusDays() ist eine Smart-Value-Funktion, die Tage auf ein Datum addiert. Estimate ist das eigene Schätzfeld.
Weil das Feld eine reine Zahl ist und kein zeitformatierter String, ist die Berechnung jedes Mal sauber und vorhersagbar: keine Sekunden-Umrechnung, keine Sonderfälle, keine stillen Fehler.
Ebene 2: die Kaskade der Kaskade
Hier wird es richtig interessant. Weil das Ändern eines Fälligkeitsdatums selbst wieder der Trigger der ersten Automation ist, arbeitet das System von Natur aus rekursiv. Aktualisiert Automation 1 das Fälligkeitsdatum eines abhängigen Vorgangs, startet sie für dessen Abhängigkeiten erneut.
Die Kaskade läuft damit automatisch durch die gesamte Abhängigkeitskette – eine separate „Deep Cascade“-Automation braucht es nicht. Eine Warnung: Der Abhängigkeitsgraph darf keine Zyklen enthalten, sonst entsteht eine Endlosschleife.
Was als Nächstes kommt: intelligente Stakeholder-Briefings
Das läuft in der Praxis hervorragend – fertig ist das System aber noch nicht. Die nächste Automation beobachtet den Projektplan auf relevante Abweichungen und informiert Stakeholder automatisch, sobald Schwellwerte gerissen werden. Geplante Regeln:
- „Projekt liegt mehr als einen Monat hinter Plan“ → Zusammenfassung per E-Mail oder Slack an die Sponsoren.
- „Drei oder mehr Meilensteine haben sich in sieben Tagen verschoben“ → Projekt-Health-Report auslösen.
- „Epic auf dem kritischen Pfad ist überfällig“ → Eskalation mit Kontext an die Projektleitung.
Erkenntnisse
- „Original Estimate“ für Smart-Value-Mathematik meiden – stattdessen ein eigenes Zahlenfeld in Arbeitstagen anlegen.
- Vor jeder Datumsberechnung „Vorgangsdaten neu laden“ einbauen, damit mit frischen Werten gerechnet wird.
- Den Trigger als Kaskaden-Motor nutzen: Wer ein Feld aktualisiert, das selbst Trigger ist, braucht keine manuelle Rekursion.
- Modular bleiben: eine Automation pro Anliegen – leichter zu debuggen, leichter zu pflegen.
