Wenn die Zahlen keine Rolle spielen: Warum Teams trotz perfekter Schätzungen Termine verpassen

TL; DR‍

Die Sprint-Planung fühlt sich schwieriger an, weil verteilte/asynchrone Arbeit, Toolkonsolidierung und Atlassian-KI zu Prioritätsproblemen, Software-Schätzproblemen und versteckten Abhängigkeiten führen. In diesem Leitfaden werden drei bewährte Methoden für die Teamplanung vorgestellt: Lege eine klare Arbeitsreihenfolge fest, schätze gemeinsam, um Risiken aufzudecken, und schließe den Kreislauf mit handlungsorientierten Rückblicken, damit die Abstimmung und Zusammenarbeit im Team verbessert wird und die Pläne Bestand haben.

---

Die Sprintplanung sollte sich nicht wie ein Geschrei anfühlen, bei dem die lauteste Stimme gewinnt. Für viele Teams ist es jedoch ein langes Meeting geworden, das Energie verbraucht, einen schwachen Plan erstellt und am Mittwoch auseinanderfällt.

Das Problem ist nicht, dass Ihr Team vergessen hat, wie man plant. Die Welt rund um den Plan hat sich geändert. Die Leute arbeiten in verschiedenen Zeitzonen. In Kommentaren und Tickets werden mehr Entscheidungen getroffen als in Räumen. Und der Plan steckt in Tools, die andere Leute (und die KI-gestützte Suche) später lesen werden. Wenn das Publikum von „Wer war an der Besprechung“ zu „jedem, der die Arbeit berührt“ wechselt, muss der Plan klarer und besser organisiert sein.

Einerseits KI und asynchrone Zusammenarbeit sind auf dem Vormarsch. Auf der anderen Seite haben wir eine direkter Link zwischen starken Lieferfähigkeiten und besserer Leistung. Und diese beiden Linien treffen bei der Planung aufeinander — wenn die Eingaben unklar sind, macht man einfach schneller die falschen Dinge.

Wir glauben, dass sich die Planung schwieriger anfühlt, weil drei grundlegende Elemente zusammengebrochen sind:

• Wie aus Prioritäten eine Arbeitsreihenfolge wird,
• wie Schätzungen das Risiko anzeigen (nicht nur Zahlen), und
• Wie aus Verbesserungsvorschlägen echte Arbeit wird.

Wenn diese schwach sind, wird Planung zu einer Übung zur Bewältigung der Metallüberflutung, anstatt einen klaren Weg in die Zukunft zu finden.

In diesem Artikel wird untersucht, warum die Sprint-Planung so schwierig geworden ist, was sich 2025 geändert hat, um es noch schlimmer zu machen, und vor allem, wie Teams diese drei Grundlagen korrigieren können, sodass Ihr Plan immer noch Sinn macht, wenn jemand, der das Meeting verpasst hat, ihn zwei Tage später liest.

Die mentale Belastung moderner Planung

„Kognitive Belastung“ ist einfach die Menge an geistiger Anstrengung, die eine Person gleichzeitig bewältigen kann. Jedes Team hat ein Limit, wie viele Informationen es zu einem bestimmten Zeitpunkt speichern kann, und die Planung von Besprechungen geht jetzt weit darüber hinaus.

Gleichzeitig werden die Teams gebeten:

• Rangieren Sie Funktionen gegen unklare Ziele,
• Schätzen Sie die Arbeit, die sie noch nicht vollständig erforscht haben,
• Stelle dich mit Plattformteams zusammen, deren Zeit ungewiss ist,
• Balancieren Sie die Anforderungen verschiedener Interessengruppen,
• Finden Sie Abhängigkeiten zwischen Systemen heraus, die sie nicht kontrollieren, und
• Versprich Termine, die andere genau verfolgen werden.

Oft werden Pläne so gemacht, als ob alle voll verfügbar sind und nicht auch an bestehenden Projekten und Aufgaben arbeiten. Und wir alle wissen ganz genau, dass das niemals der Fall ist. Wenn die mentale Belastung zu hoch ist, können Teams die Software, an der sie arbeiten, nicht sicher besitzen oder ändern.

Die Planung wird dann zu einem Engpass, bei dem Teams mehr Zeit damit verbringen, die Komplexität der Koordination zu bewältigen als mit der eigentlichen Koordination. Entscheidungen scheitern, Annahmen werden nicht überprüft, und der Plan, der herauskommt, ist kein geteiltes Verständnis aber ein schwacher Kompromiss, der niemanden zufrieden stellt.

Wo Prioritäten scheitern

In den meisten Planungssitzungen hat „Priorität“ an Bedeutung verloren. Alles ist P0. Alles ist dringend. Alles muss in diesem Sprint passieren. Wenn alles oberste Priorität hat, ist es nichts.

Teams haben Schwierigkeiten, Prioritäten zu setzen, weil es zu viele bewegliche Teile gleichzeitig gibt: viele Beteiligte, lange Rückstände und Prioritäten, die sich von Woche zu Woche ändern. Die meisten Priorisierungsmethoden wie MoSCoW, WSJF und RICE funktionieren für eine kleine Liste und eine kleine Gruppe, aber sie funktionieren nicht mehr, wenn die Liste und das Publikum groß werden. Besprechungen werden länger, Ergebnisse werden inkonsistent, und jedes Mal, wenn sich etwas ändert, alles neu zu ordnen, ist nicht praktikabel. Die Leute lernen auch, die Zahlen zu „spielen“, um ihren Artikel nach oben zu bringen.

Es gibt ein zweites Problem: Diese Methoden gehen davon aus, dass sich alle darüber einig sind, was „Wert“ bedeutet. In Wirklichkeit wollen Vertrieb, Compliance, Plattform, Design und Support oft unterschiedliche Dinge. Numerische Modelle (wie einfache Bewertungen) lassen diese Unterschiede außer Acht, weil einige Kompromisse (wie Markenrisiko, Kundenvertrauen, regulatorische Fristen) leichter zu erörtern sind, als sie in einer einzigen Zahl zusammenzufassen.

EIN flacher Produktbestand macht das noch schlimmer. Wie Jeff Patton sagt, ist das Lesen eines Backlogs als eine lange Liste so, als würde man versuchen, ein Buch zu verstehen, indem man eine Liste von Sätzen in zufälliger Reihenfolge liest — der gesamte Inhalt ist da, aber die Geschichte ist weg. Ohne die Geschichte wird „Priorität“ zu einem Etikett, das die Leute verwenden, um Argumente für sich zu gewinnen, und nicht für eine klare Reihenfolge der Arbeit.

