Das Problem mit der agilen Schätzung

Wie fühlst du dich, wenn jemand „Planung“ erwähnt? Freust du dich auf die Gelegenheit oder rennst du bei dem Gedanken, einen Plan zu schmieden, in die Berge?

Die Sprint-Planung ist ein entscheidender Teil des agilen Sprintzyklus. Sie hilft Ihnen und Ihrem Team dabei, gemeinsame Ziele zu erreichen, und bereitet Sie auf einen erfolgreichen Sprint vor. Auch wenn Planung nicht zu Ihren Stärken gehört, ist die gute Nachricht, dass Sie mit Hilfe einiger guter Ratschläge üben und im Laufe der Zeit besser werden können.

Wir haben unsere besten Tipps zur Sprint-Planung in einem ultimativen Leitfaden für agile Sprint-Planung zusammengefasst, der alles enthält, was Sie für effiziente und effektive Planungsbesprechungen benötigen.

Was ist agile Sprint-Planung?

Agile Sprintplanung ist eine wichtige Zeremonie im agilen Sprintzyklus. Sie bedeutet und bereitet das Team auf den Start des Sprints vor. Ohne diese Planung besteht das sehr reale Risiko, dass es dem Team an Fokus mangelt und es ihm nicht gelingt, sich auf das Wesentliche zu konzentrieren.

Eine effektive agile Sprint-Planung besteht aus drei Hauptteilen: einem Sprintziel, einem Verständnis der Teamkapazität und einer Reihe von priorisierten Backlog-Elementen. Jedes Element hängt vom anderen ab, um erfolgreich zu sein.

Die Idee ist, Ihr Team auf ein Ziel für den nächsten Sprint auszurichten, indem Sie sich auf eine Reihe von Backlog-Elementen einigen, die innerhalb des Sprints erreichbar sind und zum Erreichen des Sprintziels beitragen. Wenn Sie sich darauf konzentrieren und Klarheit darüber gewinnen, was Sie erreichen möchten, kann Ihr Team besser zusammenarbeiten und die Ziele erreichen.

Es ist am besten, mit einem vereinbarten Sprintziel zu beginnen. Anschließend können Sie die Arbeit an den spezifischen Backlog-Elementen priorisieren, für deren Erledigung Ihr Team in der Lage ist. Dies wird dazu beitragen, dass Ihr Sprintziel Wirklichkeit wird.

Wie die Sprint-Planung in den Scrum-Prozess passt

Wir sind große Fans des Scrum-Prozesses und er ist bei vielen Softwareentwicklungsteams sehr beliebt. Agile Sprintplanung kann zwar viele Formen annehmen innerhalb der anders agil Methodologien, für die Zwecke dieses Leitfadens konzentrieren wir uns auf die agile Sprint-Planung innerhalb des Scrum-Frameworks.

Wenn Ihr Team Scrum nicht befolgt, machen Sie sich keine Sorgen — unsere Tipps zur Vorbereitung, unser Meeting-Leitfaden, die zu vermeidenden Fehler und die Ressourcen zur Sprint-Planung sind für Sie von Nutzen.

💡 Erfahre mehr: Was ist der Unterschied zwischen Kanban und Scrum?

Scrum-Rollen: Die Menschen

In einem Scrum-Team gibt es drei Hauptrollen.

1. Inhaber des Produkts
2. Scrum Master
3. Entwicklungsteam

Der Product Owner legt die Arbeit im Voraus an. Sie helfen bei der Priorisierung der Artikel aus dem Produkt-Backlog und entscheiden, welche Elemente in den Sprint-Backlog. Diese wichtigen Entscheidungen leiten die Ziele des Sprints und bestimmen die Aufgaben, die das Team im nächsten Sprint bewältigen wird.

Das Scrum Master fungiert als Leitfaden und leitet Besprechungen, die sicherstellen, dass das Scrum-Framework während des gesamten Sprints eingehalten wird, um das Team auf Kurs zu halten. Der Scrum Master hilft dem Team, das Beste aus dem gesamten Scrum-Prozess und jeder einzelnen Scrum-Zeremonie herauszuholen.

Das Entwicklungsteam besteht aus den verschiedenen Personen, die die bei der Sprintplanung vereinbarten Arbeiten erledigen werden.

Es gibt noch andere, auf die Sie sich bei der Sprint-Planung beziehen könnten, z. B. Stakeholder, Benutzer und Kunden. Dies sind zwar technisch gesehen keine Scrum-Rollen, aber sie spielen eine entscheidende Rolle bei der Produktentwicklung. Stakeholder sollten früh und häufig in den Prozess einbezogen werden, und Kunden sollten bei Entwicklungsentscheidungen immer im Vordergrund stehen. Einige Teams halten User Personas für eine wertvolle Methode, um den Nutzerwert im Mittelpunkt zu behalten.

Artefakte: Was wird gemacht

Artefakte sind die Dinge, die erledigt werden müssen — verschiedene Aufschlüsselungen dessen, was das Team zu erreichen hofft:

1. Produktrückstand
2. Sprint-Backlog
3. Zuwächse

Artikel im Produktbacklog sind die Aufgaben, von denen das Team glaubt, dass sie sie erledigen müssen, um ein Produkt oder eine spezifische Verbesserung eines Produkts fertigzustellen. Es ist die große Masterliste mit allem, was das Team glaubt, erledigen zu müssen. Das Produkt-Backlog ist flexibel und iterativ und wird sich weiterentwickeln, wenn das Team mehr über das Produkt, das Feedback der Interessengruppen und die Kundenbedürfnisse erfährt.

Der Sprint-Backlog ist fokussierter als der Produkt-Backlog. Der Product Owner verschiebt zu Beginn jedes Sprints die wichtigsten Backlog-Elemente aus dem Produkt-Backlog in das Sprint-Backlog, basierend auf aktuellen Problemen, Prioritäten und Kundenbedürfnissen. Das Team ist bestrebt, im Laufe des Sprints alle Elemente des Sprint-Backlogs abzuschließen.

Ein Zuwachs ist ein Trittbrett aus Beton zur Erreichung des Produktziels. Eine Erhöhung muss als brauchbar verifiziert werden, um einen Mehrwert zu bieten. Das bedeutet, dass jede abgeschlossene Arbeit nicht als Teil einer Erhöhung betrachtet werden kann, es sei denn, sie entspricht der Definition von Erledigt (eine Vereinbarung zwischen dem Team darüber, was „erledigt“ bedeutet). Dabei handelt es sich um eine formale Beschreibung des Zuwachses, wenn es die für ein Produkt geltenden Qualitätsstandards erfüllt. Sobald die abgeschlossene Arbeit der vereinbarten Definition von Erledigt entspricht, erhalten Sie einen Zuschlag.

