Geschwindigkeit beginnt mit der Ausrichtung
Geschwindigkeit ist eine einfache Idee, die oft missverstanden wird. Es misst, wie viel Arbeit ein Team in einem Sprint erledigt hat, und im Laufe der Zeit kann es einen Durchschnitt anzeigen, der den Teams hilft, zu planen, was für den nächsten Sprint realistisch ist. Es ist ein nützlicher Leitfaden, aber es ist kein Ziel an sich.
Manche Teams behandeln Geschwindigkeit wie ein Ziel oder einen Wettkampf (und andere werden dazu gedrängt). Sie versuchen, sie zu „erhöhen“ oder sie teamübergreifend zu vergleichen, in der Hoffnung, dass es beweist, dass sie schneller werden. Geschwindigkeit ist jedoch kein Budget, keine Prognose oder ein Geschwindigkeitsmesser. Es ist ein Spiegelbild der tatsächlichen Fortschritte, die ein Team bei der Zusammenarbeit erzielt hat, und keine Anzeigetafel für individuelle Leistungen.
Richtig eingesetzt, hilft Geschwindigkeit einem Team, seinen Lieferrhythmus zu verstehen und nachhaltige Pläne zu erstellen. Schlecht eingesetzt, kann es Druck erzeugen, zu übermäßigem Engagement ermutigen und genau die Probleme verbergen, die es eigentlich aufdecken soll.
Deshalb ist Ausrichtung wichtig. Wenn ein Team gemeinsam plant, gemeinsam Schätzungen abschätzt und sich darauf einigt, wie Erfolg aussieht, wird Geschwindigkeit eher zu einem Zeichen für stetigen Fortschritt als zu einem Wettlauf um Punkte.
Wo echter Druck ins Spiel kommt: Führung, Kennzahlen und Erwartungen
Die Teamgeschwindigkeit wird oft nicht deshalb zum Ziel, weil das Team es so will, sondern weil die Führung oder die Stakeholder auf höhere Zahlen drängen. Community-Threads und agile Kommentatoren weisen immer wieder darauf hin.
1. Metrik als Leistungsinstrument und nicht als Leitfaden
Im“Ist die Geschwindigkeitsmessung in Scrum gut oder schlecht für Ihr Team?“ Unsere Partner bei cPrime warnen vor Risiken für die Moral und Leistung des Teams, wenn Teams anhand ihrer Geschwindigkeit verglichen werden. Wenn Geschwindigkeit als Beweis für die Leistung betrachtet wird, steigt der Druck, der die Schätzungen in die Höhe treibt oder mehr Arbeit in die Höhe treibt.
2. Unrealistische Forderungen von oben
Teams spüren den Druck, wenn Führungskräfte sich Geschwindigkeitsdiagramme ansehen und fragen: „Warum können wir nicht mehr tun?“. Dadurch wird die Last eher auf das Team als auf den Planungsprozess verlagert. In der Praxis führen solche Anforderungen dazu, dass Abstriche gemacht werden, Annahmen unangefochten werden und echte Probleme verborgen werden. Schließlich Eine Erhöhung der Geschwindigkeit um 20% könnte so einfach sein wie eine Erhöhung der Schätzungen um 25%.
3. Missbrauch von Vergleichen und individueller „Geschwindigkeit“
Manche Führungskräfte wollen Teams gegeneinander antreten lassen oder einzelne Personen messen. Laut dem Agile Allianz, „nur die Gesamtgeschwindigkeit des Teams zählt, und der Ausdruck ‚individuelle Geschwindigkeit' ist bedeutungslos.“ Dieser Missbrauch führt zu Ressentiments, Spielmetriken und unterbrochener Zusammenarbeit.
4. Volatilität löst Druck aus, nicht Einsicht
Wenn die Geschwindigkeit schwankt — hoch oder runter —, reagiert die Führung oft mit Mandaten statt mit Anfragen. Doch diese Schwankungen signalisieren oft echte Probleme: unklare Geschichten, unerwartete Abhängigkeiten oder übermäßiges Engagement. Sie eher als Versager denn als Hinweise zu behandeln, verschärft die Herausforderung.
Was Alignment wirklich bedeutet
Alignment ist kein Meeting. Es ist ein gemeinsames Verständnis, das Planung, Schätzung und Umsetzung miteinander verbindet. Wenn ein Team aufeinander abgestimmt ist, haben alle das gleiche Ziel vor Augen, wissen, was nötig ist, um es zu erreichen, und erkennen, wo die Risiken liegen.
Aber wenn die Ausrichtung einfach wäre, würde eine Fehlausrichtung nicht so oft auftreten. Sie können es normalerweise erkennen, wenn sich die Planung angespannt anfühlt, wenn die Leute aneinander vorbeireden oder wenn es ganz still wird, weil sich niemand sicher fühlt, etwas zu sagen. Die Schätzungen variieren stark, oder die Schichtarbeit mitten im Sprint, weil sich das Team nie darüber einig war, was „erledigt“ bedeutet. All dies deutet auf dasselbe Problem hin: Das Team hat noch kein klares, gemeinsames Verständnis der Arbeit.
Eine echte Abstimmung findet statt, wenn Planung und Schätzung zusammen erfolgen. Die Teams besprechen, worauf es ankommt, wie komplex es ist und wie sicher sie sich fühlen. Die Produktverantwortlichen bringen den Kontext ein, Ingenieure teilen die technische Sichtweise und Designer helfen dabei, Abhängigkeiten zu erkennen. Zusammen erstellen sie einen realistischen Plan, der die Arbeit mit dem Ergebnis verbindet.
Sobald diese gemeinsame Ansicht besteht, spiegeln Schätzungen und Geschwindigkeit eher Verständnis als Vermutungen wider. Das Team kann mit mehr Selbstvertrauen planen und sich mit weniger Stress anpassen. Ausrichtung ist das, was zu echten Fortschritten führt.
Wie Alignment in der Praxis umgesetzt wird
Die Ausrichtung erfolgt nicht zufällig. Sie ist geprägt von offenen Gesprächen, gemeinsamer Sichtbarkeit und Gewohnheiten, die dafür sorgen, dass alle nach dem gleichen Plan arbeiten. Tools unterstützen dies, aber die Abstimmung hängt davon ab, wie die Leute sie gemeinsam verwenden.
1. Beginnen Sie mit der Planung anhand gemeinsamer Prioritäten
Beginne mit dem, was am wichtigsten ist. Sprintziele oder übergeordnete Initiativen helfen dabei, die Diskussion zu verankern, bevor Sie sich mit der Aufschlüsselung der Aufgaben im Detail befassen. Wenn jeder sieht, wie jede Geschichte mit einem Ergebnis zusammenhängt, bleiben Entscheidungen wertbasiert und Sie verringern die Möglichkeit, dass starke Meinungen unangemessenen Einfluss haben.
2. Schätzen Sie als Team, nicht als Einzelpersonen
Der Vorteil einer Einschätzung ergibt sich aus dem Gespräch und der Möglichkeit, Verständnis auszutauschen. Wenn die Teilnehmer ihre Sicht auf Aufwand und Komplexität teilen, können verborgene Annahmen früh zutage treten und geklärt werden. Die Planning Poker-Funktion in Teamrhythmus macht es einfach, dies in Jira auszuführen, sodass sich die Diskussion auf die Arbeit selbst konzentriert.
3. Sorgen Sie dafür, dass Ihre Prioritäten sichtbar und aktuell sind
Ziele, die nicht sichtbar sind, werden schnell vergessen, aber eine Live-Ansicht des Sprints in Jira hilft allen, zu sehen, was als Nächstes kommt, was gefährdet ist und was bereits getan wurde.
Mit Teamrhythmus, können Teams klare Ziele für jeden Sprint oder jede Iteration setzen und sehen, wie jede Story mit diesen Zielen zusammenhängt. Die Nutzerberichte sind unter den Epen zusammengefasst und zeigen auf einen Blick, wie die Arbeit gruppiert ist und wie jedes einzelne Teil zum Gesamtbild beiträgt. Die Story-Map-Ansicht sorgt dafür, dass dies für jeden sichtbar ist, ohne dass zusätzliche Administratoren hinzugefügt werden müssen.
4. Überdenken Sie die Ausrichtung häufig
Abstimmung ist nichts, was man einmal vereinbart und dann als selbstverständlich hinnimmt; es sind kleine, regelmäßige Check-ins erforderlich. Das tägliche Stand-up ist dafür ein guter Zeitpunkt. Bestätigen Sie in Stand-ups, was immer noch am wichtigsten ist, besprechen Sie alle neu aufgetretenen Abhängigkeiten und nehmen Sie schnelle Anpassungen vor, bevor sich die Dinge verlangsamen.
Wenn Sie die Ausrichtung auf diese Weise sichtbar machen, wird sie zu einem Teil Ihrer Arbeitsweise und nicht zu einer weiteren Besprechung. Der Plan bleibt gemeinsam, die Umsetzung fühlt sich stabiler an, und es ist einfacher, auf Fortschritte zu vertrauen.
Aus Abstimmung wird Zuversicht
Bei Alignment geht es darum, den Menschen die Klarheit und das Vertrauen zu geben, die sie benötigen, um selbstbewusst als Team zu arbeiten. Wenn das gesamte Team versteht, worauf es ankommt, was erreichbar ist und welchen Beitrag ihre Arbeit leistet, können sie konzentriert vorankommen, anstatt zu zögern.
Dieses gemeinsame Verständnis fördert offene Gespräche, frühzeitige Problemlösungen und Flexibilität, wenn sich Dinge ändern. Die Menschen fühlen sich wohl dabei, sich zu äußern, weil sie wissen, dass ihre Sichtweise das Ergebnis mitbestimmt. Das sind die Bausteine für stetigen Fortschritt.
Mit dieser Klarheit spiegelt die Geschwindigkeit wider, wie gut das Team zusammenarbeitet, und nicht, wie schnell es sich bewegt. Die Zahlen hören auf, Druck auszuüben, und beginnen, Belege für eine zuverlässige Umsetzung zu liefern.
Selbstbewusste Teams treffen durchdachte Entscheidungen, passen sich Veränderungen an, ohne die Richtung zu verlieren, und leisten weiterhin Arbeit, die wirklich wichtig ist. Genau das macht Alignment möglich.
Verwandte Artikel
WorkflowPlanning Poker — Anleitung zur agilen Schätztechnik
Eine der Kernfunktionen eines agilen Softwareentwicklungsteams ist die Aufwandsschätzung. Sie können einen Produkt-Backlog nicht richtig priorisieren, ohne vorher eine Vorstellung davon zu haben, wie viel Arbeit erforderlich ist, um die einzelnen User Stories fertigzustellen. Eins agile Schätztechnik plant Poker. Agile Entwicklung ist ein gemeinschaftliches Unterfangen, und Pokerplanung ist eine Übung zur Konsensbildung, bei der Ihr gesamtes Team in den Schätzungsprozess einbezogen wird.
Softwareentwicklungsteams verwenden Planungspoker, um Elementen in ihrem Produkt-Backlog Aufwand zuzuweisen (z. B. Storypoints oder ideale Tage). Manchmal auch Scrum Poker genannt, ist es eine spielerische Methode, einen Konsens zu erzielen, indem alle Mitglieder des Scrum-Teams am Schätzungsprozess teilnehmen können. Physische oder digitale Pokerkarten werden verwendet, um eine gemeinsame Planungssitzung zu ermöglichen. ♠️
Hier geben wir Ihnen eine Anleitung zur Pokerplanung. Zunächst zeigen wir Ihnen, wie man es im Rahmen eines Sprint-Planungsmeetings spielt. Zweitens werden wir uns einige seiner Vorteile als Schätzmethode ansehen. Dann werden wir sehen, warum Planungspoker bei der Planung von Produkt-Roadmaps verwendet werden kann. Es kann helfen, Ihre Stakeholder in eine einvernehmliche Abschätzungssitzung zu den Kundenthemen Ihres Produkts einzubeziehen.
Planungspoker spielen — agile Zusammenarbeit
Eine der wichtigsten Aktivitäten für agile Teams während einer Sprint-Planungssitzung ist die Schätzung des Aufwands, der erforderlich ist, um jede User Story im Sprint abzuschließen. Ein üblicher Weg, dies zu tun, besteht darin, einer einzelnen Person, wie dem Product Owner oder einem Softwareentwickler, zu erlauben, jeder User Story Story Points zuzuweisen. Alternativ können Sie Planungspoker als Schätztechnik verwenden, um das gesamte Team einzubeziehen.
Eine Pokersitzung zur Planung ist eine unterhaltsame und kollaborative Art, die Sprint-Planung spielerisch zu gestalten. Schließlich ist das Agiles Manifest unterstreicht den Wert von Zusammenarbeit und Interaktionen in Softwareentwicklung. Poker zu planen ist eine großartige Möglichkeit, sich an diese agilen Prinzipien zu halten.
Es ist also der Tag der Sprint-Planung. Wenn Ihre Teammitglieder versammelt sind, gehen Sie wie folgt vor:
- Bereiten Sie die Bühne vor. Wenn Ihr Team noch nicht mit der Pokerplanung vertraut ist, erklären Sie den Ablauf. Sie verwenden Spielkarten, um die Größe jeder User Story in der nächsten Sprint-Iteration abzuschätzen. Der Product Owner oder Scrum-Master fungiert als Moderator, alle Teammitglieder spielen mit, und während der gesamten Sitzung wird es viel Raum für Diskussionen und Fragen geben.
- Verteile die Pokerkarten. Geben Sie jedem Spieler einen identischen Satz nummerierter Karten. Wir empfehlen, die Fibonacci-Folge zu verwenden — 0, 1, 2, 3, 5, 8, 13, 21 usw. (Um zu erfahren, warum diese Sequenz so effektiv für Schätzungen ist, siehe Mike Cohn von Die Erklärung von Mountain Goat Software.) Und übrigens, wenn ihr euch nicht persönlich treffen könnt und als verteiltes Team plant, dann könnt ihr es versuchen planningpoker.com als Möglichkeit, Ihre Sitzung aus der Ferne durchzuführen. 😃
- Lesen Sie eine Benutzergeschichte. Der Moderator liest den Teammitgliedern eine Geschichte aus dem Sprint vor. Sie sollten so viele Details und den Kontext wie möglich angeben, damit das Team den Arbeitsaufwand besser einschätzen kann.
- Besprechen Sie die Geschichte als Gruppe. Lassen Sie das Team zunächst alle klärenden Fragen zu der gerade gelesenen User Story stellen. Öffnen Sie dann das Wort für Diskussionen — jedes Teammitglied kann beschreiben, was nötig ist, um die Geschichte fertig zu stellen, welche Abhängigkeiten die Arbeit blockieren und wer im Team möglicherweise in die Arbeit einbezogen werden muss.
- Spielt Karten. Jetzt ist es Zeit, das Spiel zu spielen. Jedes Teammitglied reicht eine Karte ein (verdeckt!) an den Moderator. Wenn alle Spielkarten eingereicht wurden, verrät der Moderator, was jeder einzelne schätzt. In einer idealen Welt stimmen alle Zahlen überein! Das bedeutet, dass im Team ein perfekter Konsens über den Aufwand besteht, der für dieses Sprint-Element erforderlich ist, und Sie können mit dem nächsten weitermachen.
- Diskutieren und schätzen Sie erneut. Höchstwahrscheinlich wird es einen gewissen Unterschied zwischen den ursprünglichen Schätzungen geben. Dies bietet jedem Teammitglied eine hervorragende Gelegenheit, zu belegen, warum seine Schätzungen entweder höher oder niedriger als die der anderen waren. Dann kannst du eine weitere Runde machen, in der du die Karten einreichst und aufdeckst, um zu sehen, ob es weitere Übereinstimmungen gibt. Tipp: Lass den Moderator entscheiden, wann die Runde beendet werden soll. Denken Sie daran, dass Sie nicht für jede User Story einen perfekten Story-Point-Konsens benötigen.
Du hast es geschafft! Ihr Sprint ist geplant, und das gesamte Team hat ein gemeinsames Verständnis dafür gewonnen, wie jedes Mitglied den Aufwand und die Arbeit wahrgenommen hat, die erforderlich sind, um jede User Story fertig zu stellen.
Die Vorteile von Planning Poker Agile Estimation
Als agile Schätz- und Planungstechnik hat Planungspoker seine Vorteile:
- Es fördert die Zusammenarbeit. Als funktionsübergreifendes Team ist es wichtig, dass jedes Teammitglied während des Schätzungsprozesses eine Stimme hat. Da jeder Schätzer seine Sicht auf eine Nutzerstory darlegt, versteht die Gruppe besser, wie sie zu ihrer Schlussfolgerung gekommen ist.
- Es fördert den Konsens in Ihrem gesamten Team. Bei jeder Runde des Planungspokers ist es wahrscheinlicher, dass die Schätzungen des Teams übereinstimmen.
- Es wurde nachgewiesen, dass der Wert eine genauere Methode zur Schätzung darstellt (im Vergleich zu einer einzelnen Person, die die Schätzungen vorlegt).
In einer Studie veröffentlicht von ScienceDirect, Planungspoker wurde verwendet, um die Hälfte der Arbeit eines Softwareprojekts abzuschätzen. Es gab zwei Entdeckungen. Erstens waren die Schätzungen von Planning Poker statistisch gesehen höher als die individuellen Schätzungen. Zweitens erwiesen sich die Poker-Schätzungen als genauer als die individuellen Schätzungen für dieselben Aufgaben.
Planungspoker für Roadmap-Planung
Pokerplanung ist eine unterhaltsame und effektive Methode, um eine genaue Schätzung Ihrer Artikel im Produktbestand zu erhalten. Aber warum sollten Sie es nicht auch für strategische Planungssitzungen wie die Roadmap-Planung verwenden?
In unserem definitiver Leitfaden für Produkt-Roadmaps, wir erörtern, wie sich Roadmaps auf übergeordnete, kundenorientierte Themen konzentrieren und nicht auf einzelne Funktionen. Wir heben auch hervor, dass die Entwicklung Ihrer Produkt-Roadmap ein kollaborativer Prozess sein sollte (genau wie die Sprint-Planung) und mehrere Interessengruppen einbeziehen sollte.
Gehen Sie also zurück zu den obigen Schritten. Überlegen Sie, wie Sie mithilfe von Planungs-Pokerkarten Ihre relevanten Stakeholder dazu bringen können, den relativen Umfang der einzelnen Kundenthemen in Ihrer Produkt-Roadmap abzuschätzen. Es wird Spaß machen, einen umfassenden Konsens über die Produktvision Ihres Unternehmens zu erzielen.
Gruppieren Sie Ihre Themen
Planning Poker ist eine kollaborative Methode, um das gesamte Team dazu zu bringen, den Arbeitsaufwand einer User Story abzuschätzen. Es sorgt für Konsens und ist in der Regel genauer.
Wenn du Jira für die Durchführung deiner Sprint-Planungsmeetings verwendest, hast du bereits ein Tool, das deine User Stories und dein Produkt-Backlog organisiert. Wenn du versuchst, in deinem nächsten Meeting zur Planung deiner Produkt-Roadmap Poker zu planen, gib Einfache agile Benutzer-Roadmaps für Jira ein Blick. Es bietet die Möglichkeit, Jira-Elemente in Themen zu gruppieren, die Ihre Stakeholder leicht sehen können. Viel Spaß beim Spielen!
Agile Best PracticeDas Problem mit der agilen Schätzung
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 überarbeitetIch 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.
Agile Best PracticeSechs Tipps zur Verbesserung der Teamzusammenarbeit
Dem 17. State of Agile Report zufolge waren 93% der Führungskräfte der Meinung, dass ihre Teams die gleiche Menge an Arbeit in die Hälfte der Zeit, wenn ihre Teams besser zusammenarbeiten würden.
Das ist eine ziemliche Statistik. Wir überlassen es Ihnen, zu entscheiden, ob dies auf mangelnde Effizienz aufgrund einer schlechten Zusammenarbeit oder auf eine Diskrepanz zwischen den Erwartungen der Führungskräfte und den Realitäten der Entwicklungsteams zurückzuführen ist.
Was wir wissen, ist, dass die Verbesserung der Teamzusammenarbeit Vorteile hat und dass eine verbesserte Zusammenarbeit ein wesentlicher Vorteil effektiver agiler Praktiken ist.
Wenn Sie also der Meinung sind, dass Ihr Team effektiver arbeiten könnte, finden Sie hier sechs Tipps zur Verbesserung der Teamzusammenarbeit, von denen wir glauben, dass sie Ihr Arbeitsleben verbessern und Ihnen helfen, Ihre Kunden zufrieden zu stellen.
1. Agile Teams sind funktionsübergreifend
Funktionsübergreifende Teams sind das Rückgrat agiler Zusammenarbeit. Es ist Agile 101:
Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.
Manifest für agile Softwareentwicklung
Idealerweise sollte Ihr agiles Team in der Lage sein, die Arbeit unabhängig zu erledigen. Die Fähigkeiten und das Fachwissen Ihres Teams sollten es Ihnen ermöglichen, vielfältige Aufgaben zu bewältigen, ohne Abhängigkeiten von anderen Teams aufzubauen. Sie können die Verantwortung für die Software übernehmen, die Sie bereitstellen.
Der Vorteil der Organisation in funktionsübergreifenden Teams ist ein besseres gemeinsames Verständnis Ihres Projekts, sodass jeder sehen kann, wie die einzelnen Teile zusammenpassen. Diese Art der Zusammenarbeit unterstützt den effizienten Arbeitsablauf und stellt sicher, dass Wissen und Fähigkeiten einheitlich geteilt werden.
2. Gehen Sie iterativ vor
Oder anders ausgedrückt: Machen Sie es einfacher, schnell zu scheitern, damit Ihr Team herausfinden kann, warum, und Ihren Kurs korrigieren kann. Indem Sie große Projekte in überschaubare Abschnitte unterteilen, kann sich Ihr Team darauf konzentrieren, in regelmäßigen Abständen kleine, funktionale Teile der funktionierenden Software bereitzustellen. Dieser Ansatz geht mit kontinuierlichem Feedback von Benutzern einher und stellt sicher, dass Probleme schnell aufgedeckt und genauso schnell behoben werden. Dieser gemeinsame Teamfokus auf das Feedback der Nutzer und die damit verbundene gemeinsame Zielsetzung und Zusammenarbeit sind ein wesentlicher Vorteil der agilen Entwicklung.
3. Sorgen Sie für eine regelmäßige und transparente Kommunikation
Tägliche Stand-ups, Sprint-Reviews und Planungstreffen dienen dazu, eine regelmäßige und klare Kommunikation zu fördern. Sie und Ihr Team sollten diese Treffen als Gelegenheit sehen, Ideen auszutauschen, Fortschritte und Hindernisse zu besprechen und zusammenzuarbeiten. Wenn dein tägliches Stand-up nichts weiter als eine Einkaufsliste mit Aufgaben ist, dann machst du es falsch.
Wenn dein täglicher Stand-up nichts anderes als eine Einkaufsliste mit Aufgaben ist, dann machst du es falsch.
Jemand, der zu viel Zeit mit Einkaufslistenbesprechungen verschwendet hat.
Abgesehen von Teambesprechungen ist eine klare Kommunikation überall dort wichtig, wo die Details Ihrer Arbeit geteilt werden. Agile Tools wie Einfacher agiler Teamrhythmus bieten eine zentrale Plattform für die Priorisierung von Arbeiten und die Verfolgung des Fortschritts. Mit einer zentralen Informationsquelle, auf die jeder zugreifen kann, um Ziele, Prioritäten und das Engagement des Teams zu verstehen, kann die Zusammenarbeit effektiver sein und das Team auf Kurs halten.
4. Führen Sie Team-Retrospektiven durch
Hot Take: Regelmäßige Retrospektiven sind die wichtigste agile Praxis, die Ihr Team anwenden kann.
Team-Retrospektiven bieten eine strukturierte Gelegenheit, über Ihre Arbeit nachzudenken und zu besprechen, wie sie beim nächsten Mal besser gemacht werden kann. Dies ist eine teamorientierte Verbesserung, da Sie und Ihr Team das Steuer in der Hand haben. Die Förderung ehrlicher und offener Diskussionen während der Retrospektiven hilft, Vertrauen unter den Teammitgliedern aufzubauen und fördert eine kooperative Denkweise. Indem Sie weiter an Prozessen und Verhaltensweisen arbeiten, können Sie und Ihr Team Ihre Leistung im Laufe der Zeit verbessern und Ihr Arbeitsleben verbessern.
5. Verwenden Sie Tools für die Zusammenarbeit
Die richtigen Tools können einen großen Unterschied in der Teamzusammenarbeit ausmachen. Die besten Tools bieten eine zuverlässige Informationsquelle, auf die das gesamte Team zugreifen kann, und zwar an einem Ort, an dem das gesamte Team Testament greife darauf zu. Es ist ein einfaches Konzept; ein gemeinsames Verständnis der Arbeit wird durch den gemeinsamen und freiwilligen Zugriff auf dieselben Informationen unterstützt.
Wählen Sie ein Tool, das es Ihnen und Ihrem Team erleichtert, auf Informationen zuzugreifen und sie auf dem neuesten Stand zu halten. Wenn du bereits in Jira arbeitest, eine Integration wie Einfacher agiler Teamrhythmus bietet einen besseren Überblick über Ihre Arbeit in einem Story-Map-Format, in dem Ziele und Teamengagement deutlich zum Ausdruck kommen. Team-Retrospektiven sind jedem Sprint beigefügt (oder werden nach Bedarf für Kanban-Teams erstellt), sodass du deine vom Team geleiteten Verbesserungsideen eng mit der Arbeit in Jira verknüpfen kannst.
Ganz gleich, für welches Tool Sie sich entscheiden, stellen Sie sicher, dass es eine bessere Abstimmung ermöglicht, Ihre Arbeitsabläufe optimiert und ein klares Bild von Hindernissen und Fortschritten bietet. Durch den effektiven Einsatz von Tools für die Zusammenarbeit bleibt Ihr Team organisiert, konzentriert und vernetzt, unabhängig davon, wo sich die einzelnen Mitglieder befinden.
6. Bauen Sie eine positive Teamkultur auf
Es mag offensichtlich klingen, aber eine positive Teamkultur ist für eine effektive Zusammenarbeit unerlässlich. Die Schaffung einer Umgebung, in der sich Teammitglieder geschätzt, respektiert und motiviert fühlen, fördert die psychologische Sicherheit, die sie benötigen, um ihre großartigen Ideen zu teilen, aus Fehltritten zu lernen und effektiver mit ihren Kollegen zusammenzuarbeiten.
Leistungsstarke Teams erkennen die Leistungen anderer an, geben konstruktives Feedback und unterstützen Praktiken, die zu einer gesunden Work-Life-Balance führen. Machen Sie es regelmäßig und achten Sie darauf, dass es authentisch ist. Eine positive Kultur verbessert nicht nur die Teamdynamik, sondern steigert auch die allgemeine Produktivität und Arbeitszufriedenheit.
Erfolgreiche Teamzusammenarbeit
Eine effektive Zusammenarbeit kann den Unterschied ausmachen, ob Ihr Team seine Ziele erreicht oder nicht. Indem Sie agile Methoden wie die regelmäßige Kommunikation bei agilen Planungsbesprechungen oder die Erkenntnisse aus einem interaktiven Entwicklungsansatz nutzen und mit Rückblicken Zeit für teamgeführte Verbesserungen schaffen, können Sie die Dynamik Ihres Teams erheblich steigern.
Easy Agile TeamRhythm unterstützt die Teamzusammenarbeit
Einfacher agiler Teamrhythmus wurde entwickelt, um Ihre agilen Praktiken zugänglicher und effektiver zu machen und Ihrem Team dabei zu helfen, Arbeit besser aufeinander abzustimmen und klarer zu planen, zu priorisieren und auszuführen.
TeamRhythm basiert auf einer Storymap zur Arbeitsvisualisierung und rückblickenden Boards, die teamgeführte Verbesserungen fördern. Es erleichtert die Sprint- und Release-Planung, das Abhängigkeitsmanagement, das Backlog-Management, das User Story Mapping und Retrospektiven.
Die enge Integration mit Jira macht Easy Agile TeamRhythm zu einer zuverlässigen Informationsquelle, unabhängig davon, wo Sie und Ihre Teammitglieder sich befinden.
Sehen Sie sich eine Demo an, erfahren Sie mehr über die Preisgestaltung und probieren Sie es selbst in unserer Sandbox aus. Weitere Informationen finden Sie auf der Seite mit Funktionen und Preisen von Easy Agile TeamRhythm.
Einfacher agiler Teamrhythmus