Einfach ausgedrückt, wenn die Arbeit und die Anzahl der Stimmen zunehmen, können die üblichen Techniken nicht mehr mithalten. Wenn Sie nicht in der Lage sind, unterschiedliche Sichtweisen aufzuzeigen und Kompromisse zu vereinbaren, weichen Entscheidungen von der Strategie ab, Pläne ändern sich ständig, weil sie nie an Ergebnisse gebunden waren, und Ingenieure verstehen nicht mehr, warum ihre Arbeit wichtig ist.

Die Schätzung zeigt

Teams sind in der Regel zu optimistisch über Aufwand und zu viel Vertrauen in ihre Schätzzahlen. Im Durchschnitt dauert die Arbeit etwa 30% länger als erwartet. Selbst wenn die Leute angeben, dass sie zu 90% sicher sind, dass ein Bereich den tatsächlichen Aufwand abdeckt, ist dies nur in 60— 70% der Fälle der Fall.

Übersetzung: Selbstvertrauen fühlt sich gut an, bedeutet aber nicht Genauigkeit.

Die tiefere Frage ist, wie wir schätzen. Es wird oft allein geraten, anstatt gemeinsam das Risiko zu überprüfen.

Folgendes passiert tatsächlich: Jemand sieht ein Arbeitselement namens „API aktualisieren“, gibt ihm 5 Punkte allein aufgrund des Titels und das Team macht weiter. Niemand testet die Annahmen, die hinter der Zahl stehen.

Niemand spricht über die Änderungen der Authentifizierungsebene, die durch „Update“ impliziert werden. Niemand spricht die Datenbankmigration an, die sich vor aller Augen versteckt. Niemand überprüft, ob das Frontend-Team weiß, dass diese Änderung bevorsteht.

Und wenn diese mitten im Sprint auftauchen, scheitert der Plan und das Vertrauen sinkt.

Nach ein paar Fehlschüssen verschlechtert sich das Verhalten. Die Leute beginnen, ihre Schätzungen aufzufüllen und runden die Zahlen leise auf um sich sicher zu fühlen. Das Produkt beginnt dann, sich zurückzudrängen. Und aus Schätzung wird Verhandlung, nicht Lernen.

Ein gesünderes Signal zum Anschauen ist das Streuung der Schätzungen. ‍Eine große Streuung von Schätzungen ist kein Problem, das es zu glätten gilt, sondern eher ein Signal zur Diskussion von Annahmen. Höchstwahrscheinlich wird es einen gewissen Unterschied zwischen den ursprünglichen Schätzungen geben, sodass jedes Teammitglied eine großartige Gelegenheit hat, darüber zu sprechen, warum seine Schätzungen entweder höher oder niedriger als die anderen waren.

Die Koordinationskosten von Abhängigkeiten

Wenn verschiedene Teams verbundene Teile des Systems besitzen, kann die Arbeit eines Teams oft erst dann voranschreiten, wenn ein anderes Team eine Änderung vornimmt. Wenn diese Teams nicht in einer Reihe stehen, bleibt die Änderung hängen.

Dies ist häufig der Fall, wenn die Art und Weise, wie die Software verkabelt ist, nicht mit der Organisation der Teams übereinstimmt.

Im Code steht beispielsweise „Service A muss sich vor Service B ändern“, aber A und B leben in unterschiedlichen Teams mit unterschiedlichen Prioritäten, Sprint-Terminen und Aufnahmeregeln. Der Code erfordert Koordination, aber das Organigramm sieht sie nicht vor.

In großen Organisationen sind diese kleinen Links auf Arbeitselementebene ein ständige Quelle der Verzögerung. Und in letzter Zeit ist es nur noch schlimmer geworden.

Das Plattform-Engineering ist gewachsen, und die meisten Funktionen betreffen jetzt gemeinsame Dienste — Authentifizierung, Datenplattformen, CI/CD, Komponentenbibliotheken. Die Planung erfolgt jedoch oft, ohne dass das Plattformteam im Raum anwesend ist. Niemand überprüft ihre Kapazität, niemand testet die Reihenfolge der Arbeiten, und es gibt keine Einigung über Aufnahmefenster oder darüber, was zu tun ist, wenn etwas blockiert ist.

Auf dem Papier sieht der Plan also fertig aus. Geschichten sind groß. Der Sprint ist abgeschlossen. Dann, nach drei Tagen, sagt jemand im Stand-up: „Diese API wird erst nächsten Dienstag fertig sein“, oder „Das Plattformteam ist überfordert“ oder „Das Bereitstellungsfenster am Freitag ist nicht verfügbar“. Die Arbeit wartet, die Leute warten und Geld brennt, während nichts vorankommt.

Abhängigkeiten erhöhen Sie die Komplexität in jedem System. Höhere Komplexität bedeutet mehr Leerlaufzeiten, wenn die Arbeit zwischen Personen oder Teams ausgetauscht wird. Entwickler warten also oft darauf, dass andere Arbeiten abgeschlossen sind, bevor sie beginnen können, was zu Ineffizienzen führt, die keinen Mehrwert bringen, aber dennoch Lohn- und Budgetkosten kosten.

Was hat sich 2025 geändert

Drei Schichten im Jahr 2025 erschwerten die Planung noch weiter:

1. Verteilte Arbeit reduzierte die Live-Koordination.

Hybride Tage ersetzt jeden Tag im selben Raum zu sein. Mehr Arbeit passiert asynchron. Das bedeutet, dass Ihre schriftlichen Pläne und Notizen wie Sprintziele, Storymaps und Abhängigkeitsnotizen erklären müssen, was in Gesprächen in Echtzeit früher behandelt wurde: warum diese Arbeit wichtig ist, was zuerst kommt, was nicht passt, wer daran beteiligt ist und was Sie blockieren könnte. Vage Ziele, die persönlich festgelegt werden könnten, fallen jetzt in allen Zeitzonen auseinander.

2. Weniger Tools, ein System.