Scrum-Zeremonien: Wo Sprint Planning passt

In Scrum gibt es eine Reihe von Zeremonien, die in jedem Sprint stattfinden. Hier passt die Sprint-Planung in den Scrum-Prozess.

1. Sprint-Planung
2. Tägliches Scrum (oder Standup)
3. Sprint-Bewertung
4. Sprint-Rückblick

💡 Erfahre mehr: Agile Ceremonies: Ihr Leitfaden für die vier Stufen

Sprint-Planung ist die erste Scrum-Zeremonie — sie bereitet das Team auf den Sprint vor. In der Planungssitzung wird alles in Bewegung gesetzt und das Team darauf ausgerichtet, was für diesen Sprint am wichtigsten ist. In diesem Moment werden Entscheidungen getroffen und wichtige Backlog-Elemente aus dem Produkt-Backlog in das Sprint-Backlog verschoben.

Die zweite Zeremonie wiederholt sich an jedem Tag des Sprints. Tägliche Standups Bringen Sie das Team zusammen, um Fortschritte und Hindernisse zu besprechen, die möglicherweise im Weg stehen. Indem die Bedenken frühzeitig an die Öffentlichkeit gebracht werden, kann das Team die Frustration aufgrund von Verzögerungen vermeiden und sicherstellen, dass die Arbeit reibungslos abläuft.

Die letzten beiden Zeremonien finden am Ende des Sprints statt. Für der Sprint Review, kommt das Team zusammen, um anhand der abgeschlossenen Arbeit den Erfolg des Sprints zu ermitteln. Es ist auch eine Gelegenheit, Stakeholder einzubeziehen, um Feedback zu dem einzuholen, was bisher erreicht wurde. Das Sprint-Review stellt sicher, dass Kundeninformationen immer im Mittelpunkt stehen, die Stakeholder kontinuierlich Fortschritte verfolgen und garantiert, dass das Produkt nie zu weit von dem abweicht, wonach die Stakeholder suchen.

Das Sprint-Rückblick sammelt wichtige Einblicke von Teammitgliedern darüber, wie der Sprint verlaufen ist. Was lief gut, was lief nicht so gut und was könnte beim nächsten Mal verbessert werden? Diese wertvollen Erkenntnisse machen Scrum agil — das Team denkt immer kritisch über den Prozess nach und sucht nach Möglichkeiten, die Arbeit und die Art und Weise, wie sie zusammenarbeiten, zu verbessern.

Wir werden im Folgenden ausführlicher auf diese Zeremonien eingehen, wenn wir besprechen, was nach dem Sprint-Planungsmeeting passiert.

Die Vorteile der agilen Sprint-Planung

Agile Sprintplanung ist ein leistungsstarkes Meeting, das nicht übersehen oder unterschätzt werden sollte. Es ist eine Gelegenheit für:

• Bringen Sie das gesamte Team zusammen und orientieren Sie sich an gemeinsamen Zielen
• Stellen Sie den Kontext ein, indem Sie den Sprint mit klaren Prioritäten beginnen
• Identifizieren Sie potenzielle Hindernisse, bevor sie auftreten
• Bringen Sie das Feedback der Stakeholder in den Planungsprozess ein
• Lernen Sie aus früheren Sprints, indem Sie Sprint Review und retrospektive Einblicke in Betracht ziehen
• Berücksichtigen Sie die Teamkapazität und passen Sie sie entsprechend an, um sicherzustellen, dass die Ziele erreichbar sind und das Team im bevorstehenden Sprint nicht überfordert ist.
• Berücksichtigen und planen Sie Abhängigkeiten, die sich auf den Arbeitsablauf auswirken können.

So bereiten Sie sich auf ein Sprint-Planungstreffen vor

Wir wissen, dass wir gesagt haben, dass ein Sprint mit der Sprint-Planung beginnt, aber es gibt tatsächlich ein paar wichtige Schritte, die Sie ergreifen müssen, um sich auf die Planungssitzung vorzubereiten. Leider müssen Sie für das Planungstreffen ein wenig planen.

Verfeinerung des Backlogs

Durch die Pflege oder Verfeinerung Ihres Backlogs bleibt Ihr Backlog gesund, aktuell und bereit für die Sprint-Planung. Ein verfeinertes Backlog trägt dazu bei, dass die Planungszeit Ihres Teams effizient und effektiv genutzt wird, da Sie keine Zeit damit verschwenden müssen, dem Backlog Details hinzuzufügen, die im Voraus hätten abgeschlossen werden können, bevor alle zusammengekommen sind.

Der Produktmanager sollte das Backlog einige Tage vor dem Sprint-Planungsmeeting bereinigen, um sicherzustellen, dass es fertig ist.

Tipps zur Aufrechterhaltung eines gesunden Backlogs:

• Stellen Sie sicher, dass die Geschichten in der Reihenfolge ihrer Priorität angeordnet sind
• Priorisieren Sie Artikel, die dem Kunden den größten Mehrwert bieten
• Details zu den Backlog-Elementen mit der höchsten Priorität hinzufügen
• Teilen Sie alle User Stories auf, die zu groß sind
• Löschen Sie alle User Stories, die nicht mehr relevant sind
• Erstellen Sie neue User Stories auf der Grundlage neuer oder klarerer Bedürfnisse
• Fügen Sie Artikel hinzu, die auf dem Feedback neuer Interessengruppen basieren
• Nehmen Sie Anpassungen auf der Grundlage von Fehlerkorrekturen vor
• Weisen Sie genauere Schätzungen zu

💡 Erfahre mehr: Unverzichtbare Checkliste für eine effektive Backlog-Verfeinerung (und was zu vermeiden ist)

Sei konsistent

Eine einheitliche Besprechungszeit, die weit im Voraus geplant wird, stellt sicher, dass das gesamte Scrum-Team das Zeitfenster offen hält. Buchen Sie Ihr Sprint-Planungsmeeting bei jedem Sprint am selben Tag und zur gleichen Zeit, damit niemand es vergisst oder doppelt bucht.

Bei der Sprint-Planung handelt es sich nicht um ein Meeting, das hin- und hergeschoben, verzögert oder ignoriert werden kann — Besprechungen zur Sprint-Planung sind für den Erfolg eines jeden Sprints unerlässlich. Fragen Sie Ihr Team nach einer bestimmten, wiederkehrenden Zeit für ein Meeting und stellen Sie sicher, dass es für alle funktioniert.

So führen Sie ein Sprint-Planungsmeeting durch

Die agile Methode ist zwar flexibel und kollaborativ, aber nicht chaotisch; alles muss mit einem Plan beginnen.

