Im Scrum ist Refinement der Prozess, der dazu dient, sicherzustellen, dass die Elemente im Produkt-Backlog klar, präzise und bereit für die Entwicklung sind. Es handelt sich um eine kontinuierliche und kollaborative Anstrengung zwischen dem Product Owner und dem Entwicklungsteam, um sicherzustellen, dass der Produkt-Backlog stets in einem Zustand ist, in dem die nächsten Elemente klar verstanden werden und vom Entwicklungsteam bearbeitet werden können. Das Ziel von Refinement ist es, die Effizienz des Entwicklungsprozesses zu verbessern, indem das Team sich auf die Lieferung von Werten für den Kunden konzentriert.
Die häufigsten Fehler im Refinement
Aus meiner Sicht sind dieses dieses die 5 häufigsten Fehler:
1. Es wird nicht genügend Zeit für Refinements eingeplant, was zu einem unklaren oder veralteten Produkt-Backlog führt.
2. Es werden nicht die richtigen Personen in den Refinement-Prozess eingebunden, was zu einem Produkt-Backlog führen kann, der nicht die Prioritäten und Ziele des Teams widerspiegelt.
3. Elemente im Produkt-Backlog werden nicht klein genug in Arbeitspakete aufgeteilt, die in einem Sprint abgearbeitet werden können.
4. Die Elemente werden nicht effektiv priorisiert, was dazu führen kann, dass das Entwicklungsteam an den falschen Dingen arbeitet und keinen Mehrwert generiert.
5. Es gibt kein aktuelles Backlog, was dazu führen kann, dass zu wenige Punkte in der folgenden Sprint-Planung zur Verfügung stehen.
Wie viel Zeit sollte man in Refinements stecken?
Es ist wichtig, einen Ausgleich zu finden, wenn es um die Menge an Zeit geht, die für Refinements aufgewendet wird. Auf der einen Seite ist es wichtig, sicherzustellen, dass der Produkt-Backlog gut gewartet und auf dem neuesten Stand ist. Auf der anderen Seite kann zu viel Zeit für Refinements kontraproduktiv sein, da es Zeit von der eigentlichen Entwicklungsarbeit wegnimmt. Es ist wichtig, einen Ausgleich zu finden, der für das Team und das Projekt funktioniert. Letztendlich kann es notwendig sein, viel Zeit in Refinements zu investieren, um die Ergebnisse zu verbessern und die gewünschten Ergebnisse zu erzielen. Es bringt nichts viel Entwicklungszeit auf die Entwicklung der falschen Features zu verwenden.
Wer sollte beim Refinement dabei sein?
Beim Refinement sollten idealerweise alle Mitglieder des Scrum-Teams teilnehmen, insbesondere der Product Owner und das Entwicklungsteam. Es kann auch sinnvoll sein, Vertreter anderer Teams oder Stakeholder einzubeziehen, um deren Anforderungen und Perspektiven zu berücksichtigen.
Der Product Owner ist für die Definition und Priorisierung des Produkt-Backlogs verantwortlich und sollte daher bei jedem Refinement anwesend sein, um sicherzustellen, dass das Backlog auf dem neuesten Stand ist und die Bedürfnisse und Anforderungen der Stakeholder widerspiegelt.
Das Entwicklungsteam sollte ebenfalls beim Refinement dabei sein, um die Elemente im Produkt-Backlog zu besprechen, ihre Komplexität zu bewerten und Arbeitspakete zu definieren. Dies hilft ihnen dabei, den Aufwand für zukünftige Sprints besser zu planen und sicherzustellen, dass sie die Arbeit effektiv ausführen können.
Es ist wichtig, dass die Personen, die am Refinement teilnehmen, die notwendige Kompetenz und Autorität haben, um Entscheidungen zu treffen und sicherzustellen, dass das Produkt-Backlog auf dem neuesten Stand ist und den Anforderungen der Stakeholder entspricht.
Wie groß sollten die zu schätzenden Tickets sein?
Die Größe der Punkte im Produkt-Backlog beim Refinement sollte so klein sein, dass das Entwicklungsteam diese Aufgaben in einem Sprint abschließen kann. Die Punkte im Backlog sollten auch so formuliert sein, dass sie klar und verständlich sind und eine klare Vorstellung davon vermitteln, was zu tun ist. Hierbei kann die Verwendung von Akzeptanzkriterien (Definition of Done) hilfreich sein.
Eine gängige Methode, um die Größe der Aufgaben im Backlog zu schätzen, ist die Verwendung von Story Points. Story Points sind eine relative Schätzgröße, die die Größe und Komplexität einer Aufgabe widerspiegelt. Es gibt verschiedene Techniken, um Story Points zu schätzen, wie zum Beispiel Planning Poker. Bei uns verwenden wir meist Story Points mit den Zahlen der Fibonacci Reihe.
Es ist wichtig, dass die Aufgaben im Backlog klein genug sind, um in einem Sprint abgeschlossen werden zu können, da dies dem Entwicklungsteam ermöglicht, einen besseren Überblick über den Fortschritt der Arbeit und den verbleibenden Aufwand zu haben. Außerdem fördert die Aufteilung in kleinere Aufgaben die Transparenz und die Möglichkeit, die Fortschritte zu messen und das Produkt-Backlog zu aktualisieren.
Eine grobe Orientierung kann sein, dass eine Aufgabe im Produkt-Backlog nicht größer als zwei Tage Arbeit sein sollte. Es ist jedoch wichtig, dass das Team und der Product Owner gemeinsam die Größe der Aufgaben im Backlog schätzen und geeignete Methoden finden, um sicherzustellen, dass sie klein genug sind, um im Sprint umgesetzt zu werden.
Wie sollte das Backlog priorisiert sein?
Die Priorisierung der Elemente im Produkt-Backlog sollte auf der Grundlage des Wertes für den Kunden und der Bedürfnisse der Stakeholder erfolgen. Der Product Owner ist für die Priorisierung des Backlogs verantwortlich und sollte dafür sorgen, dass die am höchsten priorisierten Elemente im Backlog den höchsten Wert für den Kunden oder die Stakeholder haben.
Um die Priorisierung zu unterstützen, können verschiedene Methoden verwendet werden, wie zum Beispiel die MoSCoW-Methode oder die Value-based Prioritization. Bei der MoSCoW-Methode werden die Elemente im Backlog in vier Kategorien eingeteilt: Must Have, Should Have, Could Have und Won't Have. Diese Kategorien helfen dabei, die Priorität der Elemente im Backlog klar zu definieren und sicherzustellen, dass die am höchsten priorisierten Elemente zuerst umgesetzt werden.
Bei der Value-based Prioritization werden die Elemente im Backlog anhand des geschätzten Nutzens für den Kunden oder die Stakeholder bewertet. Hierbei wird der Nutzen in Relation zu den Kosten und dem Aufwand für die Umsetzung betrachtet. Dies hilft dabei, sicherzustellen, dass die am höchsten priorisierten Elemente den größten Nutzen für den Kunden oder die Stakeholder haben und die Ressourcen des Teams effektiv eingesetzt werden.
Wie oft sollte der Product Owner das Backlog priosieren?
Es ist auch wichtig, dass die Priorisierung des Produkt-Backlogs kontinuierlich erfolgt, um sicherzustellen, dass das Backlog immer auf dem neuesten Stand ist und den Bedürfnissen der Stakeholder entspricht. Der Product Owner sollte daher regelmäßig Feedback von den Stakeholdern einholen und das Produkt-Backlog entsprechend anpassen.
Zusammenfassung
Zusammenfassend sollten Scrum-Master und Product Owner sicherstellen, dass genügend Zeit und die richtigen Personen für das Refinement eingeplant werden, die Elemente im Backlog in kleine Aufgaben aufgeteilt werden und die Priorisierung der Elemente auf der Grundlage des Wertes für den Kunden und der Bedürfnisse der Stakeholder erfolgt. Durch die kontinuierliche Überprüfung und Anpassung des Produkt-Backlogs kann das Team effektiv arbeiten und den höchsten Nutzen für den Kunden und die Stakeholder generieren. Dieses bildet die Grundlagen für ein erfolgreiches SCRUM Refinement und sollten von Scrum-Mastern und Product Ownern beachtet werden, um sicherzustellen, dass das Team effektiv arbeitet und den höchsten Nutzen für den Kunden und die Stakeholder generiert.