Mannschaften Anbieter kürzen um die Ausgaben zu reduzieren. Planung, Schätzung und Rückblick wurden in einer Lösung zusammengefasst, unabhängig davon, ob sie gut passten oder nicht. Das reduziert zwar die Zahl der Kontextwechsel, bedeutet aber auch, dass die Teams auf spezielle Tools und benutzerdefinierte Workflows verzichten müssten. Das bedeutet auch, dass alle Beteiligten die gesamte Bandbreite von der Strategie bis hin zu den Storys an einem Ort sehen können, sodass Ihre Sprintziele, Schätzungen und Rückblick-/Verbesserungsmaßnahmen genauer gelesen werden können.

3. Atlassian AI hat die Erwartungen geweckt.

Atlassian erweitertes Rovo in Jira und Confluence. Suche, Steuerung und Automatisierung verbinden jetzt Konversationen mit Problemen und beschleunigen die Erkennung. Und die Sache mit KI ist, dass sie jede Richtung beschleunigt, in die Sie bereits eingeschlagen haben. Wenn Ziele verschwommen sind, wenn Schätzungen Vermutungen sind und wenn Abhängigkeiten verborgen sind, hilft Ihnen die Automatisierung nur dabei, schneller in die falsche Richtung zu gehen.

Die Kombination all dieser Änderungen ist brutal: mehr Koordination erforderlich, weniger Überschneidungen bei der Abstimmung in Echtzeit und höhere Strafen, wenn Pläne scheitern, weil die Beteiligten jetzt mehr vom Gesamtbild sehen können.

Die Grundlagen schaffen: Best Practices für die Sprint-Planung

Die Teams, die für die Planung zuständig sind, haben ihre Grundlagen anhand von drei bewährten Planungsmethoden neu aufgebaut. Es sind einfache, geschriebene Regeln, die das gesamte Team befolgt. Sie sind von der Planungstafel und den Arbeitsaufgaben abhängig, sodass sie auch nach Übergaben und über Zeitzonen hinweg immer noch Sinn machen.

1. Setzen Sie Prioritäten in eine klare Arbeitsreihenfolge um

Die „Priorität“ wird unterbrochen, wenn Menschen nicht dieselbe Wertvorstellung teilen. Die Lösung besteht darin, sich auf eine einzige, sichtbare Reihenfolge zu einigen — warum zuerst diese, dann die und was passt nicht in diesen Sprint.

Teams, die das richtig machen:

• Verwandeln Sie Ziele und Ergebnisse in Backlog-Arbeit in einem gleichmäßigen Rhythmus, nicht ad hoc.

Einmal im Monat bestätigen Produkt und Lieferung die Ziele und teilen sie für die nächsten 6—8 Wochen in epische und kleine Abschnitte auf. Auf diese Weise bleibt sinnvolle Arbeit in der Pipeline, ohne die Annahmen und Wünsche, die sich ohnehin ändern werden, zu überfordern.

• ‍Schreiben Sie testbare Sprintziele mithilfe einer konsistenten Vorlage.

Ziel, Test, Einschränkung. Legen Sie klar definierte Ziele, Vorgaben und Kennzahlen fest. Was ist die Definition von erledigt? Woher weiß das Team, ob es erfolgreich ist? Du solltest das verlassen Besprechung zur Sprint-Planung mit einer klaren Vorstellung davon, was getan werden muss und wie Erfolg aussieht. Zum Beispiel ist „Benutzer können den Checkout mit gespeicherten Zahlungsmethoden abschließen, ohne die Kartendaten erneut eingeben zu müssen“ viel besser als „Verbessern Sie die Checkout-UX jedes Mal“. Wenn du nicht verifizieren kannst, ob du es erreicht hast, ist das ein Wunsch, kein Ziel.

• ‍Führen Sie eine 30-minütige Überprüfung durch, bevor Sie etwas planen.

Vereinbaren Sie die Reihenfolge der Arbeiten, bevor Sie die Termine festlegen. In 30 Minuten mit den Konstruktions-, Design- und Plattformteams: Gehen Sie die Liste der Abhängigkeiten durch, überprüfen Sie die Kapazität und identifizieren Sie die wichtigsten Risiken. Ergebnis: geordneter Pfad zum Erledigen, klare Abgrenzung dessen, was nicht in diesen Sprint passt, und eine einfache Regel für den Umgang mit blockierten Elementen. Dadurch kommen teamübergreifende Spannungen zum Vorschein, bevor es mitten im Sprint zu einer Krise kommt.

• ‍Machen Sie Abhängigkeiten dort sichtbar, wo Menschen tatsächlich planen.

Verwende ein Standardabhängigkeitsfeld und zwei bis drei Linktypen in Jira. Überprüfe die Links mit dem höchsten Risiko während der Planung — nicht, wenn sie am dritten Tag die Arbeit blockieren.

Einfache Agile TeamRhythms Story-Maps von Benutzern macht diesen Prozess konkret — Lege Ziele und Ergebnisse an oberster Stelle fest, Arbeitselemente, die mit diesen Zielen in Verbindung stehen, und sprinte oder versioniere Swimlanes, um sie klar zu gruppieren. Aktiviere Abhängigkeitslinien, damit Hindernisse und teamübergreifende Verbindungen in der Planung auftauchen. Wenn Epen zu Ergebnissen führen, wenn sich die Reihenfolge der Arbeit von selbst erklärt und wenn Abhängigkeiten auf derselben Tafel sichtbar sind, hören Sie auf, Prioritäten zu überdenken und beginnen mit der Umsetzung.

2. Schätzen Sie gemeinsam ab, um Risiken frühzeitig zu erkennen

Bei der Schätzung geht es nicht darum, eine perfekte Zahl zu erreichen. Es ist eine schnelle Methode, um Risiken zu identifizieren, während Sie den Umfang oder die Reihenfolge noch ändern können. Behandeln Sie es wie ein kurzes, zielgerichtetes Gespräch, das verborgene Annahmen sichtbar macht und aufzeichnet, was Sie gelernt haben.

• ‍Schätzen Sie zusammen, leben Sie.‍

Lauf Poker planen aus der Jira-Problemansicht, sodass jeder den gleichen Titel, die gleiche Beschreibung, die gleichen Akzeptanzkriterien, Designs und Anlagen sieht. Halte die ersten Stimmen versteckt und zeige sie alle zusammen an (damit die erste Zahl den Rest nicht beeinflusst).

Easy Agile TeamRhythm hilft Ihnen beim Ausführen des Einschätzung Prozess in Jira, genau dort, wo die Arbeit stattfindet. Erfassen Sie die wichtigsten Punkte der Diskussion in den Kommentaren in der Themenansicht. Synchronisiere die endgültige Schätzung wieder mit Jira, sodass dein Plan auf der aktuellen Realität basiert und nicht auf alten Schätzungen von vor zwei Wochen.