1. Halten Sie sich an eine festgelegte Sitzungsdauer zur Sprint-Planung

Wie bei jeder Art von Besprechung kann das Team ohne Timebox leicht abgelenkt werden. Schließlich ist es oft einfacher, über die Arbeit zu sprechen, die erledigt werden muss, als sie tatsächlich abzuschließen. Es ist die Aufgabe des Scrum Masters, das Team auf Kurs zu halten und sicherzustellen, dass das Zeitlimit nicht überschritten wird.

Gehen Sie gut vorbereitet in das Sprint-Planungsmeeting. Eine klare Agenda und ein gut ausgearbeitetes Backlog sorgen dafür, dass Ihr Team direkt mit der Planung beginnen kann.

Legen Sie eine realistische Zeitbox für das Meeting fest und halten Sie sich daran. Wir empfehlen Ihnen, nicht mehr als 2-3 Stunden für ein Sprint-Planungs-Meeting einzuplanen, aber je besser Sie sich mit der Sprint-Planung auskennen, desto besser verstehen Sie, wie viel Zeit für Sie und Ihr Team in Frage kommt.

2. Verwenden Sie Schätzungen, um realistische Entscheidungen zu treffen

Sie möchten, dass Ihr Team so produktiv wie möglich ist, aber eine Überlastung kann die Produktivität und Konzentration tatsächlich beeinträchtigen. Unangemessene Erwartungen sind demotivierend und übermäßig engagierte Teammitglieder machen mit größerer Wahrscheinlichkeit Fehler.

Sie müssen wissen, wie viel Aufwand und Zeit erforderlich sind, um die Ziele zu erreichen, die Sie sich für jeden Sprint gesetzt haben. Agile Schätzungstechniken und Storypoints ermöglichen ein besseres Verständnis der Teamkapazität, der individuellen Kapazität und der Frage, wie eine angemessene Arbeitsbelastung aussieht. Angemessene und realistische Ziele helfen Ihrem Team, motiviert zu bleiben und einen konsistenten Arbeitsablauf zu unterstützen.

3. Definieren Sie klare Ziele und Ergebnisse

Was will das Team bis zum Ende des Sprints erreichen? Setze klar definierte Ziele und Ergebnisse, die jeder versteht. Stimmen deine Ziele mit dem überein, was du aus vergangenen Sprints gelernt hast? Stimmen sie mit den Kundenbedürfnissen überein? Sind sich alle einig, wie der nächste Sprint (ungefähr) aussehen wird?

Gehen Sie nicht davon aus, dass alle auf derselben Seite sind. Stellen Sie Fragen und ermutigen Sie Ihr Team, sich zu äußern, wenn etwas unklar ist. Es ist besser, Unstimmigkeiten oder Missverständnisse jetzt auszuräumen, als zu Beginn der Arbeit.

Um Sprintziele effektiv zu setzen, muss das SMART-Framework befolgt werden, eine anerkannte Strategie im Projektmanagement und bei der Zielsetzung in verschiedenen Branchen. Das Akronym SMART steht für:

• Spezifisch: Definieren Sie klar, was Sie erreichen möchten. Vermeiden Sie vage Ziele, indem Sie präzise Ergebnisse festlegen.
• Messbar: Legen Sie Kriterien für die Messung des Fortschritts fest. Dies hilft bei der Nachverfolgung von Erfolgen und der Identifizierung von Bereichen, in denen Anpassungen erforderlich sind.
• Erreichbar: Streben Sie Ziele an, die herausfordernd sind, aber mit den vorhandenen Ressourcen erreichbar sind. Überehrgeizige Ziele können ein Team demoralisieren, wenn sie nicht realistisch sind.
• Relevant: Stellen Sie sicher, dass jedes Ziel mit den übergeordneten Zielen des Projekts übereinstimmt. Irrelevante Aufgaben können die Energie von dem ablenken, was wirklich wichtig ist.
• Zeitgebunden: Legen Sie eine klare Frist fest, um die Dringlichkeit und den Fokus aufrechtzuerhalten. Die Sprintziele müssen mit dem begrenzten Zeitplan des Sprints übereinstimmen, um einen fristgerechten Abschluss zu gewährleisten.

In der Praxis bedeutet die Anwendung des SMART-Frameworks auf Sprintziele, dass Ihr Team synchronisiert ist und sich auf Prioritäten konzentriert, die das Projekt effizient vorantreiben. Indem Sie dafür sorgen, dass die Ziele innerhalb des Zeitrahmens des Sprints relevant und erreichbar sind, vermeiden Sie eine Fehlverteilung der Anstrengungen und stellen sicher, dass der Fortschritt den allgemeinen Projektzielen entspricht.

Veröffentlichen Sie Ihr Sprintziel an einem leicht zugänglichen Ort, damit das Team während des gesamten Sprints darauf zurückgreifen kann.

💡 Erfahre mehr: So holen Sie das Beste aus Ihren Sprintzielen heraus

4. Entscheide, was es heißt, „fertig“ zu sein

Was bedeutet „erledigt“ für ein bestimmtes Backlog-Element, eine Erhöhung, ein Produktproblem oder ein Produkt als Ganzes? Das Team und Ihre Stakeholder müssen sich darauf einigen, wie „Erledigt“ aussieht, um realistische Ziele zu setzen, die den Erwartungen aller Beteiligten entsprechen.

Wenn du dir Ziele setzt und auswählst, welche Backlog-Elemente du für den nächsten Sprint erledigen möchtest, solltest du dir darüber im Klaren sein, was es bedeutet, die Ziele, die du erreichen möchtest, zu erreichen und zu erreichen.

5. Richten Sie Sprintziele mit Produktzielen aus

Sprintziele sollten immer mit Ihren umfassenderen Produktzielen übereinstimmen. Ihr Sprint kann je nach aktuellen Produktproblemen, Bugfixes oder Kundenanliegen eine bestimmte Richtung einschlagen, aber es ist wichtig, das Gesamtbild im Auge zu behalten.

Wählen Sie Backlog-Elemente sorgfältig aus — stellen Sie sicher, dass sie sich auf das übergeordnete Produktziel beziehen und dass alle Elemente synchron funktionieren, um die Entwicklung voranzutreiben. Das Übersehen von Produktzielen in der Sprint-Planung könnte bedeuten, dass jeder Sprint eher wie eine zufällige Auswahl von To-do-Listen aussieht, die sich nicht auf die Kundenbedürfnisse beziehen, keinen Bezug zu Produktzielen haben oder Ihnen helfen, wichtige Etappen zu erreichen. Das Ergebnis wird sich wie ein Mangel an Fortschritten anfühlen, was die Gefahr birgt, dass das Team und andere wichtige Interessengruppen, wie Ihre Benutzer, aus dem Blickfeld geraten.

