Just in Time spezifizieren

Das ist der zweite Teil der Werkzeugkiste des Product Owners. Das durchgehende Beispiel ist ein Tool, das die Tabelle ersetzt, in der eine Firma mit 300 Leuten ihre Ferienanträge verwaltet.

Früher hätte man für das Ferientool zuerst ein Pflichtenheft geschrieben: vierzig Seiten über jede Abwesenheitsart, jeden Bewilligungsweg und jeden Sonderfall rund um den Jahreswechsel, unterschrieben, bevor jemand eine Zeile Code schreibt.

Das scheitert auf zwei Arten, und beide kosten Geld.

Der Inhalt veraltet. Anforderungen ändern sich, während man sie aufschreibt, und das Umfeld ändert sich mit. Bis die Entwicklung bei Seite 30 ankommt, beschreibt Seite 30 ein Bedürfnis, das es nicht mehr gibt. Das Schreiben war verlorene Arbeit, das Nachführen ist noch mehr davon.

Die Details gehen zu tief. Die Hälfte dessen, was spezifiziert ist, wird nie gebaut, weil sich Prioritäten verschieben oder das erste Release etwas Neues zeigt. Die detaillierte Beschreibung hast du trotzdem bezahlt.

Details auf Abruf

Just-in-time-Spezifikation heisst: Eine Anforderung ist nur so detailliert, wie der nächste Schritt es braucht. Sie wird Schritt für Schritt verfeinert, als Teil der Arbeit, von der groben Idee bis zu etwas, das ein Team bauen kann:

1. Idee: eine Zeile. «Mitarbeitende sehen ihre verbleibenden Tage.»
2. Backlog-Eintrag: genug, um ihn gegen andere Einträge zu priorisieren.
3. In Arbeit: mit dem Team besprochen und auf eine Grösse geschnitten, die in einen Sprint passt.
4. Bereit zur Umsetzung: Akzeptanzkriterien, Sonderfälle, offene Fragen geklärt.

Auf die nächste Ebene gehst du erst, wenn das für eine konkrete Umsetzung sinnvoll ist. Wird eine Idee verworfen, hört die Dokumentation sofort auf. Meine Regel: so früh wie nötig, so spät wie möglich.

Vom Warum zum Was

Dieselbe Idee gilt für die ganze Hierarchie von Backlog-Einträgen:

• Vision: warum es das Produkt gibt
• Ziel: was wir als Nächstes erreichen wollen
• Epic: ein grosses Bedürfnis oder Problem, in das sich zu investieren lohnt
• Feature: eine Funktionalität für eine Gruppe von Nutzern
• User Story: ein Stück, das klein genug für einen Sprint ist

Je weiter oben ein Eintrag steht, desto mehr sagt er über das Warum. Je weiter unten, desto mehr über das Was. Mit jedem Schritt nach unten steigen Detailgrad und Kosten, und das Verständnis wächst mit.

Auch die Form ändert sich unterwegs. Oben wird gezeichnet: eine Skizze des Prozesses, ein Bild der Person, die unter der Tabelle leidet. Bilder schaffen schneller ein gemeinsames Verständnis des Kontexts als Text, und sie machen das spätere Refinement viel einfacher. Unten wird geschrieben: Text, ein Modell, Akzeptanzkriterien. Und geredet, mit einer Zeichnung am Whiteboard daneben.

Nicht eine Ebene fertig machen, sondern der Priorität folgen

Der Detailgrad folgt der Priorität, nicht der Ebene. Du machst nicht zuerst alle Epics fertig, dann alle Features, dann alle Stories. Du gehst nur dort in die Tiefe, wo die Arbeit gleich beginnt.

Beim Ferientool heisst das: Die Vision ist geschrieben, und auf dem Board stehen vier Epics. Nur eines davon, «Ferien beantragen und bewilligen», ist in Features heruntergebrochen. Nur die ersten zwei Features haben Stories. «Nicht bezogene Tage ins nächste Jahr übertragen» ist noch eine einzige Zeile, und das ist richtig so, weil das vor dem Frühling niemand anfasst.

Deine Ebenen, deine Definitionen

In der Praxis brauchen wenige Teams jede Ebene. Ein kleines Produkt kann mit Features und Stories anfangen und Epics ergänzen, sobald es genug Features zum Gruppieren gibt. Wichtig ist, dass das Team jede Ebene definiert, die es nutzt, und auch, wer auf dieser Ebene priorisiert.

Die Tools sind sich bei den Begriffen nicht einig. In einem Setup enthält ein Feature mehrere Epics, im nächsten ist es umgekehrt, und manche Teams sagen «Thema» zu einer Gruppe von irgendwas. Mike Cohn hat schon vor Jahren darauf hingewiesen, dass Story, Epic und Theme nur Wörter sind, die manche Gespräche einfacher machen. Leg eine Bedeutung fest, schreib sie auf und benutze sie konsequent.

Als Nächstes

Jede Ebene dieser Leiter hängt an der obersten. Nächstes Mal schreibe ich deshalb die Produktvision des Ferientools und erkläre, warum ihre wichtigste Aufgabe ist, Nein zu sagen.