• ‍Notieren Sie die Argumentation, nicht nur die Zahl.‍

Wenn sich eine Geschichte von einem bewegt 3 zu einem 8 fügen Sie nach der Diskussion zwei kurze Anmerkungen zum Arbeitselement hinzu:‍

- Was hat sich geändert in der Konversation (die Annahme, die Sie aufgedeckt haben), und‍

- Was ist noch unbekannt (das Risiko, dem Sie ausgesetzt sind)

Das hilft der nächsten Person, die es aufgreift, und verhindert, dass Sie dieselbe Debatte später wiederholen.

• Halten Sie sich an klare, einfache Skalen.

Die Zeitschätzungen variieren stark von Person zu Person. Story Points helfen Teams stattdessen dabei, sich auf den Aufwand zu einigen. Wenn Sie jedes Teammitglied bitten, den Zeitaufwand für eine Aufgabe abzuschätzen, erhalten Sie wahrscheinlich mehr als 5 verschiedene Antworten. Das Timing hängt von Erfahrung und Verständnis ab. Die meisten Teammitglieder sind sich jedoch einig, wie viel Aufwand für die Erledigung eines Arbeitselements erforderlich ist. Das bedeutet, dass Sie einen Konsens erzielen und viel schneller mit Ihrem Story-Mapping oder Ihrer Sprint-Planung fortfahren können.

Pflegen Sie einen kleinen Satz aktueller Arbeitselemente (einfach/mittel/schwer) mit Schätzungen und Istwerten. Wenn die Diskussionen nicht zu Ende zu gehen scheinen, verweisen Sie auf diese bekannte Arbeit: „Das sieht aus wie der Auth-Refactor vom Juni — das war eine 8 und hat sechs Tage gedauert, einschließlich des Migrationsskripts.“

• ‍Beschränken Sie die festgelegte Arbeit auf etwa 80-85% der durchschnittlichen Kapazität.

Der Raum bietet Platz für einen Verbesserungsgegenstand, für unvermeidliche Unterbrechungen und für die Realität. Wenn Sie sich unerreichbare Ziele setzen, ist Ihr gesamtes Team zum Scheitern verurteilt. Wenn Sie Ihre Sprintziele Sprint für Sprint nicht erreichen, schadet dies der Motivation und Moral des Teams. Verwenden Sie Schätzungen, um so gut wie möglich vernünftige Ziele zu setzen. Berücksichtigen Sie die Teamkapazität auf der Grundlage Ihrer bisherigen Erkenntnisse darüber, wie lange die Erledigung von Aufgaben dauert, wie das Team arbeitet und welche Hindernisse sich dabei ergeben könnten.

Schützen Sie die Ehrlichkeit der geschätzten Zahlen. Eine Schätzung ist eine gemeinsame Einschätzung von Umfang und Risiko und kein Ziel, das durchgesetzt werden muss. Wenn es sich ändern muss, ändern Sie es nach einer Teambesprechung — überschreiben Sie es nicht. Denken Sie daran, was wir zuvor gesagt haben: Wenn aus einer Schätzung eine Verhandlung wird, fangen die Leute an, eine Zahl zu „übertreiben“ (leise zu übertreiben) um sich sicher zu fühlen), und die Genauigkeit wird schlechter.

3. Der Kreis der Verbesserungen wurde geschlossen

Teams tappen oft in die Falle, rückblickende Artikel als gute Absichten und nicht als klare Maßnahmen zu verfassen. Allgemeine Hinweise wie „Verbessern Sie die Kommunikation“ oder „Korrigieren Sie unseren Prozess“ klingen auf dem Papier gut, aber sie sagen niemandem, was als Nächstes zu tun ist.

‍Aktionselemente werden bei einer Retrospektive oft ignoriert. Jeder konzentriert sich darauf, die Menschen dazu zu bewegen, ihre Ideen zu verbreiten, und es wird nicht so viel Zeit mit den Aktionspunkten und dem, was als Ergebnis getan oder geändert wird, aufgewendet.

• ‍Beginne jedes Retro, indem du die Aktionen des letzten Sprints überprüfst.‍

Zehn Minuten. Haben wir sie geschlossen? Haben sie geholfen, falls geschlossen? Was haben wir gelernt? Auf diese Weise setzt das Team das Gelernte sofort um und jeder kann sehen, was sich geändert hat.

• ‍Verwandeln Sie Erkenntnisse sofort in JIRA-Arbeitselemente.‍

Jede Aktion benötigt einen Besitzer, ein Fälligkeitsdatum, einen Link zur zugehörigen Arbeit und eine klare Definition von erledigt. Wenn du sie nicht sofort zuweisen kannst, ist sie nicht umsetzbar, es handelt sich um eine Beschwerde.

Einfache Agile TeamRhythms Rückblick lebt direkt in Jira, an dein Board angeschlossen. Verwandle rückwirkende Elemente in Jira-Ausgaben mit Inhabern und Datum, verknüpfe sie mit einem epischen oder Backlog-Objekt und setze mindestens eines davon in den nächsten Sprint ein. Erfasse unvollständige Aktionspunkte und sich wiederholende Themen auf derselben Seite wie die Bearbeitung.

• ‍Machen Sie in jedem Sprint Platz für einen Verbesserungsgegenstand.‍

Wähle einen Aktionspunkt für einen Sprint aus und beende ihn, bevor du einen anderen startest, damit er nicht durch Feature-Arbeit zur Seite geschoben wird. Behandle Aktionspunkte wie ein Feature: Schätzen Sie es ein, verfolgen Sie es und schließen Sie es mit einer Notiz über das Ergebnis und die Auswirkungen ab.

• ‍Schreiben Sie eine kurze Wirkungsnotiz, wenn Sie eine Aktion abschließen.‍

Ein Retro sollte den Menschen Energie geben. Es sollte ihnen zeigen, dass wir besser werden, dass ihre Stimme wichtig ist, dass etwas besser geworden ist, weil sie etwas gesagt haben.