Was passiert als Nächstes?

Nachdem die Planung abgeschlossen ist, können Sie Ihren Plan umsetzen und die Arbeit abschließen. Das heißt aber nicht, dass die Teammitglieder losziehen und isoliert arbeiten.

Tägliches Scrum (oder Stand-up)

Das tägliches Gedränge oder Stand-up ist eine Gelegenheit für ein kollaboratives agiles Team, den Fortschritt aufrechtzuerhalten. Es sollte ein schneller Check-in zu Beginn eines jeden Tages sein.

Das Team wird besprechen, was in den letzten 24 Stunden getan wurde, auf welche Hindernisse es gestoßen sein könnte und was das Team am nächsten Tag zu erreichen hofft.

Dieses wichtige Check-In hilft dem Team, auf derselben Wellenlänge zu bleiben, trägt dazu bei, den kontinuierlichen Arbeitsfluss sicherzustellen und das Team auf Kurs zu halten, um die Sprintziele zu erreichen.

Sprint-Bewertung

Am Ende eines Sprints findet ein Sprint-Review-Meeting statt. Es ist eine Gelegenheit für das Team, alle „Erledigt“ -Probleme für diesen Zeitraum zu überprüfen. Das Sprint-Review bestimmt, ob das Ziel für den Sprint erreicht wurde oder nicht.

Es ist eine Gelegenheit, dem Team die lieferbaren, funktionstüchtigen Produktzuwächse zu demonstrieren, und auch eine Gelegenheit, Feedback von Interessenvertretern einzuholen. Dieses Feedback gibt Ihnen wertvolle Erkenntnisse, anhand derer Sie beurteilen können, ob Sie auf dem richtigen Weg sind oder im nächsten Sprint Änderungen vornehmen müssen. Das Sprint-Review ist auch eine hervorragende Vorbereitung auf die nächste Backlog-Grooming- und Sprint-Planungssitzung.

💡 Erfahre mehr: Einführung in Sprint Reviews

Sprint-Rückblick

Während im Sprint-Review untersucht wird, was erreicht wurde und wie es weitergehen soll, untersucht die Retrospektive Ihre Prozesse und die Zusammenarbeit des Teams.

Was hast du im letzten Sprint gelernt? Retrospektiven können zwar viele Formen annehmen, aber das Ziel besteht darin, herauszufinden, was gut funktioniert hat, was nicht so gut gelaufen ist und was beim nächsten Mal verbessert werden könnte. Ihr Team wird die in der Retrospektive gesammelten Erkenntnisse nutzen, um Ihre Zusammenarbeit zu verbessern und Ihren Kunden in Zukunft einen Mehrwert zu bieten.

💡 Erfahre mehr: 5 Schritte zur Durchführung effektiver Sprint-Retrospektiven

Fehler bei der agilen Sprint-Planung

Es ist leicht, in schlechte Angewohnheiten zu verfallen, besonders wenn Termine und Produkteinführung Termine nähern sich. Vermeiden Sie diese üblichen agile Planungsfehler um sicherzustellen, dass Ihr Team immer das Beste aus der agilen Methodik und dem Scrum-Prozess herausholen kann.

Unrealistische Erwartungen

Wenn Sie unerreichbare Ziele wählen, 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 und berücksichtigen Sie Ihr bisheriges Wissen darüber, wie lange die Erledigung von Aufgaben dauert, wie das Team arbeitet und welche Hindernisse sich dabei ergeben könnten.

Fehlender Kontext

Ihr Team wird von einem Verständnis dafür profitieren, wie die Probleme, an denen es arbeitet, in das Gesamtbild passen.

Je nachdem, welches Tool Sie für die Planung und Verwaltung Ihrer Arbeit verwenden, kann es schwierig sein, die kontextuellen Details zu erkennen, die für eine klare Planung und Arbeit erforderlich sind. Je mehr Elemente Sie haben, desto schwieriger und überwältigender wird es sein, sie zu organisieren und zu priorisieren. Verwenden Sie Tools, mit denen Sie Kontext, Tiefe und Kundeneinblicke mit übersichtlichen Funktionen hinzufügen können, um Ihren Plan an die Bedürfnisse Ihres Teams und Ihrer Stakeholder anzupassen.

Vernachlässigen Sie Ihren Backlog

Wir haben diesen Punkt erwähnt, als wir darüber gesprochen haben, was Sie tun müssen, um sich auf die Sprint-Planung vorzubereiten. Es lohnt sich, ihn noch einmal zu erwähnen, da es sich um einen häufigen Fehler handelt.

Wenn Sie ohne einen gut verwalteten Backlog in ein Sprint-Planungsmeeting gehen, fehlt Ihnen die Klarheit, die Sie für eine effektive Planung benötigen. Ihre Zeit ist wertvoll, ebenso wie die Zeit Ihres Teams. Sie sollte daher mit Sorgfalt behandelt und effektiv genutzt werden.

Ein gut verwaltetes Backlog ist TIEF:

• Angemessen detailliert
• Geschätzt
• Aufstrebend
• Priorisiert

💡 Erfahre mehr: Die 4 Merkmale eines guten Produkt-Backlogs

Keine Anpassung des Plans

Wenn du deinen Sprint planst, wirst du alles in deiner Macht Stehende tun, um die wichtigsten Aufgaben für die Dauer des Sprints zu priorisieren. Es ist wichtig, dass Sie versuchen, sich so gut wie möglich an den Plan zu halten, aber Sie müssen sich auch anpassen, wenn Sie neue Informationen erhalten.

Seien Sie bereit, im Handumdrehen Änderungen vorzunehmen, falls Sie auf Hindernisse stoßen oder neue Informationen über Kundenbedürfnisse, Bedenken oder Produktprobleme erhalten.

Stakeholder nicht verstehen

Sie müssen die Ziele und Prioritäten der Stakeholder verstehen, um erfolgreich zu sein. Nur weil Sie mit dem, was Sie erreicht haben, zufrieden sind, heißt das nicht, dass Ihre Stakeholder es auch tun werden.

Stellen Sie sicher, dass Ihre Stakeholder früh und häufig in Ihren Prozess einbezogen werden, und machen Sie ihnen klar, wie Sie arbeiten, um ihnen einen Mehrwert zu bieten. Holen Sie regelmäßig Feedback von Stakeholdern ein, um sicherzustellen, dass Ihre Ziele aufeinander abgestimmt sind. Ein guter Zeitpunkt dafür ist während des Sprint Reviews. Stellen Sie einfach sicher, dass diese Erkenntnisse auf Ihr nächstes Planungsgespräch übertragen werden.

