Kollabe
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

Asynchrones Sprint Planning: Kann das wirklich funktionieren?

Verteilte Teammitglieder, die von verschiedenen Standorten aus arbeiten, mit Planning-Artefakten, die durch gestrichelte Linien verbunden zwischen ihnen schweben
Kelly Lewandowski

Kelly Lewandowski

Zuletzt aktualisiert am 25/03/20267 Min. Lesezeit

Sprint Planning ist eine der wenigen Scrum-Zeremonien, bei denen das gesamte Team das Meeting mit demselben Verständnis davon verlassen muss, was gebaut wird und warum. Das macht es zu einem schwierigen Kandidaten für eine vollständig asynchrone Durchführung. Doch der Großteil dessen, was in einem zweistündigen Planning-Meeting passiert, erfordert eigentlich nicht, dass alle zur gleichen Zeit im selben Raum (oder Call) sind. Teams, die asynchrones Planning gut umsetzen, überspringen das Gespräch nicht. Sie verlagern lediglich die Lese- und Denkphasen aus dem Meeting heraus, damit die gemeinsame Zeit für echte Entscheidungen genutzt werden kann.

Das Problem mit vollständig synchronem Planning

Ein typisches Sprint-Planning-Meeting dauert 1-2 Stunden für einen zweiwöchigen Sprint. In der Praxis entfällt ein großer Teil dieser Zeit auf Aktivitäten, die nicht von einer Diskussion in Echtzeit profitieren:
  • Tickets durchlesen, die hätte vorher überprüft werden können
  • Klärungsfragen stellen, die der Product Owner schriftlich hätte beantworten können
  • Auf den langsamsten Leser warten, bevor zum nächsten Punkt weitergegangen wird
  • Kontext erneut erklären, der bereits im Backlog vorhanden ist, aber den niemand gelesen hat
Bei verteilten Teams über Zeitzonen hinweg verschärft sich das Problem. Jemand nimmt immer an einem ungünstigen Zeitpunkt am Meeting teil. Und ein müdes Teammitglied um 22 Uhr trägt nicht sein bestes Denken zu Kapazitätsdiskussionen bei.

Was wirklich asynchron funktioniert

Einige Teile des Plannings lassen sich gut asynchron durchführen, ohne etwas zu verlieren:

Backlog-Review und Kontextvermittlung

Der Product Owner teilt die Kandidaten-Items für den Sprint zusammen mit dem vorgeschlagenen Sprint-Ziel 1-2 Tage vor dem Planning. Teammitglieder überprüfen diese in ihrer eigenen Zeit, hinterlassen Fragen als Kommentare und kennzeichnen alles Unklare. Wenn das Meeting beginnt, hat jeder die Arbeit bereits gelesen und verinnerlicht.

Schätzung

Das ist der Teil, der sich am besten asynchron umsetzen lässt. Tools wie Kollabes Planning Poker ermöglichen es Teammitgliedern, Stories unabhängig voneinander zu schätzen, ohne den Verankerungseffekt durch das zuerst genannte Ergebnis eines Senior-Entwicklers. Jede Person überprüft die Story, vergibt ihre Schätzung und macht weiter. Meinungsverschiedenheiten werden sichtbar, wenn die Stimmen auseinandergehen, und diese spezifischen Items können für eine synchrone Diskussion markiert werden. Für einen tieferen Einblick in die Durchführung von Schätzungen ohne Live-Call, lesen Sie unseren Leitfaden zum asynchronen Planning Poker.

Kapazität und Verfügbarkeit

Urlaub, Schulungstage, Bereitschaftsdienste. Diese Informationen können in einem gemeinsamen Dokument oder Slack-Thread festgehalten werden. Niemand braucht ein Meeting, um zu sagen „Ich bin Donnerstag und Freitag nicht da."

Definition-of-Ready-Prüfungen

Ob jedes Backlog-Item der Definition of Ready Ihres Teams entspricht, ist eine einfache Ja/Nein-Prüfung. Teammitglieder können Items asynchron anhand der Kriterien überprüfen und Lücken für den Product Owner kennzeichnen, damit diese vor der synchronen Session behoben werden. Teammitglied, das Sprint-Backlog-Items auf einem Laptop überprüft, mit Häkchen und Fragezeichen über verschiedenen Items

