Drei Stunden Workshop, vierzig Klebezettel, ein Foto vom Whiteboard – und zwei Wochen später weiß niemand mehr, was eigentlich beschlossen wurde. So enden erstaunlich viele Workshops in Softwareprojekten. Dabei sind gut gemachte Workshops eines der wirksamsten Werkzeuge, die ein App-Team hat: Sie bringen Fachabteilung, Design und Entwicklung an einen Tisch, bevor teure Missverständnisse im Code landen.

Apps haben dabei ihre Eigenheiten. Ein Release muss durch die Prüfung der App-Stores, Nutzer aktualisieren nicht sofort, und Fragen wie Offline-Betrieb, Push-Benachrichtigungen oder Berechtigungen für Kamera und Standort sollten früh geklärt sein. Welche Workshop-Formate sich dafür eignen, wie Sie sie vorbereiten und wie die Ergebnisse tatsächlich im Backlog ankommen, zeigen die folgenden Abschnitte.

Was einen Workshop „agil“ macht

Ein agiler Workshop ist kein besonderes Meeting-Format mit Zertifikat. Gemeint ist eine moderierte, zeitlich begrenzte Arbeitssitzung, die ein konkretes Ergebnis liefert, das das Team im nächsten Entwicklungsschritt nutzt. Drei Merkmale unterscheiden ihn von einer Besprechung:

• Ein greifbares Ergebnis: eine priorisierte Story Map, ein getesteter Prototyp, eine Liste von Maßnahmen. Nicht „Wir haben darüber gesprochen“.
• Gemeinsames Arbeiten statt Präsentieren: Alle Beteiligten schreiben, skizzieren, ordnen. Die Moderation strukturiert, entscheidet aber nicht inhaltlich.
• Kurze Rückkopplung: Was im Workshop entsteht, wird bald überprüft – im nächsten Sprint, durch einen Nutzertest, im Review.

Diese Workshops ergänzen die regulären Scrum-Termine wie Sprint Planning, Review und Retrospektive. Manche davon sind selbst Workshops, andere finden nur zu bestimmten Projektphasen statt.

Wer Workshops allgemein in Webprojekten einsetzt, findet im Beitrag Workshop-Strategien in der modernen Webentwicklung einen breiteren Überblick. Hier geht es um die Formate, die in App-Projekten den Unterschied machen.

Welche Formate in welcher Projektphase helfen

Zum Start: Kick-off und Produktvision

Bevor die erste User Story geschrieben wird, sollte klar sein, für wen die App gebaut wird und welches Problem sie löst. Ein Vision-Workshop mit Auftraggeber, Fachabteilung und Team klärt Zielgruppe, die wichtigsten Nutzungssituationen und Erfolgskriterien. Angenommen, ein Handwerksbetrieb lässt eine App für seine Monteure entwickeln: Hier stellt sich sofort die Frage, ob die App im Keller ohne Netz funktionieren muss. Solche Rahmenbedingungen gehören in den ersten Workshop, nicht in den dritten Sprint.

Für App-Projekte gehören außerdem diese Entscheidungen früh auf den Tisch: iOS, Android oder beides? Native Entwicklung oder plattformübergreifend? Welche Geräte- und Betriebssystemversionen werden unterstützt? Welche Backend-Systeme müssen angebunden werden?

Für den Umfang: User Story Mapping

User Story Mapping, bekannt geworden durch Jeff Patton, ordnet die Funktionen einer App entlang des Wegs, den Nutzer durch die Anwendung nehmen. Oben steht der Ablauf („Auftrag öffnen“, „Material erfassen“, „Unterschrift einholen“), darunter die Funktionen in absteigender Wichtigkeit. Ein waagerechter Schnitt durch die Karte markiert, was in die erste Version gehört – das Minimum Viable Product (MVP), also die kleinste Version, mit der echte Nutzer arbeiten können.

Der Vorteil gegenüber einer flachen Backlog-Liste: Lücken im Ablauf fallen auf. Eine App, die Aufträge anzeigt, aber keinen Abschluss erlaubt, ist für Monteure wertlos, auch wenn jede einzelne Story sauber umgesetzt ist.

Für Unsicherheit: Design Sprint und Prototyp-Test

Wenn unklar ist, ob eine Idee bei Nutzern funktioniert, hilft ein Design Sprint. Das Format entstand bei Google und Google Ventures (heute GV) und wurde durch das Buch „Sprint“ von Jake Knapp, John Zeratsky und Braden Kowitz verbreitet: In der klassischen Form durchläuft ein kleines Team in fünf Tagen Problemverständnis, Ideen, Entscheidung, Prototyp und Test mit echten Nutzern. Viele Teams arbeiten heute mit verkürzten Varianten.