Wählen Sie keine Tools mit einem kundenorientierten Ansatz

Eine erfolgreiche Produktentwicklung liefert, was der Kunde braucht und will. Um Produkte für Ihre Kunden zu entwickeln, ist es hilfreich, Tools für Planung und Arbeitsmanagement zu verwenden, mit denen Sie sie ganz einfach im Auge behalten können. Wenn Sie User Story Maps und Kundenpersönlichkeiten in Ihre Planung einbeziehen, können Sie und Ihr Team die Arbeit priorisieren, die zuerst den größten Nutzen bringt.

💡 Erfahre mehr: 10 Tipps für effektivere User Personas

Versäumnis, rückwirkende Erkenntnisse in die Planung einzubeziehen

Retrospektiven sind das Beste, was Sie tun können, um Ihrem Team zu helfen, besser zusammenzuarbeiten. Während einer Retrospektive bitten Sie Ihr Team, offen und ehrlich darüber zu sprechen, wie sich die Dinge im Laufe des Sprints entwickelt haben, damit Sie voneinander lernen können.

Wenn Sie nicht aus diesen Erkenntnissen lernen, bedeutet dies, dass die kollektive Zeit, die Sie in der Retrospektive verbracht haben, verschwendet wurde und das Feedback, das Ihr Team geteilt hat, abgewertet wird.

Wenn Sie die Erkenntnisse, die Sie aus einer Retrospektive gewinnen, in Ihre nächste Planungssitzung und in den nächsten Sprint einfließen lassen, wird Ihr Team dabei unterstützt, jedes Mal besser zu werden, sodass es mit der Arbeit zufriedener wird und bessere Ergebnisse erzielt.

Virtuelle oder persönliche Sprint-Planung

Die Vorteile der Telearbeit stellen auch die kollaborative Planung vor Herausforderungen. Ganz gleich, für welche Art sich Ihr Team entscheidet, ob virtuell, persönlich oder in einer Kombination aus beidem, es ist wichtig, dass Sie Werkzeuge wählen die den Bedürfnissen Ihres Teams entsprechen.

Tipps für die virtuelle Sprint-Planung:

• Seien Sie wirklich vorbereitet — kommunizieren Sie Ihre Pläne im Voraus klar und deutlich, sodass jeder klare Erwartungen hat.
• Verwenden Sie ein Videokonferenz-Tool, das Breakout-Sitzungen ermöglicht
• Richten Sie die interaktiven Online-Ressourcen ein, die Sie verwenden möchten, und fügen Sie Links in die Besprechungsanfrage ein.
• Online-Diskussionen beginnen nicht so natürlich wie persönlich. Teilen Sie daher die Diskussionsthemen im Voraus mit und überlegen Sie, ob Sie einige Eisbrecher vorbereiten sollten.
• Stellen Sie sicher, dass Sie Zeitunterschiede für Teams berücksichtigt haben, die sich über mehrere Zeitzonen erstrecken.
• Technische Probleme treten auf, unabhängig davon, wie weit Sie im Voraus planen und testen. Erwarte immer das Unerwartete.

Tipps für die persönliche Sprint-Planung:

• Buchen Sie einen Tagungsraum mit viel Platz für Ihr Team und ziehen Sie separate Räume für Breakout-Sitzungen in Betracht.
• Stellen Sie sicher, dass Ihr Besprechungsraum eine gemeinsame Ansicht Ihres Sprint-Plans bietet. Benötigen Sie eine Wand für Haftnotizen oder einen Bildschirm, auf dem Sie ein digitales Tool gemeinsam nutzen können?
• Wenn einige Ihrer Teammitglieder remote arbeiten, ist es schwierig, sie auf die gleiche Weise einzubeziehen. Überlegen Sie sich also, wie das für Ihr Team funktionieren könnte. Sie werden ein Whiteboard oder Haftnotizen nicht so einfach lesen können, daher ist eine digitale Lösung möglicherweise die beste.
• Wenn Sie sich dafür entscheiden, Ihren Sprint „an der Wand“ zu planen, sollten Sie am Ende des Planungsgesprächs unbedingt jemanden benennen, der Ihren Plan in Ihr Arbeitsmanagement-Tool transkribiert.

Egal, wo Ihre Planung stattfindet, denken Sie immer daran, Ihr Backlog im Voraus vorzubereiten, damit Sie während der Sprint-Planung fokussierte und fundierte Diskussionen führen können.

Zusätzliche agile Ressourcen

Wir erweitern ständig unsere Inhaltsbibliothek, die mit Ressourcen, Anleitungen, Produktupdates und vielem mehr gefüllt ist.

📚 Füge diese zu deiner Liste hinzu:

• Easy Agile Podcast Ep.20: Die Bedeutung der Team-Retrospektive
• Easy Agile Podcast Ep.18 Die besten Eigenschaften eines agilen Leiters und Teams
• Easy Agile Podcast Ep.16 Unterstützung leistungsstarker agiler Teams mit Adaptavist
• Agil sein oder agil handeln
• Der ultimative Leitfaden für User Story Mapping
• Der ultimative Leitfaden für Buyer Personas
• Der ultimative Leitfaden zur PI-Planung [2022 SAFe Edition]

Verwenden von Easy Agile zur Verbesserung der Sprint-Planung

Machen Sie Ihre Sprint-Planung reibungslos und effektiv mit Einfacher agiler Teamrhythmus. Verwandeln Sie Ihren flachen Produktbestand in eine dynamische, flexible und visuelle Darstellung der zu erledigenden Arbeit. TeamRhythm ist nahtlos in Jira integriert und bietet folgende Möglichkeiten:

• Sieh dir deine Jira-Storys, Aufgaben und Bugs im Kontext an, geordnet unter ihren Epen auf der Story-Map
• Ziehen Sie Jira-Issues per Drag-and-Drop aus dem Backlog in einen Sprint
• Neue Ausgaben direkt auf der Storymap erstellen
• Schätzen Sie Probleme auf der Story-Map ab und messen Sie die Kapazität anhand der Gesamtzahl der Story-Punkte in jeder Sprint-Swimlane
• Veröffentlichen Sie das Sprintziel auf jeder Sprint-Swimlane, damit es immer im Vordergrund steht
• Verwenden Sie Filter, um sich auf die Geschichten und Themen zu konzentrieren, die gerade am wichtigsten sind
• Gruppieren Sie Epen nach einer dritten Hierarchieebene, um leicht zu erkennen, wie die Arbeit im Fokus zum Gesamtbild beiträgt

