Kontinuierliches Discovery bezeichnet den Prozess, bei dem ein interdisziplinäres Team aus Entwicklern, UX-Experten und Fachbereichsvertretern gemeinsam und fortlaufend Kundenprobleme versteht, bevor Features ins Backlog kommen. Scrum setzt ein fertiges Backlog voraus, lässt aber offen, wie es entsteht. Methoden wie Event Storming und User Story Mapping helfen, diesen Lücke zu schließen.
Das Wichtigste in Kürze
- Scrum setzt ein fertiges, priorisiertes Backlog voraus, klärt aber nicht, wie gute Anforderungen überhaupt entstehen: genau dieser blinde Fleck kostet Teams am Ende Relevanz.
- User Story Mapping und Event Storming bringen Entwickler, Fachexperten und User gemeinsam in einen Raum und erzeugen durch die Diskussion ein geteiltes Verständnis, das kein Dokument ersetzen kann.
- Gemba Walks, also der Besuch beim Anwender vor Ort, decken Workarounds und Nutzungslücken auf, die das Entwicklungsteam aus der Distanz schlicht nicht sieht.
- Ein interdisziplinäres Team braucht gezielt Personen mit fachlichem Fokus, weil nicht jeder Entwickler Fachlichkeit durchdringen will und soll, diese Brille aber trotzdem im Team vorhanden sein muss.
Scrum optimiert die Lieferung, nicht die Entdeckung
Scrum konzentriert sich fast vollständig auf Delivery und blendet die Discovery-Phase aus. Der Scrum Guide setzt ein fertiges, priorisiertes Backlog voraus. Wie diese Anforderungen überhaupt in das Backlog kommen, bleibt offen.
Genau hier liegt eine Lücke. Der Scrum Guide hält die Rolle des Product Owners bewusst vage und beschreibt seine Verantwortung nur grob. Auf wenigen Seiten lässt sich nicht jedes Projektproblem abdecken. Das ist legitim, verschiebt aber die eigentlich schwierige Frage nach hinten: Welche Methoden helfen, ein gutes Backlog aufzubauen, und wie holst du schnell Feedback vom Kunden?
Scrum verfolgt an dieser Stelle gegensätzliche Ziele. Auf der einen Seite steht das auslieferbare Produkt-Inkrement mit hohem Qualitätsanspruch. Auf der anderen Seite das Bedürfnis nach möglichst frühem Feedback. Wer eine Idee erst sauber durchbaut und ausliefert, erfährt oft zu spät, dass der Kunde sie gar nicht braucht. Der Fokus gehört deshalb auf den Outcome, nicht nur auf den Output.
Warum Fachlichkeit ins Entwicklungsteam gehört
Entwickler, die nur das nächste Backlog-Item abarbeiten, ohne das Problem dahinter zu verstehen, liefern Output ohne Wirkung. Ina Einemann beschreibt diese Haltung zugespitzt: das Team nimmt sich das nächste Item, setzt es um und versteht fachlich nicht, wofür. Das ist kein tragfähiges Modell.
Der Titel “Komm mir nicht mit Fachlichkeit” meint das Gegenteil von dem, was er sagt. Fachlichkeit ist nicht das Problem, sie ist die Voraussetzung. Ohne ein Verständnis der Domäne lässt sich das Problem des Kunden nicht lösen, sondern nur blind nachbauen.
Wichtig ist dabei die Richtung. Die Fachlichkeit bleibt nicht im Fachbereich, der allein mit dem Kunden spricht und Anforderungen weiterreicht. Stattdessen lernt das ganze Team gemeinsam, wie der Kunde tickt und welche Probleme er hat. Innovationen entstehen häufig im technischen Bereich. Entwickler, die den Problemraum kennen, bringen Ideen ein, die ein reiner Fachbereich nicht sehen würde.
Diese gemeinsame Entdeckung darf kein Mini-Wasserfall werden. Es geht nicht darum, ein vorgeschaltetes Discovery-Team zu bauen, das Ideen testet und nach hinten durchreicht. Es geht um ein interdisziplinäres Team, das zusammen lernt.
Event Storming und User Story Mapping bringen alle in einen Raum
Beide Methoden starten gleich: alle Perspektiven in einem Raum. User, Product Owner, Business Owner und die technische Seite. Die Beteiligten arbeiten mit Stickys und kommen sofort ins Tun, ohne vorher eine Notation wie UML lernen zu müssen.
Der gemeinsame Raum ist kein Detail, sondern der Kern. Die gleichen Diskussionen entstehen digital nicht. Der eigentliche Wert liegt im direkten Austausch: wenn zwei User merken, dass sie denselben Begriff unterschiedlich definieren, und das im Workshop sichtbar wird. Eine fertige Map später nur durchzusprechen hat einen Wert, aber nicht denselben.
User Story Mapping baut ein zweidimensionales Backlog
User Story Mapping sammelt Tätigkeiten und bricht sie von einer hohen Flughöhe schrittweise herunter. Am Beispiel “morgens aufstehen”: die oberste Reihe lautet “ins Badezimmer gehen”, “etwas essen”, “das Haus verlassen”. Darunter folgt die nächste Ebene, etwa “anziehen”, “duschen”. Ganz unten stehen feingranulare Schritte wie “in die Dusche gehen”, “Shampoo in die Hand nehmen”.
Innerhalb jeder Spalte lässt sich priorisieren. Angezogen das Haus verlassen ist Pflicht, das Haarewaschen an diesem Tag verzichtbar. Wer einmal von vorne bis hinten durch den gesamten Prozess geht, erhält einen kompletten Durchstich. Das Ergebnis ist ein zweidimensional aufgebautes Backlog, in dem die obere Reihe direkt die ersten User Stories liefert.
Event Storming schärft Service- und Teamschnitt
Event Storming beginnt im Kleinen und sammelt fachliche Events, die in der Anwendung passieren. Events werden in der Vergangenheit formuliert, weil sie abgeschlossen sind: “Rechnung wurde verschickt”, “Auftragsbestätigung wurde verschickt”. Hier kann nichts mehr schiefgehen.
Später kommen weitere Farben dazu: Personen, externe Systeme und Commands. Commands stehen im Präsens und machen sichtbar, dass es neben dem Happy Path auch Fehlerfälle gibt. Aus dieser genaueren Modellierung lässt sich der Prozess schneiden.
Event Storming zahlt damit auf einen guten Service-Schnitt und darauf aufbauend auf einen guten Team-Schnitt ein. Es eignet sich für den Start großer Projekte ebenso wie für das Modularisieren übernommener Altanwendungen, dann technisch getrieben.
| User Story Mapping | Event Storming | |
|---|---|---|
| Richtung | von oben nach unten, vom Großen ins Kleine | von unten nach oben, vom Event zum Prozess |
| Bausteine | Tätigkeiten in Spalten | Events, Commands, Personen, externe Systeme |
| Ergebnis | priorisiertes, zweidimensionales Backlog | Service-Schnitt und Team-Schnitt |
| Typischer Einsatz | Backlog-Aufbau, Durchstich durchs Produkt | Projektstart, Modularisierung von Altanwendungen |
Discovery hört nach dem Kick-off nicht auf
Der häufigste Fehler ist, Discovery als einmaligen Auftakt zu behandeln. Der Kick-off-Workshop schafft ein Big Picture und ein gemeinsames Verständnis, das ist ein starker Start. Schwierig wird es, dieses kontinuierliche Lernen im laufenden Prozess zu halten.
Viele Teams leben nicht einmal die Feedback-Schleifen, die im Scrum Guide stehen. Das Review ist als Arbeitstermin gedacht, in dem Stakeholder Feedback geben und das Backlog gemeinsam überarbeitet wird. In der Praxis passiert oft nicht einmal das.
Kontinuierliche Discovery bedeutet, regelmäßig auf die modellierten Prozessteile zu schauen und zu prüfen, ob das Modell noch zur Fachlichkeit passt und das Problem noch löst. An dieser Stelle ist auch ein digitales Tool wie Miro sinnvoll, weil sich Prozessmodelle dort leichter pflegen lassen als auf Papier.
Der Gemba Walk zeigt, was Anwender wirklich tun
Wer dem Anwender vor Ort über die Schulter schaut, sieht die Workarounds, von denen das Entwicklungsteam sonst nie erfährt. Der Gemba Walk macht sichtbar, wo Nutzer mit Behelfslösungen arbeiten und wo die eigentlichen Probleme liegen.
Diese direkte Beobachtung verändert die Energie im Team. Nach einem Besuch in den Produktionshallen, in denen die Software im Einsatz ist, entstehen neue Ideen und ein neues Verständnis. Es ist ein größerer Block, der Planung braucht, aber er gibt dem Team einen Schub.
Nicht jede Anwendung lässt sich vor Ort beobachten. Ist der Endnutzer schwer erreichbar, hilft eine Abfrage im System, eine Art Fragebogen- oder Interview-Technik, die den Nutzer so weit wie möglich in den Prozess einbindet. Entscheidend ist, dass er offen für solche Experimente ist.
Schnelles Feedback geht ohne fertiges Inkrement
Du musst eine Idee nicht erst auslieferbar bauen, um zu lernen, ob der Kunde sie braucht. Genau dieses Missverständnis kostet Zeit: Wer alles vorab qualitativ hochwertig durchbaut, verprobt zu spät.
Ein Papierprototyp oder ein Interview reicht oft, um eine Idee auszuloten, bevor die Entwicklung startet. Diese Vorarbeit übernehmen UX-Experten und Fachexperten, die zum Team gehören. Entwickler müssen nicht selbst den ganzen Tag Interviews führen, aber sie lernen mit, was der Kunde will.
Keiner möchte etwas bauen, was keiner benutzt. Auch wenn es technisch herausfordernd ist und Spaß macht, wenn es danach niemand nutzt, damit kriegt man auch die Skeptiker.
Ina Einemann
Gemischte Teams überzeugen auch die Skeptiker
Nicht jeder Entwickler will sich in die Fachlichkeit eingraben, und das ist in Ordnung. Manche wollen tief in die Technik, ins Backend oder ins Frontend. Das Wissen über die Domäne ist zu breit, als dass eine Person alles leisten könnte.
Deshalb gehört in jedes Team eine Mischung. Genauso wie es Backend- und Frontend-Experten braucht, braucht es ein, zwei neugierige Kollegen mit fachlichem Fokus, die Discovery kontinuierlich anstoßen. Sie zeigen im Review, was sie im letzten Sprint gelernt haben, und stimmen im Daily ab, welche Experimente als Nächstes anstehen.
Die Skeptiker gewinnst du nicht über Pflicht, sondern über den Nutzen. Wenn ein Entwickler versteht, dass diese Kollegen verhindern, dass er etwas baut, das niemand benutzt, sieht er den Wert. Er muss es nicht selbst tun, er muss nur akzeptieren, dass es wichtig ist.
Ein interner Hackathon holt Ideen aus der Technik zurück
Wenn Entwickler den Problemraum verstanden haben, lohnt es sich, sie selbst überlegen zu lassen, welche Features sie umsetzen würden. Ein kleiner interner Hackathon gibt ihnen genau diesen Raum.
Das Ergebnis kann überraschen. Nach einem solchen Hackathon kam starkes Feedback von Kunden, weil Probleme gelöst wurden, die gar nicht im Fokus standen und von denen niemand wusste, dass sie so schnell lösbar sind. Um daraus etwas Auslieferbares zu machen, braucht es hier und da Nacharbeit. Der eigentliche Gewinn ist der Rückfluss: Ideen aus der Technik wandern zurück in die Fachlichkeit.