Was trotzdem einen Live-Call braucht

Vollständig asynchron zu gehen ist der Punkt, an dem Teams sich üblicherweise die Finger verbrennen. Einige Teile des Plannings brauchen die Hin-und-Her-Geschwindigkeit, die nur ein Echtzeit-Gespräch bieten kann.

Aushandlung des Sprint-Ziels

Das Sprint-Ziel ist eine Verpflichtung darüber, worauf das Team in diesem Zyklus optimiert. Wenn Prioritäten konkurrieren oder das Ziel nicht offensichtlich ist, muss diese Diskussion live stattfinden. Asynchrone Threads über konkurrierende Prioritäten neigen dazu, sich tagelang ohne Ergebnis hinzuziehen. Wenn sich etwas wirklich nicht asynchron lösen lässt, ist manchmal der schnellste Weg nach vorne der einfachste. Teams haben bekanntermaßen eine Münze geworfen, um bei wenig riskanten Entscheidungen einen Patt zu lösen, anstatt noch ein weiteres Meeting zu planen. Das klingt albern, ist aber besser als ein dreitägiger Slack-Thread darüber, ob man das Dashboard-Redesign oder die API-Bereinigung priorisieren soll.

Scope-Commitment

Nach asynchroner Schätzung und Review braucht das Team einen Moment, um gemeinsam das Gesamtbild zu betrachten: das Sprint-Ziel, die ausgewählten Items, die Kapazität. „Können wir das wirklich schaffen?" ist eine Frage, die am besten als Gruppe beantwortet wird, wo jemand sagen kann „das ist zu viel" und das Team in Echtzeit verhandeln kann.

Hoch-ambige Items

Wenn eine Story unklare Anforderungen oder echtes technisches Risiko hat, reichen asynchrone Kommentare nicht aus. Diese Items brauchen Whiteboarding oder zumindest ein fokussiertes Gespräch, bei dem die Leute Optionen in Echtzeit durchsprechen können.

Das hybride Modell

Erledigen Sie die Vorbereitung asynchron. Reservieren Sie die Live-Session für Abstimmung und Entscheidungen. So sieht das in der Praxis aus:
Async: Kandidaten teilen (2 Tage vorher)
Der Product Owner veröffentlicht das vorgeschlagene Sprint-Ziel und die Kandidaten-Backlog-Items. Das Team überprüft, stellt Fragen und schätzt mit einem asynchronen Planning-Poker-Tool.
Async: Blocker kennzeichnen (1 Tag vorher)
Teammitglieder markieren Items, die sie nicht sicher schätzen können, teilen ihre Kapazität und vermerken Bedenken. Der Product Owner beantwortet offene Fragen.
Sync: Abstimmen und verpflichten (30-60 Minuten)
Sprint-Ziel gemeinsam überprüfen. Nur gekennzeichnete Items besprechen. Scope gegen Kapazität bestätigen. Mit einer gemeinsamen Verpflichtung herausgehen.
Teams, die dieses Modell verwenden, reduzieren ihre synchrone Planning-Zeit regelmäßig von zwei Stunden auf 30-60 Minuten. Das Meeting wird zu einer Entscheidungssitzung statt eines Lese-und-Diskussions-Marathons. Team in einem kurzen Video-Call mit einem klaren Agenda-Board, das nur drei gekennzeichnete Diskussionspunkte zeigt

Wann man vollständig synchron bleiben sollte

Asynchrones Planning ist nicht für jedes Team geeignet. Behalten Sie das vollständige Meeting, wenn:
  • Ihr Team neu ist. Menschen, die noch keinen gemeinsamen Kontext aufgebaut haben, brauchen mehr persönliche Zeit, um Erwartungen zu kalibrieren und Vertrauen aufzubauen.
  • Sie noch am Anfang der Scrum-Einführung stehen. Die Struktur einer vollständigen Zeremonie hilft, bis sich die Gewohnheiten festigen.
  • Die Arbeit überwiegend explorativ ist. Wenn die meisten Sprint-Items forschungsintensiv sind, verbringen Sie sowieso mehr Zeit mit Diskutieren als mit Schätzen.
  • Ihr Backlog unübersichtlich ist. Asynchrones Planning setzt voraus, dass Items bereit ankommen. Wenn nicht, verbrennen Sie die synchrone Zeit damit, halbgare Tickets zu sortieren.