Easy Agile TeamRhythm unterstützt auch Team-Retrospektiven mit flexiblen und intuitiven Retrospektiven-Boards, die für jeden Sprint erstellt werden. Du kannst rückblickende Elemente direkt von der Sprint-Swimlane aus hinzufügen, damit du keine wichtigen Punkte vergisst. Und du kannst rückwirkende Maßnahmen in Jira-Ausgaben umwandeln, die für zukünftige Sprints geplant werden können, sodass du in dem, was du tust, immer besser wirst und das für deine Kunden lieferst.

Vielen Dank, dass Sie unseren ultimativen Leitfaden zur agilen Sprint-Planung gelesen haben! Wenn Sie Fragen zu diesem Leitfaden, unseren anderen Inhalten oder unseren Produkten haben, wenden Sie sich an unser Team zu jeder Zeit. Wir freuen uns, von Ihnen zu hören.

Wir werden diesen Leitfaden weiter aktualisieren, sobald wir mehr Erkenntnisse, Techniken, Tools und Best Practices zur agilen Planung gewinnen.

Storypoints können etwas verwirrend sein und werden oft missverstanden. Story Points sind ein wichtiger Bestandteil des User Story Mappings, und viele agile Teams verwenden sie bei der Planung ihrer Arbeit. Sie sind jedoch nicht so einfach wie das Hinzufügen von Zahlen zu Aufgaben oder das Abschätzen, wie lange ein Job dauern wird.

Selbst wenn Sie Story Points schon eine Weile verwenden, werden Sie feststellen, dass verschiedene Teams und Organisationen sie unterschiedlich verwenden.

Lassen Sie uns also Storypoints definieren, besprechen, warum sie für agile Teams so nützlich sind, und über einige der verschiedenen Arten sprechen, wie Teams sie beim Story-Mapping und der Sprint-Planung umsetzen.

Was sind User Story Points?

Story Points sind eine nützliche Maßeinheit in Agile und ein wichtiger Bestandteil der Prozess zur Zuordnung von User Storys. Sie weisen jeder User Story eine Zahl zu, um den Gesamtaufwand abzuschätzen, der erforderlich ist, um ein Feature oder eine Funktion zum Leben zu erwecken.

Wann sollten Storypoints geschätzt werden?

User Stories können während des User Story-Mappings, der Backlog-Verfeinerung oder während der Sprint-Planung geschätzt werden.

Sobald eine User Story definiert, dem Backbone zugeordnet und priorisiert wurde, ist es an der Zeit, die Storypoints abzuschätzen. Es ist eine gute Idee, dabei mit Ihrem Team zusammenzuarbeiten, da jedes Teammitglied in verschiedenen Storys eine andere Rolle spielt und die Arbeit kennt, die mit UX, Design, Entwicklung, Test und Markteinführung verbunden ist. Die Zusammenarbeit bei der Schätzung von Storypoints hilft dir auch dabei, Abhängigkeiten frühzeitig zu erkennen.

Es empfiehlt sich, jeder User Story Story Points zuzuweisen, bevor du sie in Releases oder Sprints aufteilst. Auf diese Weise können Sie die Komplexität, den Aufwand und die Ungewissheit jeder User Story im Vergleich zu anderen in ihrem Backlog einschätzen und fundierte Entscheidungen über die Arbeit treffen, die Sie für jeden Sprint oder Release aufwenden.

Wie schätzt man User Story Points ein

Bei der Schätzung von Story Points berücksichtigen Sie den Gesamtaufwand, der erforderlich ist, um dieses Feature oder diese Funktion verfügbar zu machen, damit sie dem Kunden einen Mehrwert bieten kann. Ihr Team muss Fragen wie die folgenden besprechen:

• Wie komplex ist die Arbeit?
• Wie viel Arbeit ist erforderlich?
• Was sind die technischen Fähigkeiten des Teams?
• Was sind die Risiken?
• Bei welchen Teilen sind wir uns nicht sicher?
• Was müssen wir an Ort und Stelle haben, bevor wir beginnen oder fertig werden können?
• Was könnte schief gehen?

Tipp: Wenn du Schwierigkeiten hast, eine Story einzuschätzen oder der Umfang der Arbeit überwältigend ist, musst du deine Story möglicherweise in kleinere Teile zerlegen, um mehrere User Stories zu erstellen.

Was ist ein Storypoint wert?

An dieser Stelle können Storypoints etwas verwirrend werden, da Storypoints keinen festgelegten universellen Wert haben. Du musst irgendwie herausfinden, was sie für dich und dein Team wert sind (ja, wirklich tiefgründiges und bedeutungsvolles Zeug).

So funktioniert das:

• Jeder Geschichte wird eine bestimmte Anzahl von Storypoints zugewiesen
• Punkte bedeuten für verschiedene Teams oder Organisationen unterschiedliche Dinge.
• Ein Storypoint für dein Team entspricht möglicherweise nicht dem gleichen Aufwand, der mit einem Storypoint für ein anderes Team verbunden ist
• Der Aufwand für 1 Story Point sollte stabil bleiben dein Teamarbeit bei jedem Sprint und es sollte von einer Story zur nächsten stabil bleiben
• 2 Story Points sollten dem doppelten Aufwand im Vergleich zu 1 Story Point entsprechen
• 3 Story Points sollten dem dreifachen Aufwand entsprechen im Vergleich zu 1 Story Point... und so weiter

Die Zahl, die Sie vergeben, spielt keine Rolle — was zählt, ist das Verhältnis. Die Story Points sollen dir dabei helfen, den relativen Aufwand zwischen jeder Story und jedem Sprint nachzuweisen.

Zum ersten Mal Storypoints einschätzen

Da Story Points relativ sind, müssen Sie sich einige grundlegende Schätzungen geben, wenn Sie zum ersten Mal eine Story Point-Schätzung durchführen. Dadurch erhalten Sie einen Bezugsrahmen für alle zukünftigen Geschichten.

Wählen Sie zunächst Geschichten in verschiedenen Größen aus:

• Eine sehr kleine Geschichte
• Eine mittelgroße Geschichte
• Eine große Geschichte

... ein bisschen wie T-Shirt-Größen.

Weisen Sie dann jeder dieser grundlegenden Geschichten Punkte zu. Ihre kleinste Geschichte könnte 1 sein. Wenn deine mittlere Geschichte dreimal mehr Aufwand erfordert, dann sollte es 3 sein. Wenn Ihre große Geschichte den 10-fachen Aufwand erfordert, sollte es das 10-fache sein. Diese Zahlen hängen von der Art der Geschichten ab, an denen Ihr Team normalerweise arbeitet, sodass Ihre grundlegenden Story-Zahlen möglicherweise anders aussehen als diese.

