Szenario: Wir haben Architekten, die Spezifikationen und Akzeptanzkriterien schreiben. Geschäftsspezialisten und Product Owner geben keine dokumentierten Geschäftsspezifikationen/-logiken vor, sodass die Architekten die Akzeptanzkriterien schreiben und diese mit dem Geschäftsspezialisten und Product Owner in einem Meeting überprüfen.
Problem: Während die PO die Aufgabe testete (Product Owner Testing erwähnt in diesem Beitrag: Post on Product Owner Testing), fand sie ein Szenario, das nicht funktioniert. Aber wir haben die Akzeptanzkriterien durchgelesen und dieses Szenario wurde nie erwähnt und sie möchte es scheitern an der Aufgabe.
Frage: Kann ein PO eine Aufgabe nicht bestehen, weil das Szenario nicht in den Akzeptanzkriterien erwähnt wurde?
Ich würde nein sagen! denn das kann zu Scope Creep führen.
Ausgabe:
Der PO/Geschäftsspezialist sollte Geschäftslogik/Anforderungen aufschreiben, damit ein Architekt, wenn er an den Spezifikationen/Abnahmekriterien arbeitet, alle Szenarien abdecken kann.
Weichen Sie nicht von den Akzeptanzkriterien ab, da sie nach der Entwicklung alle möglichen Szenarien oder Anforderungen hinzufügen können.
Du hast kein einziges Problem, du hast viele. Abgesehen vom Fehlen eines funktionsübergreifenden Teams, das vollständig zusammenarbeitet, scheinen die beiden größten Prozessprobleme zu sein:
Wenn Sie nicht beide Probleme lösen, machen Sie kein Scrum. Noch wichtiger ist, dass das Scrum-Team dysfunktional bleibt, solange der Product Owner und das Entwicklungsteam im Streit bleiben, anstatt eng zusammenzuarbeiten.
Das gesamte Scrum-Team (nicht nur der Product Owner) muss neu geschult werden, wie iterative Entwicklung wirklich funktioniert. In Scrum hat jeder Sprint ein einzelnes, kohärentes Ziel (das Sprint-Ziel), an dessen Erfüllung das gesamte Team gemeinsam arbeitet. Die Arbeit wird vom Product Owner priorisiert, vom Entwicklungsteam ausgewählt und für den Sprint geplant, und dann wird die abgeschlossene Arbeit den Stakeholdern beim Sprint Review demonstriert. Das Sprint Review kann auch ein Ort sein, um zu diskutieren, warum das Sprint-Ziel nicht erreicht wurde (falls nicht), und um Feedback zum Produkt zu sammeln oder die nächsten Schritte und zukünftigen Prioritäten mit den Stakeholdern zu diskutieren.
Während der Sprint-Planung arbeitet das Scrum-Team an Folgendem zusammen:
Wenn das Scrum-Team seine Arbeit während des Backlog Refinements erledigt hat und während des Sprint Plannings richtig zusammenarbeitet, dann gibt es für einen Product Owner keinen Platz, um Arbeit zu „bestehen“ oder „nicht zu bestehen“. Es ist einfach weder Teil des Frameworks noch eine akzeptable Praxis.
Was hier wirklich passiert, ist, dass der Product Owner, Stakeholder oder Mitglieder des Teams neue Arbeit entdecken, die zuvor nicht in der Backlog-Verfeinerung oder Sprint-Planung identifiziert wurde. Das ist großartig! Als Nächstes sollte neu entdeckte Arbeit zum Product Backlog hinzugefügt werden, damit der Product Owner sie verfeinern und als zukünftige Arbeit für einen anderen Sprint priorisieren kann.
Bei der iterativen Entwicklung tritt kein „Scope Creep“ auf, da neu aufgedeckte Arbeit oder neue Anforderungen die aktuelle Timebox-Iteration nicht grundlegend ändern können. Stattdessen werden sie zu Wasser auf der Mühle, da das Produkt im Laufe der Zeit schrittweise weiterwächst.
Die einzige Ausnahme ist, wenn etwas aufgedeckt wird, das das aktuelle Sprint-Ziel gefährdet. Wenn das Sprint-Ziel nicht erreicht werden kann, es sei denn, das Team kehrt zum Reißbrett zurück, sollte der Product Owner den gesamten Sprint vorzeitig beenden und zur Sprint-Planung zurückkehren. Dies hat sichtbare Kosten für das Projekt (sichtbar ist gut; Kosten, nicht so viel), daher ist es im Allgemeinen am besten, neue Arbeit als zukünftige Arbeit zu behandeln, es sei denn, die Auswirkungen sind hoch genug, um die Kosten zu rechtfertigen. Das ist die Entscheidung des Product Owners, und diese Entscheidung zu treffen, ist ein grundlegender Teil ihrer Arbeit.
Darüber hinaus wird Arbeit entweder getan oder nicht getan . Wenn es in Übereinstimmung mit dem Plan des Teams erledigt, in Übereinstimmung mit der Definition of Done abgeschlossen und innerhalb des aktuellen Zeitrahmens demonstriert wurde, dann gibt es keine Möglichkeit, die Arbeit „nicht bestanden“ oder „abzulehnen“. Das Team baute das Ding, an dem alle mitarbeiteten und das es benötigt wurde, einschließlich des Product Owners.
Wenn sich später herausstellt, dass das Scrum-Team das Falsche gebaut hat , dann ist das ein Kooperations- oder Kommunikationsproblem, das in der Sprint-Retrospektive angesprochen werden sollte. Die Behebung des Prozessproblems erfordert wahrscheinlich eine engere Zusammenarbeit mit Nicht-Team-Stakeholdern sowohl durch den Product Owner als auch durch die Mitglieder des Entwicklungsteams.
Auf der anderen Seite, wenn das Team einfach neue Arbeit oder den Bedarf an zusätzlichen Verfeinerungen aufgedeckt hat, dann ist das großartig! Das ist es, was agile Frameworks tun sollen. Die neue Arbeit kann wie jede andere Arbeit innerhalb des Frameworks priorisiert und geplant werden.
Todd A. Jacobs
Ruan