· Torsten · 3 min read
Der mutigste Satz in der Discovery: „Das bauen wir nicht."
Je mehr Stories in der Discovery geschlossen werden, desto besser. Discovery ist kein Pflichtprogramm vor dem Coding — sie ist der Filter, der entscheidet, was gebaut wird.
Ich erinnere mich noch gut an Backlogs, die zu endlosen Sammlungen aller möglichen Ideen angewachsen waren — übervoll und unübersichtlich.
Hunderte von Stories. Sauber beschrieben, priorisiert, mit Akzeptanzkriterien versehen. Alle wollten irgendwann gebaut werden. Und der Großteil davon? Wurde nie gebraucht.
Das ist kein Einzelfall. Es ist die Regel.
Discovery wird oft missverstanden
Viele Teams nutzen Discovery, um Stories vorzubereiten — Anforderungen klären, Designs abstimmen, Aufwände schätzen. Das ist wichtig. Aber es greift zu kurz.
Für mich ist Discovery vor allem eines: die Phase, in der ich herausfinde, was ich nicht bauen soll.
Das klingt kontraintuitiv. Warum so viel Aufwand für etwas, das am Ende im Papierkorb landet?
Weil es nichts Ineffizienteres gibt, als effizient das Falsche zu tun.
Eine Story zu discovern, zu refinern, zu entwickeln, zu testen und auszurollen — und dann festzustellen, dass niemand dieses Feature braucht — das kostet ein Vielfaches mehr als der Mut, früh Nein zu sagen.
Pareto gilt auch im Backlog
20 % der Stories schaffen 80 % des echten Werts. Die anderen 80 %? Gut gemeint. Vielleicht sogar sinnvoll klingend. Aber gemessen an dem, was Nutzer wirklich brauchen und was das Produkt wirklich voranbringt, sind sie Ballast.
Die Aufgabe der Discovery ist es, genau diese 20 % zu finden — und den Rest konsequent zu schließen.
Nicht irgendwann. Früh.
Je früher eine Story geschlossen wird, desto mehr Energie wurde gespart: keine Konzeption, kein Design, kein Development, kein Testing. Jeder Schritt im Prozess macht einen Rückzug teurer. Das ist der eigentliche Pareto-Funnel: nicht mehr was rein-, sondern was rauskommt.
Was das in der Praxis bedeutet
Ich schaue in der Discovery nicht nur, wie etwas gebaut werden soll. Ich frage zuerst, ob es gebaut werden soll.
- Welches echte Nutzerproblem löst diese Story?
- Haben wir Daten oder Feedback, das das unterstützt?
- Was passiert, wenn wir es nicht bauen?
Wenn diese Fragen keine überzeugenden Antworten liefern, ist die Discovery ein Erfolg — auch wenn die Story danach geschlossen wird. Gerade dann.
Eine Story zu schließen ist keine Niederlage. Es ist eine bewusste Entscheidung, die Energie freimacht für das, was wirklich zählt.
Aber: Das braucht Mut — und Mandat
Hier liegt der eigentliche Engpass. Nicht die Methode. Nicht das Framework.
Es braucht eine Product Owner oder einen Product Owner, die oder der die Befugnis hat, eine Entscheidung zu treffen — und den Mut, sie auch zu treffen. Auch wenn jemand diese Story vor Monaten eingestellt hat. Auch wenn Stakeholder enttäuscht sind. Auch wenn der Druck groß ist, alles irgendwann mal zu bauen.
Wer alles baut, was im Backlog landet, ist kein Produktteam. Das ist eine Feature-Fabrik.
Discovery ist der Filter, nicht die Vorbereitung
Discovery ist kein Pflichtprogramm vor dem Coding. Discovery ist der Filter, der entscheidet, was es überhaupt bis ins Development schafft.
Und je mehr Stories in der Discovery geschlossen werden — mit gutem Grund, auf Basis echter Erkenntnisse — desto höher die Chance, dass das, was gebaut wird, wirklich zählt.
Die mutigste und wertvollste Fähigkeit in der Produktentwicklung ist nicht, schnell zu liefern.
Es ist, rechtzeitig aufzuhören.