Das Wichtigste ist, dass Sie diese grundlegenden Geschichten verwenden können, um all Ihre zukünftigen Geschichten abzuschätzen, indem Sie den relativen Aufwand vergleichen.

Mit der Zeit werden Sie und Ihr Team feststellen, dass es einfacher wird, Nutzerberichte einzuschätzen, wenn sich Ihr gemeinsames Verständnis der Arbeit entwickelt. Hier werden Storypoints am wertvollsten. Sie helfen Ihrem Team dabei, die Erwartungen aufeinander abzustimmen und effektiver zu planen.

Vereinfachen Sie die Schätzung

Eine App für Jira wie Einfacher agiler Teamrhythmus macht es einfach, das Teamengagement für jeden Sprint oder jede Version zu sehen, mit geschätzten Gesamtwerten für jede Swimlane.

Verwendung der Fibonacci-Sequenz zur Story-Point-Schätzung

Einige Teams verwenden die Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21, 34, 55, 89 usw.) für ihre Story-Point-Schätzungen, anstatt linear zu bleiben oder Teams zu erlauben, eine beliebige Zahl (1, 2, 3, 4, 5, 6, 7 usw.) zu verwenden.

Das hat seine Vorteile. Wenn Sie sich beispielsweise eine Geschichte ansehen und abschätzen möchten, ob es sich um eine 5, 8 oder 13 handelt, ist es viel schneller und einfacher, eine Antwort zu finden, als zu versuchen, auf der richtigen Zahl zwischen beispielsweise 4-15 zu landen. Sie werden wahrscheinlich viel schneller zu einem Konsens kommen.

Das bedeutet auch, dass ihr nicht in der Lage sein werdet, den Durchschnitt der Storypoints des Teams zu ermitteln, um die Schätzung abschliessen zu können. Stattdessen müsst ihr die Arbeit besprechen und euch für die beste Schätzung aus einer begrenzten Anzahl von Optionen entscheiden.

Aber es schränkt Ihre Möglichkeiten ein — wenn Sie eine Geschichte haben, die mehr Aufwand als 34, aber weniger als 55 erfordert, ist Ihre Schätzung möglicherweise weniger genau.

Verwendung von Story Points zur Schätzung der Geschwindigkeit

Nach einiger Zeit der Zusammenarbeit werden die meisten Teams eine gute Vorstellung davon haben, wie viel Aufwand in den einzelnen Storypoints steckt.

Natürlich ist das Timing nicht genau - es gibt eine Glockenkurve, und Story Points sind so konzipiert, dass sie eine Schätzung des Aufwands und nicht der Zeit sind.

Storypoints (und die Kenntnis ihres ungefähren Zeitpunkts) können jedoch hilfreich sein, wenn es darum geht, herauszufinden, wie viel Ihr Team in jedem Sprint erledigen kann.

Du solltest in der Lage sein, abzuschätzen, wie viele Storypoints dein Team während eines zweiwöchigen Sprints bewältigen kann, oder in welchem Zeitrahmen auch immer du gerade arbeitest.

Wenn dein Team beispielsweise in der Regel 3 Story Points pro Tag durchstehen kann, können sich in einem zweiwöchigen Sprint bis zu 30 Story Points summieren. Das ist deine Geschwindigkeit.

Velocity ist nützlich für das User Story Mapping und die Sprint-Planung. Wenn Sie Ihre User Stories Sprints oder Versionen zuordnen, können Sie die Gesamtzahl der Storypoints überprüfen und sicherstellen, dass sie mit Ihrer Geschwindigkeit übereinstimmt, damit Sie sich nicht zu sehr oder zu wenig engagieren.

Wie Sie sehen, gibt es verschiedene Methoden zur Schätzung der Arbeit. Der beste Rat ist, konservativ zu sein und das Team nicht zu überlasten.

Im Laufe der Zeit sollten Ihre Schätzungen genauer werden.

Verwendung von Story Points in Scrum, Kanban und Extreme Programming

Story Points sind in vielen agilen Methoden von zentraler Bedeutung für Schätzungs- und Planungsprozesse. Scrum und Extreme Programming (XP) stützen sich stark auf Story Points, um den Aufwand und die Komplexität von User Stories einzuschätzen.

Scrum-Teams verwenden während der Sprint-Planung Storypoints, um zu entscheiden, welche Aufgaben in den kommenden Sprint aufgenommen werden sollen, und fördern so Diskussionen, die zu einem gemeinsamen Kontext und einem gemeinsamen Verständnis der Arbeit führen.

Extreme Programming hingegen verwendet Story Points, um die Größe von Funktionen zu beurteilen, sodass Teams Ressourcen effektiv priorisieren und zuweisen können. Teams, die Kanban verwenden, können von Storypoints profitieren, indem sie sie nutzen, um Grenzen für laufende Aufgaben festzulegen und den gesamten Aufgabenablauf zu optimieren.

Die spezifischen Praktiken können sich zwar unterscheiden, aber Story Points können dazu beitragen, die Zusammenarbeit im Team und einen vorhersehbareren Arbeitsablauf zu fördern.

Manchmal scheint die Idee, User Stories zu schreiben, eine weitere „Sache“ zu sein, die zu einer ohnehin schon vollen Arbeitsbelastung hinzukommt. Aber für Softwareentwicklungsteams, die ihre eigenen Verbesserungen selbst vorantreiben und Software liefern wollen, die für ihre Kunden funktioniert, ist das Schreiben effektiver User Stories der erste Schritt.

Wenn Sie diesen Beitrag lesen, bedeutet das, dass Sie herausfinden möchten, was für die Menschen, die Ihre Software verwenden, am besten funktioniert, und Ihre Herangehensweise an die Softwareentwicklung verbessern möchten. Das ist großartig! Unser Ziel bei Easy Agile ist es, Ihnen dabei zu helfen.

Beginnen wir also damit, warum gute User Stories wichtig sind.

Warum User Stories schreiben?

Sie fragen sich vielleicht, warum Sie User Stories schreiben sollten, anstatt stattdessen Funktionen oder Aufgaben zu schreiben.

Wenn das nach Ihnen klingt, haben Sie vielleicht noch nicht erkannt, wie wichtig es ist, User Stories zu schreiben, und dass sie einem ganz anderen Zweck dienen als das Schreiben von Funktionen oder Aufgaben.

Es ist leicht, sich in einem Zyklus der Feature-Entwicklung zu verlieren, dem es an Kontext mangelt. Das Ziel besteht mehr darin, sich den Weg durch einen großen Backlog freizumachen, als Lösungen zu entwickeln, die Ihren Kunden einen Mehrwert bieten. Um erfolgreiche Software zu entwickeln, müssen Sie sich auf die Bedürfnisse der Menschen konzentrieren, die sie verwenden werden. Ihre menschlichen Kunden. Nutzerberichte bringen diesen Kontext und diese Perspektive in den Entwicklungszyklus ein.