Schreiben Sie eine einzeilige Wirkungsnotiz für jede abgeschlossene Maßnahme, idealerweise mit einer kleinen Kennzahl — zum Beispiel „Zusammenfassen von PR-Reviews in zwei täglichen Zeitfenstern — die durchschnittliche Überprüfungszeit ist von sechs Stunden auf 90 Minuten gesunken“. Das unterrichtet das nächste Team, rechtfertigt die Investition und zeigt, dass Aktionen im Nachhinein die Fähigkeit des Teams erhöhen, Ergebnisse zu liefern, und dass es sich nicht um Verwaltungsaufwand handelt.

Was ändert sich, wenn Sie die Best Practices für die Planung befolgen

Teams mit soliden Grundlagen der Sprint-Planung sprechen selten über sie. Sie sind nicht auf der Bühne und erklären ihren Prozess. Sie liefern nur feste Arbeit, während sich alle anderen fragen, was ihr Geheimnis ist.

Es gibt kein Geheimnis. Die besten Teams haben einfach aufgehört, Planung als Besprechung zu betrachten, um zu überleben, und beginnen, sie als ein System bewährter Verfahren zu betrachten, das sich im Laufe der Zeit weiterentwickelt.

Die mentale Belastung durch die Planung von Sitzungen lässt nicht nach. Aber es verschiebt sich. Anstatt alles live in einem Raum unter Zeitdruck zu verarbeiten, haben diese Teams ihre Antworten in schriftlichen Plänen und Notizen festgehalten, die ihnen das Denken abnehmen.

Die User Story Map erklärt, worauf es ankommt und warum. Die Reihenfolge der Arbeiten zeigt Abhängigkeiten, bevor sie die Arbeit blockieren. Die Schätzwerte und Notizen erfassen nicht nur Zahlen, sondern auch die zugrunde liegenden Annahmen. Retro-Aktionspunkte stehen neben der Arbeit am Produkt, sodass der nächste Sprint von dem profitiert, was der letzte Sprint gelernt hat.

Wenn Sie die Best Practices korrigieren, werden sich Ihre Herausforderungen bei der Sprint-Planung verringern. Nicht perfekt. Nicht für immer. Aber genug, dass sich Planung nicht mehr wie eine Krise anfühlt und sich so anfühlt, wie sie sein sollte: eine ruhige Sicht auf das, was jetzt möglich ist, mit einfachen Möglichkeiten, sich anzupassen, während Sie lernen.

Die Kosten unklarer Pläne steigen. KI beschleunigt, was Sie ihr geben. Stakeholder können auf einfache Weise mehr Details einsehen. Die Arbeit findet zeitzonenübergreifend statt. In dieser Welt ist Klarheit kein nettes Extra — sie ist eine Grundvoraussetzung.

Die Teams, die 2026 gut abschneiden werden, sind nicht diejenigen mit besseren Tools oder intelligenteren Frameworks. Sie werden diejenigen sein, die ein paar einfache Best Practices in den Plan und die Arbeitsaufgaben geschrieben haben, sodass Übergaben einfach sind, andere sie überprüfen und verstehen können und sie auch nach dem Meeting Sinn machen.

Agile Schätzungstechniken sind erstaunlich einfach, können aber für Softwareentwicklungsteams manchmal komplexer als nötig gestaltet werden. Nachdem sie in den letzten Wochen eines großen Projekts den Zorn erlebt haben, bei früheren Aufträgen eine Frist zu verpassen und Angst vor 20-Stunden-Arbeitstagen zu haben, ist es kein Wunder, dass agile Teammitglieder vorsichtig mit Schätzungen umgehen. Wie oft hat Ihre Schätzung Sie schon einmal getroffen? 😱

Agile Schätztechniken wurden entwickelt, um ein nachhaltiges Entwicklungstempo zu erreichen und den Stakeholdern realistischere Terminerwartungen zu bieten. Sie verwenden relative Größenangaben, anstatt Schätzungen in Echtzeit vorherzusagen.

Zu den beliebten Schätzmethoden in einer agilen Entwicklungsumgebung gehören Story Points, Punktabstimmung, ein Bucket-System, Affinitäts-Mapping und T-Shirt-Größen. Die Größe von T-Shirts ist eine gängige Methode zur agilen Schätzung, die sich bei der langfristigen Planung als sehr effektiv erweisen kann oder Ihrem Team hilft, sich an relative Schätzungen zu gewöhnen.

Wir geben Ihnen einen kurzen Überblick über diese agilen Schätztechniken, aber dann werden wir uns mit der Größe von T-Shirts und den verschiedenen Möglichkeiten befassen, wie Sie diese Technik anwenden können.

Notieren Sie sich Ihre Schätzungen in Jira mit

Einfache Agile User Story Maps

Kostenlose Testversion

Ein kurzer Überblick über einige beliebte agile Schätztechniken

Wenn Sie diesen Artikel lesen, sind Sie wahrscheinlich bereits mit Story Points vertraut, die normalerweise für die Sprint-Planung verwendet werden, daher werden wir keine Zeit damit verbringen, diese aufzuarbeiten. Wenn Storypointing jedoch keine vertraute agile Schätztechnik ist, gehen Sie wie folgt vor ein Artikel, der Storypoints definiert und noch eine über bestimmte Zeiten, zu denen Storypoints könnte in Ihrem Team am besten funktionieren.

Die anderen agilen Schätzungstechniken, die wir uns zuerst ansehen werden, eignen sich eher für Road Mapping oder Release-Planung als für die Sprint-Planung. Lassen Sie uns einen kurzen Überblick über Affinitäts-Mapping, Bucket-Systeme und Punktabstimmung geben.

Affinitätszuordnung

In der Produktentwicklung bezieht sich „Affinität“ auf ähnliche Backlog-Elemente, entweder in Bezug auf Codetypen, Produktbereiche oder Aufwand. Bei der Abbildung von Affinitäten im Rahmen der agilen Schätzung sprechen wir von der Gruppierung von Arbeitselementen ähnlicher Größe. Geh und finde es heraus.

Um ein Affinitäts-Mapping durchzuführen, klebt der Moderator die Backlog-Elemente auf einzelne Haftnotizen und befestigt sie an einer Wand. Identifizieren Sie an einer anderen Wand eine Seite als „Kleiner“ und die andere Seite als „Größer“. Bitten Sie dann das Scrum-Team, die Elemente im Hintergrund von der Backlog-Wand auf die Größenordnung zu verschieben, in die sie passen, je nachdem, wie groß das Objekt wahrgenommen wird oder wie lange das Team voraussichtlich benötigen wird, um es fertigzustellen.