Asynchrone Schätzung zum Laufen bringen

Wenn Schätzung der Teil ist, den Sie asynchron verlagern, helfen einige Dinge dabei:
PraxisWarum es wichtig ist
Eine Deadline für Stimmen setzenOhne eine solche zieht sich die Schätzung unendlich hin
Relative Größenordnungen verwendenFibonacci oder T-Shirt-Größen funktionieren asynchron besser als stundenbasierte Schätzungen
Kontext mit jeder Story anzeigenAbnahmekriterien, Designs und Abhängigkeiten sollten angehängt, nicht verlinkt sein
Divergente Stimmen automatisch kennzeichnenTools wie Kollabe heben hervor, wenn Schätzungen weit auseinanderliegen, damit Sie wissen, was synchron besprochen werden muss
Runden kurz haltenNicht 30 Stories auf einmal abladen. In Gruppen von 5-8 aufteilen
Wenn Sie unsicher sind, wie komplex eine Story vor der Schätzung ist, kann der Estimation Complexity Analyzer Ihnen helfen zu entscheiden, ob etwas eine Gruppendiskussion braucht oder unabhängig geschätzt werden kann.

Ein realistischer Zeitplan

So sieht async-first Planning für ein Team mit zweiwöchigen Sprints aus: Mittwoch (2 Tage vor Sprint-Start):
  • Product Owner teilt Kandidaten-Items und Sprint-Ziel-Entwurf
  • Team beginnt mit asynchronem Review und Schätzung
Donnerstag (1 Tag vorher):
  • Schätzungs-Deadline
  • Team kennzeichnet Items, die Diskussion benötigen
  • Product Owner beantwortet offene Fragen
Freitag (Sprint-Start):
  • 30-60-minütige synchrone Session: Ziel bestätigen, Kennzeichnungen auflösen, Scope committen
  • Sprint beginnt
Gesamtzeitaufwand pro Person: unter zwei Stunden, ungefähr gleich wie ein einzelnes traditionelles Planning-Meeting. Der Unterschied ist, dass er sich über drei Tage verteilt und der Großteil davon passiert, wenn es für jede Person günstig ist.

Klein anfangen

Asynchrones Sprint Planning funktioniert, wenn Sie es als Möglichkeit betrachten, Ihre synchrone Zeit fokussierter zu gestalten — nicht als Ersatz für Gespräche insgesamt. Verlagern Sie zuerst Schätzung und Backlog-Review asynchron. Behalten Sie Zielsetzung und Commitment synchron. Sehen Sie von dort aus, was Ihr Team wirklich braucht — nicht was in der Theorie effizient klingt.

Technisch gesehen ja, aber die meisten Teams stellen fest, dass Scope-Commitment und Sprint-Ziel-Diskussionen live besser funktionieren. Ein hybrider Ansatz — asynchrone Vorbereitung mit einer kurzen synchronen Session — führt tendenziell zu besseren Ergebnissen.

Mit guter asynchroner Vorbereitung reichen in der Regel 30-60 Minuten. Wenn Sie regelmäßig über eine Stunde hinausgehen, muss Ihre asynchrone Vorbereitung wahrscheinlich verbessert werden.

Sie benötigen ein Backlog-Tool (Jira, Linear usw.) in Kombination mit einem asynchronen Schätzungs-Tool wie Kollabes Planning Poker. Die Kommunikation erfolgt über die normalen Kanäle Ihres Teams — Slack, Teams oder ähnliches.

Es kann, obwohl die Vorteile geringer sind. Teams am gleichen Ort gewinnen hauptsächlich Zeit, indem die Leute Items unabhängig voneinander überprüfen, anstatt gemeinsam in einem Raum zu lesen.