Was ist eine User Story?

Eine User Story hilft agilen Softwareentwicklungsteams, sich in ihre Kunden hineinzuversetzen. Aus der Sicht des Kunden (oder Benutzers) geschrieben, helfen User Stories dem Entwicklungsteam zu verstehen, was es entwickeln muss und warum es es erstellen muss.

User Stories sind vereinfachte, allgemeine Beschreibungen der Anforderungen eines Benutzers, die aus der Sicht des Endbenutzers verfasst wurden. Eine User Story ist kein kontextloses Feature, das in der Sprache der Entwickler geschrieben ist.

Eine User Story = das „Was“

Eine User Story beschreibt eine Funktion aus der Sicht des Benutzers.

User Stories unterteilen Funktionen in Geschäftsprozesse.

Eine Aufgabe = das „Wie“

Aufgaben sind die Aktivitäten, die ausgeführt werden müssen, um ein Ergebnis zu erzielen.

Aufgaben sind einzelne Arbeiten.

Wie schreiben wir User Stories?

Vielleicht möchten Sie sich eine User Story als „Gleichung“ vorstellen:

Als [Benutzer] + möchte ich [Absicht] +, damit [Wert]

Lassen Sie uns das weiter aufschlüsseln;

Als [Benutzer] — das ist die WHO. Für wen bauen wir das? Wer ist der Nutzer?

Ich will [Absicht] — das ist das WAS. Was bauen wir? Was ist die Absicht?

Also das [Wert] — das ist das WARUM. Warum bauen wir es? Was ist der Wert für den Kunden?

Schauen wir uns ein paar einfache Beispiele an;

Als Internetbanking-Kunde

ich will um einen fortlaufenden Saldo für meine täglichen Konten zu sehen

Also das Ich kann nach jeder Transaktion den Überblick über meine Ausgaben behalten

ODER

Als Administrator

ich will um andere Administratoren für bestimmte Projekte erstellen zu können

Also das Ich kann Aufgaben effizienter delegieren

Gemäß dieser Gleichung sollten Teams sicherstellen, dass ihre User Stories alle der folgenden Checkboxen ankreuzen:

Um erfolgreiche User Stories zu schreiben:

• Halte sie kurz
• Halte sie einfach
• Schreiben Sie aus der Sicht des Benutzers
• Machen Sie den Wert oder Nutzen der Geschichte deutlich
• Beschreiben Sie eine Funktion
• Schreiben Sie im Team User Stories
• Verwenden Sie Akzeptanzkriterien, um einen MVP anzuzeigen.

Akzeptanzkriterien

User Stories ermöglichen es agilen Teams, die Bedürfnisse, Wünsche und Werte ihrer Kunden mit den Aktivitäten in Einklang zu bringen, die sie durchführen müssen, um diesen Mehrwert zu bieten.

Der Link, der diese beiden Dinge miteinander verbindet, sind Akzeptanzkriterien.

Die Akzeptanzkriterien oder „Erfüllungsbedingungen“ geben einen detaillierten Überblick über die Benutzeranforderungen. Sie helfen dem Team, den Wert der User Story zu verstehen und helfen dem Team zu wissen, wann es erwägen kann, etwas zu tun.

Ziele der Akzeptanzkriterien

Die Akzeptanzkriterien sollten:

• klären Sie, was das Team bauen soll, bevor es mit der Arbeit beginnt
• Sicherstellung eines gemeinsamen Verständnisses des Problems oder der Bedürfnisse des Kunden
• Helfen Sie den Teammitgliedern, zu wissen, wann die Geschichte abgeschlossen ist
• helfen Sie dabei, die Geschichte durch automatisierte Tests zu überprüfen.

Schauen wir uns ein Beispiel für eine abgeschlossene User Story mit Akzeptanzkriterien an:

Als potenzieller Konferenzteilnehmer möchte ich mich online für die Konferenz anmelden können, sodass die Registrierung einfach und papierlos ist.

Akzeptanzkriterien:

• Teilnahmeformular für die Konferenz
• Ein Benutzer kann kein Formular einreichen, ohne alle Pflichtfelder auszufüllen (Vorname, Nachname, Firmenname, E-Mail-Adresse, Position, Rechnungsinformationen)
• Informationen aus dem Formular werden in der Registrierungsdatenbank gespeichert.
• Der Schutz vor Spam funktioniert
• Die Zahlung kann per Paypal, Lastschrift oder Kreditkarte erfolgen
• Nach dem Absenden des Formulars wird dem Teilnehmer eine Bestätigungs-E-Mail gesendet

Vor diesem Hintergrund sollten die Teams sicherstellen, dass ihre Akzeptanzkriterien alle folgenden Punkte berücksichtigen:

• Negative Szenarien der Funktionalität
• Funktionale und nicht funktionale Anwendungsfälle
• Leistungsbedenken und Richtlinien
• Was das System oder die Funktion zu tun beabsichtigt
• durch/Benutzerfluss
• Der Einfluss einer User Story auf andere Funktionen
• UX-Bedenken

Die Akzeptanzkriterien sollten NICHT Folgendes beinhalten:

• Die Codeüberprüfung wurde durchgeführt
• Nichtblocker oder größere Probleme
• Leistungstests durchgeführt
• Abnahme und Funktionstest abgeschlossen
  

Warum?

Ihre Akzeptanzkriterien sollten keines der oben genannten Punkte enthalten, da Ihr Team bereits ein klares Verständnis davon haben sollte, was Ihre Definition of Done (DoD) beinhaltet, zum Beispiel:

• Einheit/integriertes Testen
• bereit für den Abnahmetest
• auf dem Demoserver bereitgestellt
• lösbar

Das Schreiben effektiver User Stories ist eine wertvolle Praxis, die Ihnen und Ihrem Team dabei hilft, Software bereitzustellen, die für Ihre Kunden relevant bleibt.

Wenn Sie User Stories als mehr als nur eine weitere Aufgabe auf Ihrer Checkliste betrachten, sondern sie stattdessen als unverzichtbares Instrument betrachten, um Kontext und Wert für Ihre Projekte zu schaffen, können Sie mit Ihrem wichtigsten Fokus in Verbindung bleiben — Ihrem Kunden.

Verwandeln Sie Ihr Backlog in ein aussagekräftiges Bild der Arbeit, um Kontext für die Sprint- und Versionsplanung, die Backlog-Verfeinerung und das User Story Mapping zu erhalten.

Konzentrieren Sie sich auf Ihre Kunden

Einfacher agiler Teamrhythmus