Der Schlüssel zu dieser Technik liegt darin, schnell vorzugehen, nicht zu viel darüber nachzudenken und nicht darüber zu diskutieren. Sobald alle Gegenstände an der Wand angebracht sind, können die Teammitglieder besprechen, welche Gegenstände möglicherweise falsch dimensioniert sind. Nach einer kurzen Diskussion kann das Team entscheiden, ob die Gegenstände verschoben werden sollen.

Nachdem alle mit der Platzierung zufrieden sind, kann sich der Product Owner vertikale Linien an der Wand vorstellen, die den Backlog in Abschnitte unterteilen, und jedem Artikel einfach eine T-Shirt-Größe zuweisen und ihn auf einer Roadmap platzieren.

Schaufelsysteme

Ein Bucket-System ähnelt dem Affinitäts-Mapping, außer dass es erwartet, dass Sie etwas spezifischer werden. Es verwendet die Zahlen 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100 und 200 als relative Größen, und die Teammitglieder legen alle Backlog-Elemente in einen der Buckets. Auch dies geschieht im Hintergrund, aber das Team kann am Ende alle Elemente besprechen, die ihrer Meinung nach in den falschen Eimer gelegt wurden.

Punktabstimmung

Eine weitere Möglichkeit, wie agile Entwicklungsteams Schätzungen vornehmen können, ist die Punktabstimmung. Ja, es geht wirklich darum, Punktaufkleber auf Notizkarten oder Haftnotizen zu kleben. Aber das ist eine interessante Technik, die andere Konzepte als die relative Größe beinhaltet.

Bei der Punktabstimmung erhalten die Teammitglieder fünf Punkte. Diese Punkte beziehen sich auf das, was jedes Teammitglied für die wichtigste Arbeit im Backlog hält. Die Bedeutung könnte aus technischen Gründen wie der Überarbeitung einer Datenbank zur Skalierung vor der nächsten Hauptsaison oder aus geschäftlichem Nutzen wie den am häufigsten nachgefragten neuen Funktionen aufgrund von Kundenfeedback resultieren.

Backlog-Elemente werden dann auf der Grundlage ihres Werts (der Anzahl der Punkte) zur Roadmap hinzugefügt und können dann mithilfe einer anderen Technik an den Aufwand angepasst werden.

Wie Sie sehen, sind diese agilen Schätztechniken besonders nützlich, wenn Sie einen großen Rückstand haben, bei dem Sie jedes Mal, wenn Sie versuchen, ihn zu organisieren, das Gefühl haben, Katzen zu hüten. In der Regel werden diese Schätzprozesse zu Beginn eines Projekts, bei der Erstellung wichtiger Funktionen oder bei der jährlichen oder halbjährlichen Roadmap-Planung eingesetzt.

Lassen Sie uns nun tief in die Größe von T-Shirts eintauchen.

T-Shirt-Größen für Artikel aus dem Produktrückstand

Ahhhh, die T-Shirt-Größe. XS, S, M, L, XL — wie kann das einschüchternd sein? Es ist so einfach und doch so flexibel. Die T-Shirt-Größe wird hauptsächlich für die Roadmap- und Release-Planung verwendet und ist nichts weiter als eine Schätzung des Aufwands auf der Grundlage der zum Zeitpunkt der Schätzung verfügbaren Informationen. Deshalb ist es so einfach. Das ist eine Schätzung, und das ist okay. 👌

Sie fragen sich vielleicht, warum die Größe von T-Shirts so wichtig ist, wenn es sich um eine solche ungefähre Zahl und eine relative Schätzung handelt. Es ist hilfreich für die langfristige Planung. Ja, du hast es richtig gehört. Agile Teams planen. Wenn Sie einen kurzen Blick auf die werfen Agiles Manifest, der vierte Wert agiler Entwicklungsteams lautet:

„Auf Veränderungen zu reagieren, anstatt einem Plan zu folgen.“

Ein Team kann nicht auf Veränderungen reagieren, wenn es nie von Anfang an einen Plan befolgt hat. Durch eine langfristige agile Planung wissen Sie, ob Sie den Stakeholdern realistische Erwartungen für die nächsten 6 bis 12 Monate stellen. Oder wenn sich die Bedürfnisse des Unternehmens ändern oder die vorhandenen Ressourcen nicht ausreichen und Sie ein zusätzliches Team zusammenstellen müssen. Schätzungen von T-Shirts helfen auch dabei, zu ermitteln, wie viele Iterationen in jeder Version enthalten sein müssen, um den Endbenutzern den größtmöglichen Nutzen zu bieten.

Agile Estimation beginnt mit einer T-Shirt-Größe für die Planung zukünftiger Releases, wird dann für die Sprint-Planung in Story Points aufgeteilt und kann für die Sprint-Ausführung sogar noch weiter in Stunden unterteilt werden. Unabhängig davon ist der Hauptpunkt folgender: Je näher die Arbeit der Tastatur eines Entwicklers kommt, desto kleiner und einfacher ist es, sie genau abzuschätzen. Die T-Shirt-Größe ist am weitesten von der Ausführung entfernt, daher wird nicht erwartet, dass die Schätzung perfekt ist.

Die Größe des T-Shirts ist schnell

Wenn Sie schon einmal einen Backlog mit Hunderten von Arbeitselementen geerbt haben und dann die Frage erhalten haben: „Wie lange wird es dauern, all das zu erledigen?“ du bist nicht allein. Ihr erster Versuch, die Beantwortung dieser unmöglichen Frage zu vermeiden, könnte eine gute Bereinigung des Backlogs sein. Nehmen wir an, Sie löschen ein Arbeitselement, das älter als sechs Monate ist. Ich meine, hey, wenn es schon so lange im Produkt-Backlog ist, ist es vielleicht nicht wirklich so wichtig.

Aber wenn Sie einem Team beigetreten sind, das gerade erst mit agilen Methoden angefangen hat, werden Sie wahrscheinlich mit einem großen Rückstand feststecken und Produktmanager erwarten eine altmodische Schätzung.

Die Größe von T-Shirts ist hier praktisch. Da bekannt ist, dass Sie Schätzungen aus dem Bauch heraus abgeben, kann Ihr Team einen riesigen Rückstand im Handumdrehen bewältigen. Beschränken Sie die Entscheidungsfindung auf 30 Sekunden pro Artikel, um sicherzustellen, dass die Teammitglieder bei Übungen zur Größe von T-Shirts nicht zu viel über jeden Artikel nachdenken.

