Feedback in der agilen Entwicklung implementieren

Ich denke, Aziz hat einen soliden Ansatz geliefert.

In dem von Ihnen beschriebenen Szenario klingt es so, als hätten Sie am Ende Ihres Sprints Feedback von Ihrem PO erhalten.

Wenn ja, dann ist die Antwort einfach: Sie haben im aktuellen Sprint keine Zeit mehr und müssen das Feedback zur Berücksichtigung in zukünftigen Sprints abschätzen und priorisieren. Agile verlangt nicht, einen einzelnen Sprint zu verlängern, um an einem Feature oder Feedback zu arbeiten.

Um die große Vielfalt an Feedback besser zu bewältigen, liegt es in der eigenen Verantwortung, Benutzerakzeptanzkriterien (UAC) für User Stories in einem Sprint definieren zu lassen.

Ich hoffe das hilft.

Feedback-Elemente werden schließlich Teil des Produkt-Backlogs, indem sie entweder überarbeitet oder neue Elemente im Backlog hinzugefügt werden. Diese müssen vom Product Owner priorisiert werden, bevor das Team sie in ein Sprint/Iteration Backlog zieht. Also um deine Frage zu beantworten:

in welchem ​​Sprint (aktueller oder nächster) soll ich die Feedback-Antworten umsetzen

Feedback wird basierend auf der von der Bestellung festgelegten Priorität implementiert. Wenn PO möchte, dass ein Feature/eine Story vor den Feedback-Elementen fertiggestellt wird, wird das Team das Feedback in einem zukünftigen Sprint implementieren.

Alle dem Backlog hinzugefügten Feedback-Items müssen geschätzt werden. Abhängig von der Einschätzung kann das Team zu dem Schluss kommen, dass es möglicherweise einen oder mehrere Sprints zum Projektplan hinzufügen muss. Wenn dies der Fall ist, sollte dies dem PO so früh wie möglich klar mitgeteilt werden, da dies dem PO hilft, den Rückstand richtig zu priorisieren.

Eine effektive und effiziente Feedback-Schleife ist während der agilen Entwicklung sehr wichtig. Ein starkes und wirksames Management dieses Feedbacks ist jedoch ebenso wichtig, da wir sonst einen unorganisierten und unüberschaubaren Produktrückstand in unseren Händen haben. Nicht alle Feedback-Elemente müssen in das Backlog aufgenommen werden. PO hat eine sehr wichtige Verantwortung, das Feedback zu analysieren und zu kontrollieren, was in den Rückstand kommt. Eines der Tools, die PO verwenden kann, ist die MoSCoW-Priorisierungstechnik , bei der jedes Element basierend auf dem Produkt-/Projektziel wie folgt kategorisiert (oder weiter aufgeschlüsselt) werden kann:

• M - Muss man haben
• S - Hätte
• C - Hätte
• W - Wird es nicht geben

Gewünschte Artikel müssen ebenfalls dokumentiert und mit dem Status „ Geschlossen “ versehen werden, damit wir diese nicht aus den Augen verlieren und nachverfolgt werden können. Diese Elemente können jene Feedback-Elemente sein, die für das Produkt nicht relevant sind oder zu diesem Zeitpunkt nicht kosteneffektiv zu implementieren sind.

Einige Hinweise zur Verwendung von MoSCoW in Agile:

• https://web.archive.org/web/20150523232257/http://drucode.com/our-product-development-process
• https://web.archive.org/web/20190904025148/http://toolsforagile.com/blog/archives/46/moscow-as-a-prioritization-and-planning-tool
• http://cs.anu.edu.au/courses/COMP3120/local_docs/readings/Prioritisation_using_MoSCoW_AllAboutAgile.pdf
• https://web.archive.org/web/20160515215721/https://www.agileacademy.com.au/agile/sites/default/files/aboutpdfs/AgilePracticesMoSCoWAgile%20Academy.pdf

Dies ist jedoch nur eines der verfügbaren Tools. Es gibt auch andere Priorisierungstechniken, die verwendet werden können. Ziel ist eine bessere Priorisierung des Product Backlogs.

TL;DR

Sie vermissen einige definierte Meetings, die das alles viel klarer machen würden. Insbesondere scheinen Sie Folgendes zu überspringen:

1. Sprint Review, das ist der richtige Ort für Feedback am Ende des Sprints.
2. Backlog Grooming, bei dem der Product Owner mit dem Team zusammenarbeiten kann, um die User Stories im Product Backlog basierend auf dem Sprint Review und anderen Faktoren zu ändern.

Feedback kann an jedem Punkt des Sprint-Zyklus integriert werden, aber Feedback, das neue Ziele oder User Stories generiert, wird immer für zukünftige Sprints geplant, es sei denn, der Product Owner ruft die vorzeitige Beendigung des Sprints mit einer sofortigen Rückkehr zur Sprint-Planung auf.

Ihr "Feedback" ist eine Bewertung

Während viele User Stories Platzhalter für Konversationen sind, die die Kommunikation zwischen Teammitgliedern (und manchmal Stakeholdern, anderen Teams oder Endbenutzern) erleichtern, unterscheidet sich dies erheblich von einer Überprüfung. Wenn Sie mit Ihrem Product Owner über die laufende Arbeit während des Sprints sprechen, kann dies dem Team helfen, kleine Korrekturen vorzunehmen, um das Sprint-Ziel auf Kurs zu halten. Dies ist einer der vielen Gründe, warum ein Product Owner mit dem Team zusammensitzen und während des gesamten Sprints für das Team verfügbar sein sollte.

Kleine Korrekturen vorzunehmen, die sich nicht auf das Sprint-Ziel auswirken oder die in den Sprint aufgenommenen User Stories erheblich ändern, ist jedoch überhaupt nicht das, worüber Sie in Ihrem Beitrag sprechen. Wenn du sagst:

Ich habe meinen Sprint geplant und ausgeführt, und dann habe ich die Produkt-URL für Feedback eingereicht und eine Antwort von meinem Product Owner erhalten.

Sie beschreiben eine Situation, in der die Feature-Lieferung für den Sprint abgeschlossen ist und das Team die Features für den Product Owner und die Stakeholder demonstriert. Dies ist die Sprint-Überprüfung , bei der das Team die Ergebnisse des aktuellen Sprints mit dem Sprint-Ziel vergleicht, das während der letzten Sprint-Planungssitzung definiert wurde.

Dies ist die Gelegenheit für die Organisation, den Fortschritt des Projekts zu überprüfen, dem Team Feedback über das Projekt oder die Funktionen zu geben und potenzielle User Stories zu identifizieren, die der Product Owner basierend auf der gerade abgeschlossenen Arbeit priorisieren kann. Dies ist eines der definierten Inspect-and-Adapt-Meetings, die das Scrum-Framework untermauern, und es zu überspringen oder unsachgemäß zu verwenden, ist definitiv ein Scrum-Antimuster.