Ich habe eine Frage zum Sprint Review (Demo) Meeting von Scrum, das am Ende jedes Sprints in Kombination mit Repositories und dem Git-Workflow stattfindet.
Ich weiß, dass unfertige Arbeiten aus dem Sprint wieder in das Product Backlog aufgenommen werden. Dies ist mit der Codebase sehr einfach, da sich die unvollendete Arbeit in einem separaten Feature-Zweig befindet.
Die Frage, die ich habe, ist, wann der Product Owner eine vollständig erstellte User Story ablehnt, die bereits in den Release-Branch gemergt wurde.
Wenn beispielsweise eine Benutzerverwaltungsseite erstellt wird, kann es User Storys zu den Themen „Alle Benutzer anzeigen“ und „Neuen Benutzer erstellen“ geben. Der „Neuen Benutzer anlegen“ braucht den Überblick, denn nur so kommt man dorthin und kann ihn nutzen. In der Entwicklung wird also die Übersichts-User Story entwickelt und mit dem Release-Zweig zusammengeführt, dann wird die User Story „Neuen Benutzer erstellen“ entwickelt und ebenfalls wieder mit dem Release-Zweig zusammengeführt.
Wenn also der Product Owner die User Story „Neuen Benutzer erstellen“ ablehnt:
Wie können wir diese Funktionalität allein aus dem Release-Zweig entfernen?
Scrum ist ein kollaborativer Prozess zwischen den drei definierten Rollen (Product Owner, Scrum Master und Entwicklungsteam). Sie haben Probleme mit Ihrer Scrum-Implementierung, weil Ihr Product Owner während des gesamten Prozesses nicht mitarbeitet.
Das Scrum-Team (einschließlich des Product Owners) vereinbart gemeinsam ein Sprint-Ziel für jeden Sprint sowie eine Definition of Done für Stories oder Product Backlog Items (PBIs), die innerhalb des Sprints erledigt werden.
Nach diesen Kriterien wird Arbeit „erledigt“ oder „nicht erledigt“. Es gibt keine Rahmenvorschrift für die Ablehnung von Arbeiten, die die vereinbarten Kriterien erfüllt haben. Es gibt jedoch Möglichkeiten, das Produkt iterativ zu verbessern und den Prozess zu überprüfen und anzupassen.
Das Sprint Review ist der Ort, an dem gezeigt werden kann, welche Arbeit während des aktuellen Sprints abgeschlossen wurde. Es ist eine formelle Zeremonie innerhalb des Scrum-Rahmens und hat einen bestimmten Zweck:
Am Ende des Sprints findet ein Sprint Review statt, um das Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews arbeiten das Scrum Team und die Stakeholder darüber zusammen, was im Sprint getan wurde. Basierend darauf und auf allen Änderungen am Product Backlog während des Sprints arbeiten die Teilnehmer an den nächsten Dingen, die getan werden könnten, um den Wert zu optimieren. Dies ist ein informelles Meeting, kein Statusmeeting, und die Präsentation des Inkrements soll Feedback hervorrufen und die Zusammenarbeit fördern.
Das Sprint Review ist nicht als Inkrement-Abnahme- oder Statusbericht-Meeting gedacht. Es ist einfach eine Möglichkeit, zusammenzuarbeiten, was als nächstes innerhalb des Projekts getan werden sollte, und für die Beteiligten, sich an der iterativen Gestaltung und Implementierung des Produkts zu beteiligen.
Der Product Owner sollte während des Sprints involviert sein. Er sollte den Entwicklern ständig zur Verfügung stehen, Teil des täglichen Stand-Ups sein und eng mit dem Scrum Master zusammenarbeiten, um Burn-Down, die Definition of Done und andere Metriken zu verfolgen, die sich auf das definierte Sprint-Ziel beziehen.
Wenn das Work-in-Progress das definierte Sprint-Ziel nicht erreichen wird, kann der Product Owner mit dem Team zusammenarbeiten, um den Umfang zu ändern oder eine vorzeitige Beendigung und eine Rückkehr zur Sprint-Planung auszurufen. Während der Sprint-Retrospektive sollten der Product Owner und das Entwicklungsteam auch zusammenarbeiten, um die Qualität der User Stories zu verbessern, Akzeptanztests in jeden Sprint als Teil der Definition of Done aufzunehmen oder andere Prozessänderungen vorzunehmen, um die Wahrscheinlichkeit fehlgeschlagener Sprints zu verringern die Zukunft.
Arbeiten, die in Übereinstimmung mit dem definierten Sprint-Ziel abgeschlossen sind und die vereinbarte Definition of Done erfüllen , sind jedoch abgeschlossen, unabhängig davon, ob sie den ursprünglichen Vorstellungen des Product Owners oder der Stakeholder entsprechen oder nicht.
Sofern ein Inkrement das Sprint-Ziel oder die Definition of Done nicht erfüllt hat, darf die Arbeit nicht abgelehnt werden. Das Sprint Review ist jedoch der Ort, an dem herausgearbeitet werden kann, wie man iterativ auf das zugeht, was die Stakeholder wirklich wollen, nachdem sie gesehen haben, wie das, worum sie gebeten haben, umgesetzt wurde. Danach ist die Sprint-Retrospektive der Ort, um Prozess- oder Kommunikationsverbesserungen zu identifizieren, die dem Scrum-Team und der Organisation helfen, in Zukunft besser zusammenzuarbeiten.
Es lohnt sich, einen Schritt zurückzutreten und darüber nachzudenken, das Problem von vornherein zu vermeiden.
Das Sprint Review sollte nicht das erste Mal sein, dass der Product Owner die während des Sprints erstellte Funktionalität sieht. Sie sollten mit der Funktionalität so früh wie möglich vertraut gemacht werden, oft dann, wenn sie sich noch in der Entwicklung befindet . Typischerweise konzentriert sich das Sprint Review mehr auf Stakeholder, die nicht in der Lage sind, die Zeit zu verbringen, die der Product Owner mit dem Team verbringt.
Wenn der Product Owner zusieht, wie die Stories erstellt werden, ist es unwahrscheinlich, dass er sie beim Sprint Review plötzlich ablehnt.
Es ist auch erwähnenswert, dass eines der Ziele bei der Erstellung von User Stories darin besteht, sie voneinander unabhängig zu machen. Wenn die Story „Neuen Benutzer erstellen“ von der Story „Alle Benutzer anzeigen“ abhängig ist, laufen Sie immer Gefahr, dass diese Art von Problem auftritt.
Es ist eine Herausforderung, Geschichten diskret zu halten, aber es ist möglich. Eine Möglichkeit, dies zu tun, ist die Verwendung eines sogenannten „Funktionsumschalters“, bei dem die Funktion unabhängig von anderen Funktionen ein- und ausgeschaltet werden kann. In dem von Ihnen angeführten Beispiel, in dem die Geschichte „Neuen Benutzer erstellen“ abgelehnt wird, könnte ein Funktionsumschalter verwendet werden, um diese Funktion zu deaktivieren, bis der Product Owner damit zufrieden ist.
Wenn Sie schließlich eine Quellcodeverwaltung wie Git verwenden, können Sie eine Menge tun, um ein bestimmtes Feature-Commit rückgängig zu machen, ohne anderen Code wegzuwerfen. Möglicherweise möchten Sie Feature-Zweige für jede Story haben, die regelmäßig mit Ihrem Release-Zweig zusammengeführt werden. Wenn diese Art von Problem auftritt, setzen Sie alle Commits auf den Release-Zweig zurück, der sich auf die Story bezieht, und aktualisieren Sie alle anderen Commits, die in der Zwischenzeit aufgetreten sind.
Dieser Ansatz zur Quellcodeverwaltung ist jedoch schwierig und es ist vorzuziehen, das Problem von vornherein zu vermeiden.
Es wäre am hilfreichsten zu wissen, warum das jeweilige Feature so spät im Prozess vom Product Owner abgelehnt wird. Barnaby Goldens Antwort geht in die richtige Richtung, aber ich denke, sie geht nicht weit genug.
Der Product Owner ist die Person, die die Epics, Features und Stories im Product Backlog priorisiert. Nun kann es technische Abhängigkeiten zwischen Stories geben und das Team muss sicherstellen, dass der Product Owner dies erkennt. Dies geschieht beim Sprint-Planungsmeeting, wenn Elemente aus dem Product Backlog herausgezogen und in das Sprint Backlog eingefügt werden.
Wenn die Story „alle Benutzer anzeigen“ eine hohe Priorität hat, aber technische Abhängigkeiten zu einer Story „Benutzer erstellen“ mit niedrigerer Priorität hat, dann ist es sinnvoll, die Abhängigkeit zuerst zu implementieren, damit die gewünschte Story geliefert werden kann. Das Entwicklungsteam sollte mit dem Product Owner zusammenarbeiten, um sicherzustellen, dass diese technischen Abhängigkeiten verstanden werden.
In der Antwort von Barnaby Golden wurde auch auf Feature-Toggles eingegangen, worüber Martin Fowler kürzlich viel geschrieben hat . Aber ich denke nicht, dass sie notwendig sein sollten, wenn Ihr Prozess kollaborativ ist. Das Entwicklungsteam und der Product Owner sollten sich vor Beginn des Sprints auf den Inhalt des Sprint Backlog einigen. Dann sollte der Product Owner während des gesamten Sprints daran beteiligt sein, sicherzustellen, dass die geleistete Arbeit den Bedürfnissen der Stakeholder entspricht. Es sollte keinen Grund geben, die Möglichkeit zum Umschalten einer Funktion am Ende des Sprints entfernen oder hinzufügen zu müssen. Wenn ein Feature umgeschaltet werden muss, sollte dies rechtzeitig vor dem Sprint Review entdeckt werden.
Thomas Owens
Todd A. Jacobs