Das Ergebnis ist ein einigermaßen organisierter Rückstand mit relativen Schätzungen. Der Produkteigentümer und die Interessengruppen können anhand dieser Informationen entscheiden, was kurzfristig geschehen soll.

Wie funktioniert die Größe von T-Shirts?

Abhängig von Ihrer Backlog-Größe gibt es verschiedene Möglichkeiten, wie Sie die Größe von T-Shirts angehen können. Bei einer kleinen Anzahl von Artikeln funktioniert Planungspoker hervorragend. Bitten Sie einfach Ihren Scrum Master, die Karten mit den Fibonacci-Sequenznummern gegen Buchstaben in T-Shirt-Größe auszutauschen.

Diese Technik eignet sich auch gut, wenn Sie eine Teilmenge eines umfangreicheren Backlogs schätzen müssen.

Sie sollten wahrscheinlich einen Prozess verwenden, der Affinitätszuordnungen und Bucket-Systemen für große Backlogs ähnelt. Jeder arbeitet unabhängig daran, die Größe zuzuweisen, und am Ende bespricht er dann Konflikte. Diese Technik ermöglicht es auch kleinen Teams, einen großen Backlog relativ schnell zu überwinden.

Schließlich möchten einige neue agile Teams vielleicht ihre Schätzungsreise beginnen, indem sie T-Shirt-Größen für User Stories und die Sprint-Planung verwenden. Mike Cohn, einer der Gründer der Scrum Alliance und ein Experte für agile Prozesse, schlägt vor dass Teams, die sich für diesen Ansatz entscheiden, jeder T-Shirt-Größe einen Story-Point-Wert zuweisen. Diese Technik hilft den Teams, sich mit den Storypoints vertraut zu machen, die innerhalb des Sicherheitsnetzes bei der Schätzung der T-Shirt-Größe liegen.

Übung macht den Meister mit agilen Schätztechniken

Unabhängig von der Art des agilen Projekts, an dem Sie arbeiten oder für welchen Schätzprozess Sie sich entscheiden, je mehr Sie üben, desto schneller wird Ihr Team zu Meisterschätzern. 👑 Wir empfehlen, ein paar verschiedene Methoden auszuprobieren, um herauszufinden, welche für Ihr Team am besten geeignet ist.

Eine letzte Sache: Denken Sie daran, dass Story-Point-Schätzungen am besten für die Sprint-Planung geeignet sind. Affinitäts-Mapping, Bucket-Systeme, Punktplanung und T-Shirt-Größe eignen sich besser für die Roadmap- und Release-Planung.

Wenn du Hilfe brauchst, um deine Planung von der Wand auf Jira zu übertragen, solltest du es versuchen

Einfache agile Roadmaps

Vergessen Sie nicht, sich unsere anzusehen weitere Blogartikel um Ihrem Team auf seiner agilen Reise zu helfen.

Das siebte Prinzip des Manifests für agile Softwareentwicklung lautet:
Funktionierende Software ist das wichtigste Maß für den Fortschritt.
Keine Storypoints, keine Geschwindigkeit, keine Schätzungen: funktionierende Software.

Jason Godesky, Bessere Programmierung

Schätzungen sind eine häufige Herausforderung für agile Softwareentwicklungsteams. Die erwartete Größe und Komplexität einer Aufgabe ist alles andere als objektiv; was für eine Person einfach ist, ist es für eine andere möglicherweise nicht. Story Points sind zur wichtigsten Kennzahl geworden, um den Aufwand abzuschätzen, der mit der Erledigung einer Aufgabe verbunden ist, und werden häufig zur Leistungsmessung verwendet. Aber hat das einen echten Wert und welche Risiken bestehen, wenn man sich zu sehr auf die Geschwindigkeit als Richtwert verlässt?

Agile Schätzung

Als Menschen sind wir im Allgemeinen schlecht darin, große Dinge in Einheiten wie Zeit, Entfernung oder in diesem Fall Komplexität genau zu messen. Wir sind jedoch hervorragend darin, relative Vergleiche anzustellen — wir können feststellen, ob etwas größer, kleiner oder genauso groß ist wie etwas anderes. Hier kommen Story Points ins Spiel. Story Points sind eine Möglichkeit, den relativen Aufwand für eine Aufgabe abzuschätzen. Sie sind nicht objektiv und können je nach Erfahrung des Teams und gemeinsamen Referenzpunkten schwanken. Je länger ein Team jedoch zusammenarbeitet, desto effektiver werden sie in Bezug auf die relative Größe.

Die Teams, die ich coache, hatten alle Probleme mit der Schätzung von Nutzergeschichten. Die historischen Daten zeigen uns, dass, sobald eine Story 5 Storypoints überschreitet, die Variabilität bei der Bereitstellung zunimmt. In der Regel gilt: Je mehr die Schätzung 5 Punkte überschreitet, desto stärker weicht die Darstellung von der Schätzung ab.

Robin D Bailey, Agiler Coach, GoSourcing

Referenzskala

Story Points sind zwar als Abstraktion für Planung und Schätzung nützlich, sollten aber nicht überanalysiert werden. In einem neu gebildeten Team werden die Storypoints wahrscheinlich stark schwanken, aber in einem Team, das schon viele Releases zusammen fertiggestellt hat, kann man mehr Vertrauen in die Zuverlässigkeit von Schätzungen haben. Zwei verschiedene Teams werden jedoch unterschiedliche Referenzskalen haben.

Auf Unternehmensebene bestand der wichtigste Wert, nach dem ich bei Story Points gesucht habe, darin, alle systemischen Probleme zu verstehen. Damals zum Beispiel, als Atlassian vierteljährlich auf Server veröffentlichte, gingen die Sprints vor einer Veröffentlichung schnell über die Bühne und verfehlten den üblichen Grad der Fertigstellung von Storypoints. Es stellte sich heraus, dass die Hauptursache ein massiver Anstieg kritischer Fehler war, die durch hochwertige Blitztests aufgedeckt wurden. Indem wir früher und regelmäßiger bessere Tests durchgeführt haben, haben wir die Last verteilt und auch dazu beigetragen, das Risiko der Veröffentlichungen zu verringern. Rückblickend klingt das einfach, aber es waren neue Erkenntnisse für unsere Teams zu der Zeit, die aufgedeckt werden mussten.

Mat Lawrence, COO, Easy Agile