Für Apps ist der Prototyp-Test besonders wertvoll, weil ein Klickprototyp auf dem eigenen Smartphone anders wirkt als auf einem Beamer. Daumenreichweite, Schriftgrößen und Gesten fallen erst auf dem Gerät auf. Design-Werkzeuge wie Figma erlauben es, Prototypen direkt auf dem Telefon auszuprobieren.

Laufend: Refinement und Schätzung

Im Backlog Refinement zerlegt das Team große Anforderungen in umsetzbare Stories und klärt Akzeptanzkriterien. Bei Apps lohnt sich ein fester Blick auf Fälle, die gern vergessen werden: Was passiert ohne Netz, bei abgelehnter Berechtigung, bei sehr kleinem Bildschirm, bei aktivierter Großschrift? Eine kurze Checkliste für solche Randfälle spart später viele Fehlertickets.

Zum Abschluss eines Sprints: Review am echten Gerät

Ein Sprint Review überzeugt am meisten, wenn die Beteiligten die App selbst in der Hand haben. Testversionen lassen sich über TestFlight bei Apple und die Testtracks der Google Play Console an einen festen Kreis verteilen. So wird das Review zum kleinen Nutzertest statt zur Folienpräsentation.

Regelmäßig: Retrospektive

Die Retrospektive ist der Workshop, in dem das Team seine eigene Arbeitsweise verbessert. Wichtig ist, dass sie mit wenigen, konkreten Maßnahmen endet, die jemand verantwortet – und dass die nächste Retrospektive prüft, was daraus wurde. Wer Fortschritte messbar machen will, findet in unserem Beitrag zu Kennzahlen im agilen Projektmanagement Ansatzpunkte.

Vor dem Release: Release- und Rollout-Planung

App-Releases haben Besonderheiten, die ein eigener kurzer Workshop klären sollte: Store-Texte und Screenshots, Datenschutzangaben in den Stores, Zeitpuffer für die Prüfung durch Apple und Google, gestaffelte Auslieferung an einen Teil der Nutzer und die Frage, wie lange alte App-Versionen noch mit dem Backend funktionieren müssen. Wer das erst am Tag vor dem Launch bespricht, verschiebt den Launch.

Vorbereitung: Die meiste Arbeit passiert vorher

Ob ein Workshop gelingt, entscheidet sich größtenteils vor dem Termin.

1. Ziel in einem Satz. „Am Ende haben wir eine priorisierte Story Map für Version 1.“ Lässt sich das Ziel nicht so formulieren, ist es noch kein Workshop.
2. Die richtigen Leute. Wer entscheiden muss, sollte dabei sein; wer nur informiert werden will, bekommt das Ergebnis. Fünf bis neun aktive Teilnehmende sind ein guter Richtwert, größere Runden teilen Sie in Gruppen.
3. Eine Agenda mit Zeitfenstern. Jede Phase bekommt eine feste Dauer (Timebox). Pausen einplanen, bei Remote-Terminen häufiger und kürzer.
4. Vorarbeit verteilen. Nutzerfeedback, Analysedaten oder vorhandene Abläufe sollten vorher vorliegen, damit die gemeinsame Zeit nicht mit Vorlesen vergeht.
5. Material und Werkzeuge. Vor Ort reichen Whiteboard, Klebezettel und Stifte. Remote braucht es ein digitales Whiteboard wie Miro oder Mural und ein Videotool, das alle schon kennen. Ein kurzer Technikcheck vorab spart die ersten fünfzehn Minuten.

Moderation: Struktur geben, nicht Inhalte bestimmen

Gute Moderation ist unauffällig. Bewährt haben sich einige einfache Techniken:

• Erst still, dann laut. Alle schreiben ihre Ideen zunächst einzeln auf, bevor diskutiert wird. So kommen auch Ruhigere zu Wort, und die lauteste Meinung prägt nicht alles.
• Punkte statt Debatte. Zum Priorisieren verteilen alle eine begrenzte Zahl von Punkten (Dot Voting). Das beendet Endlosdiskussionen und macht Mehrheiten sichtbar.
• Parkplatz für Abschweifungen. Wichtige, aber nicht passende Themen kommen auf eine eigene Liste und werden am Ende verteilt.
• Entscheidung klar benennen. Am Ende jedes Blocks fasst die Moderation zusammen, was beschlossen ist, und fragt nach Einwänden.

Bei hybriden Workshops, in denen ein Teil im Raum sitzt und ein Teil zugeschaltet ist, geraten die Remote-Teilnehmenden leicht ins Hintertreffen. Eine pragmatische Lösung: Alle arbeiten am selben digitalen Whiteboard, auch die Personen im Raum.

Ergebnisse sichern: vom Whiteboard ins Backlog

Hier scheitern die meisten Workshops. Damit das Foto vom Whiteboard nicht das einzige Ergebnis bleibt, helfen drei Regeln:

