Agile Planung ist entscheidend, kann aber auch herausfordernd sein, insbesondere wenn Ihr Team noch nie relative Werte wie Story Points zur Schätzung ihrer Kapazität verwendet hat. Dadurch haben sie keine Referenzsumme von Punkten, auf die sie zurückgreifen können. Natürlich wird der Schätzprozess am Anfang schwierig sein und auch ungenaue Ergebnisse produzieren. Doch das ist nicht die einzige Herausforderung, der Sie und Ihr Team bei der Durchführung Agiler Planung gegenüberstehen.
Unser heutiges Thema konzentriert sich auf drei Aspekte der Agilen Planung. Wir werden zuerst die Agile Planung und ihre Vorteile erläutern. Dann werden wir über die Vorzüge von Story Points im Vergleich zu Stunden zur Kapazitätsplanung des Teams sprechen. Abschließend werden wir auf die Herausforderungen eingehen, denen Agile Teams gegenüberstehen, wenn sie zum ersten Mal Story Points zur Planung nutzen. Darüber hinaus werden wir im Laufe unseres Beitrags auch weitere wichtige Themen diskutieren, mit denen Ihr Team während und nach der Agilen Planungsaktivität konfrontiert sein kann.
Was ist Agile Planung?
Während der Agilen Planungsaktivität schätzt, das Agile Team den Aufwand, der notwendig ist, um die Arbeit abzuschließen, die es sich für den nächsten Sprint vorgenommen hat. Dabei kann das Team seine Kapazität mit verschiedenen absoluten oder relativen Werten ausdrücken. Eine der am häufigsten verwendeten Schätzmethoden ist der relative Wert, genannt Story Point.
Im Laufe des Prozesses schätzen die Teammitglieder jedes Element im Backlog, zu dem sie sich verpflichten, und die Summe der Punkte, die sie diesen Elementen zuweisen, wird zur Gesamtsumme der Story Points, die sie dann in den Sprint übernehmen werden. Das Ziel der Agilen Planung besteht nicht nur darin, die Kapazität des Teams zu bestimmen. Es geht auch darum, realistisch festzulegen, wie viel Arbeit das Team während des Sprints übernehmen kann, um engagiert, produktiv und effektiv zu bleiben.
In diesem Zusammenhang unterscheidet sich die Agile Planung von der klassischen Ressourcenkapazitätsplanung, bei der verfügbare Ressourcen den geplanten Aufgaben zugeordnet werden. Bei dieser Art der Planung müssen Sie auch während des gesamten Projektlebenszyklus die Fähigkeiten der Ressourcen sorgfältig planen und verwalten, um sicherzustellen, dass alle Aufgaben rechtzeitig geliefert werden.
Was ist der Unterschied zwischen Teamkapazität und Teamgeschwindigkeit?
Die Geschwindigkeit ist eine Summe von Story Points, die den Arbeitselementen zugeordnet sind, die Ihr Team im Sprint abgeschlossen hat. Der entscheidende Punkt hierbei ist, dass Sie die Geschwindigkeit in Punkten pro Sprint messen und nicht in Tagen innerhalb eines Sprints. Wenn Sie die durchschnittliche Teamgeschwindigkeit basierend auf der Arbeit (Story Points) berechnen, die Ihr Team in früheren Sprints abgeschlossen hat (3 bis 5 vergangene Iterationen), finden Sie in der Tat die Teamkapazität heraus.
In diesem Zusammenhang könnte man die Teamkapazität als den Faktor betrachten, der dabei hilft, die Anzahl von Produkt-Backlog-Elementen zu bestimmen, die Ihr Team im nächsten Sprint bei gleichbleibender Burn-Down-Rate abschließen könnte.
Darüber hinaus basiert die Schätzung der Teamkapazität auf der projizierten Verfügbarkeit des Teams für den zukünftigen Sprint. Daher ist dies ein entscheidender Faktor, um die Verfügbarkeit des Teams für kommende Sprints und die Anzahl von Backlog-Elementen, zu denen es hinsichtlich der Kapazität der Teammitglieder verpflichtet werden kann, zu verstehen.
Warum ist Agile Planung wichtig?
Die Planung in einer Agilen Umgebung mit Story Points hilft Ihrem Team, den Aufwand für die Lieferung von Arbeitsartikeln in einem Sprint besser zu verstehen und zu schätzen. Indem eine bestimmte Anzahl von Arbeitsartikeln Sprint für Sprint mit Story Points geschätzt wird, lernen die Teammitglieder ihre tatsächliche Fähigkeit, Work Items zu liefern. Im Laufe der Zeit werden sie auf ihrer Erfahrung aufbauen und ihre Aufwandschätzungen genauer durchführen.
Als Ergebnis führt die Agile Planung mit Story Points in einer unvorhersehbaren Agilen Umgebung zu einer gewissen Vorhersehbarkeit. Mit anderen Worten, Ihr Team lernt schrittweise und empirisch, wie viel es über den Verlauf einer Iteration liefern kann, was die Planung vorhersehbarer und somit effizienter macht.
Das Wissen und die Schätzgenauigkeit Ihres Teams steigen mit dem Fortschritt des Projekts
Vorhersehende vs. adaptive Planung
Ein klassischer (vorhersehbarer) Ansatz versucht, so viele Details wie möglich vorherzusehen, die das Projekt beeinflussen könnten. Bevor das Projekt startet, wird es in kleinere Teile zerlegt, deren individuelle Ergebnisse bestimmt werden. Ressourcen werden zugewiesen und ihre Kapazität innerhalb eines bestimmten Zeitrahmens geplant. Der vorhersehbare Ansatz hat sehr wenig Toleranz für unvorhergesehene Bedingungen, Situationen oder alles, was Sie nicht berücksichtigt haben, aber Ihr Projekt auf die eine oder andere Weise beeinflussen könnte. Diese Realität wird besonders offensichtlich, wenn Sie mit neuen Produkten und Dienstleistungen arbeiten.
Im Gegensatz dazu bietet der Agile (adaptive) Ansatz mehr Raum für Anpassungen und ist insgesamt nachsichtiger bei ungenauen Schätzungen. Im Agilen Ansatz sind Unter- oder Überschätzungen natürlich und die Geschwindigkeit des Teams kann von Sprint zu Sprint leicht variieren. Durch die adaptive Natur der agilen Planung kann das Ergebnis am Ende des Sprints jedoch vom ursprünglichen Planungsziel abweichen. Es gibt verschiedene Gründe dafür, die wir im weiteren Verlauf dieses Artikels genauer untersuchen werden.
Faktoren die sich auf die Agile Planung auswirken können
Bei der Planung von Aufgaben für den Sprint berücksichtigt man alle Ereignisse, die sich auf die Verfügbarkeit einzelner Teammitglieder auswirken könnten. Dies können zum Beispiel Feiertage oder persönliche Abwesenheiten sein. Auch andere persönliche oder arbeitsbedingte Verpflichtungen, die die Produktivität des Einzelnen beeinträchtigen können, sind wichtig.
Agile Planung mit Story Points vs. Stunden
Die Verwendung von relativen Werten wie Story Points, T-Shirt-Größen oder Fruchtgrößen bei der Schätzung erlaubt es dem Team, sich auf den Aufwand zu konzentrieren, der für die Umsetzung einzelner Aufgaben erforderlich ist, anstatt sich ausschließlich auf die Geschwindigkeit bei der Fertigstellung eines bestimmten Backlog-Elements zu fokussieren. Durch die Verwendung relativer Werte statt absoluter Werte wie Zeit, können auch in anderen Bereichen Vorteile erzielt werden.
Erhöht die Konzentration
Im Gegensatz zu absoluten Werten wie Zeit legen Story Points keine konkreten Fristen für die Fertigstellung von Aufgaben fest. Stattdessen konzentriert sich das Team auf den Aufwand, der für die Umsetzung der einzelnen Aufgaben erforderlich ist, unabhängig von der Zeit, die für die Fertigstellung benötigt wird. Durch die Verwendung relativer Werte können Teams ihre Schätzungen flexibler anpassen und sich auf das Erreichen der Definition of Done (DoD) für jedes Backlog-Element konzentrieren, anstatt sich nur auf Fristen zu konzentrieren. Dies kann dazu beitragen, dass das Team sich auf die Qualität der Arbeit konzentriert und den Druck, Termine einzuhalten, reduziert.
Steigert die Produktivität
Wenn für jedes Teammitglied Stunden oder Arbeitstage für ihre Kapazitätsplanung verwendet werden, kann dies ineffizient sein. Unsere Tendenz als Menschen ist es, uns auf absolute Werte, insbesondere auf Fristen, zu fixieren. Ein Beispiel: Ein Entwickler schließt eine 5-stündige Aufgabe in 2,5 Stunden ab. Was passiert als nächstes? Das Parkinson-Gesetz greift. Nach diesem Gesetz neigen Entwickler dazu, ihre Arbeit auszudehnen, um die für die Fertigstellung vorgegebene Zeit auszufüllen. Dies kann bedeuten, dass sie länger als nötig brauchen, um eine Aufgabe abzuschließen, prokrastinieren und die Aufgabe kurz vor dem Abgabetermin fertigstellen oder die verbleibende Zeit damit verbringen, das Backlog-Element zu feinabstimmen, das ansonsten bereit für die Auslieferung wäre.
In beiden Fällen kann die Produktivität einer Person stark leiden
Fördert besseres Verständnis
Der Prozess der Schätzung von User Stories mit Story Points ist Teamwork. Jede Person im Agilen Team, sei es ein Programmierer, ein UX-Designer oder ein Schriftsteller, schätzt jede Story individuell ein. Es ist sehr wahrscheinlich, dass die Anzahl der Punkte, die jedes Mitglied einer bestimmten Aufgabe zugeordnet hat, variieren wird. Eine solche Situation führt zu einer Gruppendiskussion, bei der jedes Mitglied seine Sichtweise einbringt.
Zum Beispiel hat ein Teammitglied eine Aufgabe mit 5 Punkten geschätzt, während andere sie mit 3 Punkten bewertet haben. Während die Diskussion weitergeht, bringt jemand ein Argument vor, an das niemand zuvor gedacht hat. Folglich nimmt der Wert einer Story ab oder zu, je nach gemeinsamem Verständnis der Komplexität der Story. Die Bottom Line hier ist, dass die Schätzung von Story Points jedem Teammitglied hilft, seine Kollegen besser zu verstehen und die Aufgabe, der sie sich verpflichten werden, besser zu verstehen.
Schafft eine gemeinsame Basis für jedes Teammitglied
Die Abstufung von Story Points gemäß der Fibonacci-Sequenz gibt eine bessere Vorstellung von der Unterschiedlichkeit des Aufwands, der für Aufgaben erforderlich ist. Es gibt sicherlich einen bemerkenswerten Unterschied im Aufwand zwischen den 5-Punkt- und 8-Punkt-Aufgaben. Aber wenn man sie beispielsweise für 6 Stunden schätzt und die andere Person für 8 Stunden einschätzt, ist der Unterschied nicht so klar. Eine solche Schätzung könnte auch darauf hinweisen, dass eine Person, vielleicht ein Senior, einfach schneller arbeitet als die andere Person.
Aus diesem Grund wäre es unmöglich, eine Gruppenkonsens darüber zu finden, wie lange eine bestimmte Aufgabe dauern sollte, und dann von einer anderen Person zu erwarten, dass sie in den vorgegebenen Zeitrahmen passt. Darüber hinaus wäre es nicht adäquat, wenn ein Nicht-Techniker die Zeit für einen Programmierer schätzt, um eine bestimmte Funktion zu entwickeln.
Mildert die psychische Belastung im Falle eines Fehlers
Relative Schätzungen sind auch nicht unbedingt genau, ähnlich wie absolute Schätzungen. Der Vorteil von relativen Schätzungen wie Story Points liegt jedoch darin, dass sie weniger Druck auf das Team ausüben und keine psychologischen Reaktionen auslösen, die durch enge Zeitvorgaben verursacht werden können. Wenn beispielsweise ein Entwickler an einer Aufgabe arbeitet, die auf 12 Stunden geschätzt wurde, aber aufgrund unvorhergesehener Probleme länger dauert, kann dies zu negativen Auswirkungen auf die Motivation und das Selbstvertrauen des Entwicklers führen.
Story Points hingegen beziehen sich nicht auf Zeit, sondern auf den Umfang einer Anstrengung. Eine User Story mit 5 Punkten kann 8 Stunden, vielleicht sogar 10 Stunden dauern. Oder es dauert weniger, weil die Story weniger komplex ist als Ihre Entwickler gedacht haben. Hier geht es um die Fertigstellung der Story, während die Zeit (genauso wie die Menge an Arbeit, Komplexität und Risiken) eine der Komponenten ist, die die Story Points ausmachen.
Wenn ein Beauftragter eine Story über- oder unterschätzt hat, hat dies normalerweise keine so schwerwiegenden Auswirkungen wie das Verpassen eines Termins oder das vorzeitige Abschließen einer Aufgabe. Es gibt keine starre Zeitkomponente bei der Schätzung mit Story Points, was den Druck auf den Beauftragten verringert, eine bestimmte Frist einzuhalten oder vorzeitig fertig zu werden. Daher ist die psychologische Wirkung für den Beauftragten normalerweise weniger belastend.
Wie man zum ersten Mal Agile-Planung mit Story Points durchführt
Wenn Ihr Team noch keine Erfahrung mit Story Points hat und keine Historie von Teamgeschwindigkeitswerten hat, können Sie dennoch eine Agile-Planung durchführen, indem Sie Folgendes berücksichtigen:
Beginnen Sie mit dem Bauchgefühl und der vorherigen Erfahrung
Wenn es keine verfügbaren historischen Daten gibt, auf die das Team zurückgreifen kann, ist es wichtig, dass die Teammitglieder ihre Intuition und Erfahrung nutzen, um Schätzungen abzugeben. Anfangs kann es unsicher sein, wie viele Story Points sie pro Sprint liefern können, aber das ist normal. Indem sie sich auf die Schätzungen konzentrieren und sich auf den nächsten Sprint fokussieren, können sie allmählich ein besseres Verständnis dafür entwickeln, was ihr Team leisten kann. Es ist auch wichtig, dass sie sich nicht zu viele Aufgaben auf einmal vornehmen, sondern nur so viele, wie sie realistisch bewältigen können, ohne die Qualität zu beeinträchtigen.
Berücksichtigen Sie alle Faktoren, die die Leistung Ihres Teams beeinflussen
Wenn der Sprint vorbei ist, können Sie die Story Points zusammenzählen, die Ihr Team abgeschlossen hat, und die anfängliche Geschwindigkeit berechnen. Beachten Sie, dass Ihr Team anfangs nicht alle seine Stories liefern wird. Tatsächlich wird es so wenig wie 10% der Stories liefern, die sie während der Agilen Planung geschätzt haben, oder sogar null. Ein solches Ergebnis ist für Teams, die noch nicht in einer Agilen Umgebung gearbeitet haben, vorprogrammiert.
Das Ergebnis der Iteration, bei der das Team nur 22 von den verpflichteten 60 Story Points abgeschlossen hat, kann auf zwei Arten interpretiert werden. Einerseits könnte das Team im nächsten Sprint bemüht sein, die restlichen 38 Story Points abzuschließen, um das ursprüngliche Ziel zu erreichen. Andererseits könnte es auch bedeuten, dass das Team in Bezug auf seine Kapazität und Verpflichtungen nicht realistisch eingeschätzt hat, wie viele Story Points es in einem Sprint tatsächlich abschließen kann. Daher muss das Team die Gründe für das nicht erreichte Ziel sorgfältig untersuchen und die Lernerfahrung nutzen, um in Zukunft realistischere Verpflichtungen einzugehen und seine Fähigkeiten zu verbessern.
Es ist möglich, dass das Team seine Fähigkeiten überschätzt hat, aber es gibt auch viele Faktoren, die das Ergebnis des Sprints beeinflussen können, wie beispielsweise unvorhergesehene interne oder externe Risiken oder plötzliche Krankheitsausfälle. Daher ist es wichtig, diese Faktoren bei der Bewertung der Leistung des Teams und seiner Kapazität zu berücksichtigen und zu analysieren, wie sie den Sprint beeinflusst haben.
Kontinuierliche Verbesserung und langfristige Vorhersagbarkeit aufbauen
Die anfänglichen Schätzungen zur Kapazität Ihres Agilen Teams können sehr ungenau sein. Aber was wirklich zählt, ist, dass in einer Agilen Umgebung Story Points keine festgeschriebenen Meilensteine sind, die man um jeden Preis erreichen muss. Wenn Ihr Team nicht 100% seiner deklarierten Kapazität liefert, ist das in Ordnung - solange Ihr Team Schlussfolgerungen zieht und versucht, die "lessons learned" in zukünftigen Schätzungen anzuwenden.
Letztendlich sind Schätzungen nur Vermutungen. Und obwohl die "Fehlschätzungen" ein fester Bestandteil der Agilen Planung bleiben werden, helfen sie Ihnen dabei, eine langfristige Vorhersagbarkeit aufzubauen. Auf diese Weise wird Ihr Team in der Lage sein, besser abzuschätzen, wann ein bestimmtes Feature voraussichtlich geliefert wird. Die Anzahl der Story Points, die Ihr Team geliefert hat, hilft Ihnen auch dabei, Schwachstellen im Prozess zu identifizieren, die die Leistung Ihrer Entwickler beeinträchtigen.
Planen Sie die optimale Kapazität des Teams
Das Auslasten der maximal möglichen Kapazität Ihres Agilen Teams kann sehr riskant sein. Auf der einen Seite haben Sie Story Points, die Ihr Team zu ihrer potenziellen Kapazität führen. Auf der anderen Seite gibt es das Bauchgefühl Ihrer Teammitglieder, die übermütig sein können, wenn es darum geht, die Stories zu deklarieren, die sie liefern werden.
In beiden Fällen müssen Sie Aktivitäten berücksichtigen, die nicht unbedingt mit den Stories zusammenhängen, wie zum Beispiel Meetings oder Fehlerbehebungen. Aus diesem Grund möchten Sie und Ihr Team ihre optimale Kapazität finden, die maximale Produktivität ermöglicht, ohne dass sie sich überlastet fühlen.
Agile Planung vs. Arbeitsumfang für den Sprint
Agile-Teams verpflichten sich zu einem bestimmten Arbeitsumfang, den sie planen und respektieren möchten. In der Praxis können jedoch bestimmte Umstände auftreten, die während des laufenden Sprints Änderungen an den geplanten Aufgaben erfordern. Solche Veränderungen können die Kapazität des Teams in mehreren Aspekten beeinflussen.
Story Points unterwegs hinzufügen
Um ihre Kapazität im Sprint zu optimieren, wählen Agile-Entwickler während der Planung und Schätzung des Backlogs nur wenige Aufgaben aus, die nicht ihre gesamte Kapazität für den gesamten Sprint beanspruchen. Sobald sie ihre aktuellen Aufgaben abgeschlossen haben oder kurz davorstehen, wählen sie eine weitere Aufgabe aus dem Backlog, die vom Product Owner genehmigt wurde und das Sprint-Ziel unterstützt. Auf diese Weise steigern sie allmählich ihre Geschwindigkeit, indem sie Story Points hinzufügen, wenn sie neue Aufgaben aus dem Backlog übernehmen.
Zusätzliche Aufgaben aus dem Sprint-Backlog übernehmen
Obwohl Ihr Team seine Schätzungen sorgfältig durchführt, ist es möglich, dass einige Entwickler ihre Aufgaben schneller als erwartet abschließen. In diesem Fall können sie proaktiv handeln und den Project Owner (PO) fragen, ob sie zusätzliche Aufgaben übernehmen können. Wenn der PO zustimmt, fügen sie der Sprint-Liste weitere Arbeit hinzu, die mit Story Points geschätzt wird. Auf diese Weise können sie ihre Kapazität und Geschwindigkeit erneut erhöhen.
Vertauschen einer blockierten Aufgabe mit einer anderen
Theoretisch sollten die Aufgaben im Sprint unabhängig voneinander sein und den INVEST-Kriterien entsprechen. In der Praxis ist es jedoch schwierig, eine solche Unabhängigkeit zu gewährleisten, da das Team nicht immer in der Lage ist, alle Aspekte im Zusammenhang mit einer Aufgabe vorherzusehen. Besonders schwierig wird dies bei Risiken, die wie Zeit ein wichtiger Bestandteil der Story Points sind.
Risiken (Unsicherheiten) können sich aus technischer Komplexität, Abhängigkeiten, Budget und vielen weiteren Faktoren ergeben. Einige dieser Risiken können zu Blockaden führen, die die Fertigstellung einer Aufgabe verzögern oder möglicherweise sogar für den gesamten Sprint blockieren können. In diesem Fall kann ein Entwickler seinen PO bitten, eine blockierte Aufgabe gegen eine andere auszutauschen.
Letztendlich ist der Sprint-Backlog ein lebendiger Organismus, der die anpassungsfähige Natur des Agilen Planungsprozesses unterstützen sollte.
Bearbeitung zusätzlicher Anfragen
Das Sprint-Ziel und die dazugehörigen Aufgaben sollen dem Team helfen, den Fokus während des Sprints aufrechtzuerhalten. Es passiert jedoch sehr häufig, dass ein anderer Projektbeteiligter nach Abschluss der Agilen Planung die Lieferung einer zusätzlichen "es ist nur eine kleine Aufgabe" verlangt.
In einer solchen Situation haben Entwickler und Scrum Master (SM) das Recht, die zusätzliche Aufgabe abzulehnen und die Fertigstellung bis zum nächsten Sprint zu verschieben. Da sich jedoch in der Praxis viele "kleine Aufgaben" oft als zeitaufwändiger herausstellen als ein Entwickler es sich leisten kann, sollte es die Entscheidung des PO bleiben, ob eine solche Ad-hoc-Aufgabe dem Sprint-Backlog hinzugefügt wird oder nicht.
Der PO kann auch eine zusätzliche Aufgabe genehmigen, wenn sich das Sprint-Ziel während des Sprints ändert und die neue Aufgabe das neue Ziel unterstützt. Oder der PO hat während der Agilen Planung erwähnt, dass das Team im Laufe des Sprints ein paar Ad-hoc-Aufgaben erhalten wird und dass dafür etwas Platz gelassen werden sollte.
Außerdem können zusätzliche Aufgaben, obwohl sie sich auf den Fokus des Teams auswirken, vernünftig sein und einen geschäftlichen Wert haben. Aus diesem Grund kann der PO erneut zustimmen, eine solche Aufgabe zum aktuellen Sprint-Backlog hinzuzufügen und somit die Gesamtzahl der Story Points zu erhöhen (die Geschwindigkeit des Teams zu erhöhen).
Bitte beachten Sie jedoch, dass die Ad-hoc-Aufgaben die Aufgaben, zu denen sich Ihr Team bereits verpflichtet hat, nicht gefährden sollten. Um sicherzustellen, dass Ihr Team nicht zu viel zu tun hat, könnte es am besten sein, eine der Aufgaben aus dem Sprint-Backlog zu entfernen, um Platz für eine zusätzliche Anfrage zu schaffen.
Verhandlung von User Stories
Entwickler können mit ihrem PO verhandeln, an welchen Aufgaben oder Stories sie im nächsten Sprint arbeiten werden. Obwohl ein solcher Ansatz das ursprüngliche Sprint-Ziel beeinflussen kann, können Entwickler ausgewählte Aufgaben schätzen und dann ein Ziel definieren, das alle diese Aufgaben enthält, natürlich solange das neue Ziel die Vision des PO unterstützt und den Geschäftswert des Product Backlogs widerspiegelt.
Ein solcher Ansatz hängt jedoch weitgehend vom Reifegrad des Agile-Teams ab. Wenn sie schon länger in einer Agilen Umgebung arbeiten und dasselbe Produkt entwickeln, werden die von ihnen vorgeschlagenen Aufgaben zumindest bis zu einem gewissen Punkt der Produktvision des PO entsprechen. Aber wenn Ihr Team neu oder sogar relativ neu ist, ist es besser, die Aufgaben an das Sprint-Ziel anzupassen, anstatt umgekehrt vorzugehen.
Am Ende spielt es jedoch keine große Rolle, für welche Richtung Sie und Ihr Team sich entscheiden, denn wenn Sie das Backlog gut verwalten, werden Ihre Entwickler anhand der obersten Backlog-Aufgaben erkennen, was Ihre Vision für den kommenden Sprint ist.
Agile Planung: Zusammenfassung
Im Agilen Vorgehen reflektiert die Kapazität das Leistungsvermögen des Teams, eine bestimmte Anzahl an Story Points bis zum Ende des Sprints zu liefern. Bei der Durchführung der Agilen Planung, entweder während der Sprint-Planung oder teilweise während der Refinement-Phase, muss man sich bewusst sein, dass das Team nicht immer in der Lage sein wird, die vorliegenden Stories genau zu schätzen.
Dennoch sind das Lernen und die Anpassung des Sprint-Backlogs auf dem Weg ein fester Bestandteil der Agilen Welt. Auch wenn es die endgültige Velocity des Teams beeinflussen kann, wird das Team im Laufe der Zeit auf seinen Erfahrungen aufbauen und die Agile Planung effizienter und vorhersehbarer gestalten.
Na, haben Sie auch Interesse an Agiler Planung bekommen? Wir helfen Ihnen Agile Planung umzusetzen und auf die Bedürfnisse Ihres Unternehmens anzupassen. Kontaktieren Sie uns noch heute, und vereinbaren Sie ein unverbindliches Beratungsgespräch mit einer/einem unserer Expert: innen.
Hier kommen Sie zum ursprünglichen Blogartikel: https://bigpicture.one/agile-planning/