Selbst bei gut etablierten Teams kann die Geschwindigkeit durch Faktoren wie erhöhte Komplexität bei gemeinsam geplanten Abhängigkeiten oder auch nur durch die durchschnittliche Anzahl von Story Points pro Ticket beeinflusst werden. Wenn ein Team viele Tickets mit geringer Komplexität geplant hat, reicht sein Prozess möglicherweise nicht für den erforderlichen Durchsatz aus. Wenn andere Teammitglieder weniger Tickets mit hoher Komplexität haben, könnte dies den Aufwand, den andere Teammitglieder zur Überprüfung der Arbeit benötigen, drastisch erhöhen. Beide Situationen könnten sich auf die Geschwindigkeit auswirken, aber beide stellen Engpässe dar.

Jede gemessene Änderung der Geschwindigkeit könnte auf eine Reihe anderer Faktoren zurückzuführen sein, z. B. auf Kapazitätsverschiebungen aufgrund von Änderungen der Mitarbeiterzahl, bei denen Teammitglieder aufgrund von Krankheit oder geplantem Urlaub abwesend sind. Die Realität ist, dass die Umgebung selten steril und kontrolliert ist.

Relative Geschwindigkeit

Viele Unternehmen fühlen sich vielleicht versucht, über Storypoints zu berichten, und Velocity-Berichte sind in Jira leicht verfügbar. Dennoch sollten sie mit Vorsicht betrachtet werden, wenn sie in einem „Team von Teams“ verwendet werden, z. B. in einem Agile Release Train. Aufgrund der unterschiedlichen Referenzskalen in den einzelnen Teams können Storypoints bedeutungslos werden. Was ein Team als 8-Punkte-Aufgabe ansieht, kann für ein anderes eine 3-Punkte-Aufgabe sein.

Für viele Manager bedeutet das Vorhandensein einer Schätzung, dass es einen „tatsächlichen“ Wert gibt. Dies bedeutet, dass Sie Schätzungen mit Istwerten vergleichen und sicherstellen sollten, dass Schätzungen und Istwerte übereinstimmen. Wenn sie das nicht tun, bedeutet das, dass die Mitarbeiter lernen sollten, besser abzuschätzen.

Wenn also das Vorhandensein einer Schätzung dazu führt, dass das Management den Blick von der Wertschöpfung abwendet und sich stattdessen auf die Verbesserung der Schätzungen konzentriert, lenkt es die Aufmerksamkeit vom zentralen Zweck ab, nämlich schnell einen echten Wert zu liefern.

‍Ron Jefferies
Mitautor des Manifests für agile Softwareentwicklung
Story Points überarbeitet

Ich suche Wert

Story Points sind jedoch immer noch ein wertvolles Werkzeug, wenn sie richtig eingesetzt werden. Storypoints dem Team, das sie verwendet, zu melden und Einblicke in ihre einzigartigen Trends zu geben, könnte ihnen helfen, mehr Selbstbewusstsein zu gewinnen und häufige Fallstricke zu vermeiden. Teams, die ihre Arbeitsweise verbessern möchten, möchten möglicherweise ihre Geschwindigkeit im Laufe der Zeit überwachen, während sie neue Strategien umsetzen.

Sicherlich werden Teams, die über einen längeren Zeitraum zusammenarbeiten, zu einem gemeinsamen Verständnis davon gelangen, wie sich eine 3-Story-Point-Aufgabe für sie anfühlt. Und die Diskussion und Erkundung, die erforderlich sind, um zu einem Punkt des gemeinsamen Verständnisses zu gelangen, sind wertvoll. Das Argument für 8 Storypoints im Gegensatz zu 3 kann eine Komplexität aufdecken, die bisher nicht berücksichtigt wurde, oder es kann eine neue Perspektive aufzeigen, die dazu beiträgt, die Arbeit effektiver aufzuschlüsseln. Es könnte sich auch die Frage stellen, ob es sich lohnt, die Arbeit überhaupt fortzusetzen, und deutlich machen, dass ein neuer Ansatz erforderlich ist.

Der Wert von Story Points für mich (als Entwickler und Gründer) sind die Gespräche, in denen das Thema von Menschen mit unterschiedlichen Perspektiven diskutiert wird. Velocity ist nur in langfristigen Teams mit hoher Mitarbeiterbindung relativ genau.

Dave Elkan, Co-CEO von Easy Agile

Auf Unternehmensebene können Story Points verwendet werden, um systemische Probleme zu verstehen, indem Trends im Zeitverlauf beobachtet werden. Diese Berichterstattung bietet zwar keine objektive Messgröße, kann aber Einblicke in die Fortschritte innerhalb eines Agile Release Trains geben. Der Abschluss eines Story Points als Maßstab für die Leistung von Einzelpersonen oder Teams sollte jedoch mit großer Vorsicht betrachtet werden.

Story Points sind ein nützliches Schätzinstrument, um den relativen Aufwand zu vergleichen. Sie hängen jedoch von gemeinsamen Bezugspunkten ab, und verschiedene Teams haben unterschiedliche Skalen. Selbst etablierte Teams können im Laufe der Zeit Geschwindigkeitsänderungen feststellen. Aus diesem Grund können Geschwindigkeitsberichte zwar Aufschluss über den Fortschritt des Teams geben, es darf jedoch nicht vergessen werden, dass Story Points eher zur Einschätzung des Aufwands als zur Messung konzipiert wurden. Und am Ende des Tages ist es unser Geschäft, großartige Software zu erstellen, keine großartigen Schätzungen.

Sie möchten Ihr Team auf Verbesserungen konzentrieren? Easy Agile TeamRhythm hilft dir dabei, Erkenntnisse in die Tat umzusetzen — mit Team-Retrospektiven, die mit deinem Agile-Board in Jira verknüpft sind. So kannst du deine Arbeitsweise verbessern und dein nächstes Release besser machen als das letzte. Verwandeln Sie ein Aktionselement mit nur wenigen Klicks in ein Jira-Problem und planen Sie dann die Arbeit auf der User Story Map, um sicherzustellen, dass Ihre Ideen am Ende der Retrospektive nicht verloren gehen.

Vielen Dank an Satvik Sharma, John Folder, Matthew Lawrence, David Elkan, Henry Seymour, und Robin D. Bailey dafür, dass Sie ihr Fachwissen und ihre Erfahrung in diesen Artikel eingebracht haben.