• Noch am selben Tag übertragen. Stories, Akzeptanzkriterien und Entscheidungen landen im Ticketsystem, etwa in Jira, mit Verweis auf den Workshop.
• Jede Maßnahme hat einen Namen. „Wir sollten mehr testen“ ist keine Maßnahme. „Anna richtet bis Freitag den Testtrack für die Fachabteilung ein“ ist eine.
• Entscheidungen dokumentieren. Ein kurzes Entscheidungsprotokoll – was wurde entschieden, warum, welche Alternativen gab es – erspart Monate später die Diskussion, warum die App kein Tablet-Layout hat.

Inzwischen bieten viele Whiteboard- und Videotools KI-Funktionen an, die Klebezettel gruppieren oder Zusammenfassungen schreiben. Das spart Tipparbeit. Die Zusammenfassung sollte aber jemand prüfen, der dabei war, denn Nuancen und Gegenargumente gehen dabei leicht verloren. Bei Aufzeichnungen und KI-Auswertung sind außerdem die Einwilligung der Teilnehmenden und die Datenschutzvorgaben des Unternehmens zu beachten.

Typische Fehler und wie Sie sie vermeiden

• Zu viel Agenda. Drei Themen in zwei Stunden sind realistisch, acht nicht. Lieber einen zweiten Termin ansetzen.
• Workshop als Ersatz für Entscheidungen. Wenn die Person mit Budgetverantwortung fehlt, endet jede Priorisierung mit „Das müssen wir noch abstimmen“.
• Methode um der Methode willen. Nicht jedes Problem braucht einen fünftägigen Design Sprint. Manchmal reicht ein einstündiges Refinement mit den richtigen Leuten.
• Kein Follow-up. Ein Workshop ohne Nachverfolgung erzeugt beim nächsten Mal Zynismus. Spätestens im folgenden Review oder in der nächsten Retrospektive sollte sichtbar sein, was aus den Ergebnissen wurde.

Was das für Ihr App-Projekt bedeutet

Workshops sind kein Selbstzweck und kein Ersatz für gute Entwicklungsarbeit. Ihr Wert liegt darin, Unsicherheit früh und günstig zu klären: Was soll die App können, was nicht, und funktioniert die Idee bei echten Nutzern? Für die meisten App-Teams lohnen sich vor allem drei Formate – Story Mapping zum Start, Prototyp-Tests bei offenen Fragen und Reviews am echten Gerät. Retrospektiven und Refinement laufen ohnehin mit.

Überschätzt werden dagegen ausgefeilte Methodenbaukästen und neue Werkzeuge. Ein gut vorbereiteter Workshop mit Klebezetteln und klaren Entscheidungen bringt mehr als ein perfekt gestaltetes digitales Board, aus dem nie ein Ticket wird.

Wenn Sie eine App planen und Workshops als Teil des Projekts einsetzen möchten, finden Sie Hintergründe zu unserem Vorgehen bei der App-Entwicklung für iOS und Android. Für Teams, die Moderation und agile Formate selbst lernen wollen, gibt es passende Seminare und Workshops.

Häufige Fragen zu agilen Workshops in App-Projekten

Wie lange sollte ein agiler Workshop dauern?

Das hängt vom Format ab. Ein Refinement kommt oft mit ein bis zwei Stunden aus, ein Story-Mapping-Workshop für eine neue App kann einen ganzen Tag füllen. Der Scrum Guide gibt für das Sprint Planning eine Obergrenze von acht Stunden bei einem einmonatigen Sprint vor; bei kürzeren Sprints entsprechend weniger. Mehr als einen halben Tag am Stück sollten Sie remote nicht ansetzen.

Wie viele Personen sollten teilnehmen?

Fünf bis neun aktive Teilnehmende sind ein guter Richtwert. Der Scrum Guide nennt für ein Scrum-Team in der Regel höchstens zehn Personen. Oft wird in diesem Zusammenhang auch die „Two-Pizza-Regel“ zitiert, die Jeff Bezos zugeschrieben wird: Ein Team sollte nicht größer sein, als zwei Pizzen satt machen. Bei größeren Runden arbeiten Sie besser in Kleingruppen und führen die Ergebnisse zusammen.

Funktionieren Workshops remote genauso gut wie vor Ort?

Für Refinement, Reviews und Retrospektiven meist ja, wenn alle am selben digitalen Whiteboard arbeiten und die Moderation straffer plant. Für Kick-offs und intensive Formate wie Design Sprints ist ein Präsenztermin oft ergiebiger, weil Abstimmung und Ideenfindung im Raum schneller gehen. Viele Teams kombinieren beides: Start vor Ort, laufende Termine remote.

Wer sollte einen Workshop moderieren?

Idealerweise jemand, der inhaltlich nicht selbst entscheiden muss – etwa der Scrum Master oder eine externe Moderation. Wenn die Produktverantwortliche gleichzeitig moderiert und mitentscheidet, fällt es Teilnehmenden schwerer, offen zu widersprechen.