Verpflichten des Product Owners zu einem Sprint Backlog mit einem Vertrag

TL;DR Nein, denn das, was Sie beschreiben, ist nicht streng Scrum – Sie sollten den Prozess reparieren, anstatt eine Problemumgehung zu erfinden. Der PO kann das Product Backlog ändern, aber nicht das Sprint Backlog. Wenn das Team mit der erforderlichen Änderung nicht einverstanden ist oder sie nicht umsetzen kann, ohne den Sprint zu gefährden, kann PO den Sprint abbrechen (und alle damit verbundenen Kosten übernehmen) oder es sein lassen und eine neue Story in das Produkt-Backlog aufnehmen, um die Änderungen anzugehen .

Gibt es ein Beispiel für ein solches Dokument in der Scrum-Literatur, auf das ich verweisen kann?

Das Hauptdokument für Sie ist ein Scrum Guide ( http://www.scrumguides.org/scrum-guide.html ). Ich werde im Folgenden mehrfach darauf verweisen.

Das Problem ist: Obwohl sie die Regeln kennen, den Sprint-Backlog während eines Sprints nicht zu ändern, ändern die meisten von ihnen den Backlog mindestens einmal pro Sprint.

Laut der Anleitung,

Während des Sprints:

• Es werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden;
• Qualitätsziele nehmen nicht ab; und,
• Der Umfang kann geklärt und zwischen dem Product Owner und dem Entwicklungsteam neu verhandelt werden, wenn mehr erfahren wird.

und

Nur das Entwicklungsteam kann sein Sprint Backlog während eines Sprints ändern.

Wenn die von PO geforderte Änderung das Sprintziel gefährdet, sollte sie nicht akzeptiert werden. Dafür sind Sie als Scrum Master zuständig. Ihr Backup im Gespräch mit dem POS ist der Scrum Guide.

Sie scheinen/wollen nicht verstehen, dass dies Auswirkungen auf die Arbeit hat, die wir während eines Sprints erledigen können.

Das ist Ihre Aufgabe als Scrum Master, es ihnen zu erklären. Wahrscheinlich verstehen sie tatsächlich, dass es Ihre Arbeit beeinflusst, schenken ihm aber nicht genug Aufmerksamkeit.

Nun dachten wir, es wäre eine gute Idee, den Product Owner einen Sprint-Release-Vertrag unterschreiben zu lassen, der Eckdaten, das Sprint-Backlog und Definitionen von Done enthält.

Nein. Nein und nein. Nochmals vom Führer

Wenn ein Product Backlog-Eintrag oder ein Inkrement als „Done“ bezeichnet wird, muss jeder verstehen, was „Done“ bedeutet. Obwohl dies je nach Scrum-Team sehr unterschiedlich ist, müssen die Mitglieder ein gemeinsames Verständnis davon haben, was es bedeutet, dass die Arbeit abgeschlossen ist, um Transparenz zu gewährleisten. Dies ist die Definition von „Fertig“ für das Scrum-Team und wird verwendet, um zu beurteilen, wann die Arbeit am Produktinkrement abgeschlossen ist.

Ihre Definition von erledigt ist ein Vertrag. Der Sprint selbst ist eine Zeitbox, die nicht geändert, sondern nur storniert werden kann.

Zusammenfassend sollten Sie mit dem PO arbeiten und die Regeln des Prozesses erklären, dem Sie zu folgen versuchen. Die Einführung zusätzlicher „Verträge“ zeigt einen Mangel an Transparenz und Vertrauen, und das sind die Dinge, die angegangen werden sollten.

Sprint-Verträge, wie Sie sie beschreiben, sollten nicht verwendet werden, da sie den Zweck von Scrum/Agile zunichte machen. Erledigen Sie stattdessen die Arbeit im Voraus, um sicherzustellen, dass das Projekt ordnungsgemäß ausgeführt werden kann. Dazu sollte (mindestens) Folgendes passieren

1. Stellen Sie sicher, dass der Kunde vor Projektbeginn ordnungsgemäß in Scrum geschult ist. Idealerweise beginnt dies bereits im Pre-Sales-/Sales-Prozess.

2. Formulieren Sie die Grundregeln der Liefermethodik in der Projektcharta. Stellen Sie sicher, dass der Auftraggeber weiß, dass er mit der Unterzeichnung des Projektauftrags seinen Segen dafür gibt, dass das Projekt gemäß dem Auftrag durchgeführt wird. Änderungen an der Charta sollten ein gewisses formelles Verfahren erfordern. Der Charter-Änderungsprozess und potenzielle Risiken von Charter-Änderungen sollten auch in der ursprünglichen Charter aufgeführt werden.

Nein, das ist keine gute Idee, da es einem der zentralen Agile-Prinzipien widerspricht :

Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel zum Wettbewerbsvorteil des Kunden.

Abbrechen eines Sprints :

Wenn die Änderungen so groß sind, dass sie die Sprintziele gefährden, sagen Sie dem Product Owner, dass er den Sprint abbrechen und einen neuen starten soll. Die Kosten sollten so sein, dass alle unerledigten Arbeiten verloren gehen, dafür sorgen, dass der Preis klar ist. Danach kann der PO entscheiden, den aktuellen Sprint fortzusetzen und zu beenden und die zusätzliche Arbeit auf den Rückstand zu setzen oder den Sprint zu stoppen und mit dem neu gewonnenen Wissen einen neuen zu starten.

Siehe auch Abbrechen von Sprints im Scrum-Leitfaden für weitere Informationen:

Der Sprint kann vor Ablauf der Sprint-Zeitbox abgebrochen werden. Nur der Product Owner hat die Befugnis, den Sprint abzubrechen, obwohl er oder sie dies unter dem Einfluss der Stakeholder, des Entwicklungsteams oder des Scrum Masters tun kann.

Kanban :

Vielleicht ist Scrum nicht das Ding für Ihre Kunden und sie bevorzugen mehr Flexibilität. Schauen Sie sich um und vergleichen Sie Scrum vs. Kanban . Konzentrieren Sie sich darauf, mit der Arbeit zu beginnen, bevor Sie neue Arbeiten aufnehmen, aber ändern Sie den kurzfristigen Auftragsbestand kontinuierlich, wie es den Anforderungen Ihrer Kunden entspricht.

Würde eine Verkürzung des Sprints dazu beitragen, die Ziele zu schützen, bedeutet dies natürlich mehr Planungsaufwand, gibt dem Kunden jedoch möglicherweise die erforderliche Flexibilität. Vielleicht gibt Ihnen eine Neuplanung in der Mitte des Sprints mehr Vorhersehbarkeit in Bezug auf spät anstehende Änderungen.

Verträge sind wahrscheinlich nicht der richtige Weg, wie bereits erwähnt wurde, da Agile Veränderungen begrüßt. Wenn die Sprint-Arbeit aufgeteilt wird, ist es möglich, genau festzulegen, was als Ergebnis nicht erledigt wird, und dies mit dem Kunden zu vereinbaren, wenn die Änderung eintrifft. Vielleicht mit einer Änderungsfrist, sagen wir 4-5 Tage vorher zu sprintende Dinge helfen könnte.

Systeme wie Scrum sind Konventionen, auf die sich Menschen geeinigt haben, um ein angemessenes Vertrauen in ihre (nahen) Zukunftserwartungen zu schaffen. Ein Sprint bietet effektiv eine angemessene Garantie/Vertrauen in das, was Sie am Ende des Sprints erwarten können.

Davon abgesehen können sich Pläne immer ändern. Wir können niemals ausschließen, dass der Kunde ein berechtigtes Anliegen hat, das es rechtfertigt, den geplanten Sprint durcheinander zu bringen. Beispielsweise müssen Ihre Entwickler möglicherweise dringend zu einer anderen Mission abberufen werden, die nicht vorhersehbar war, aber dennoch das aktuelle Entwicklungsziel übertrifft.

Technisch gesehen schreibt Scrum dies nicht vor. Es geht davon aus, dass ein Sprint in Stein gemeißelt ist und sich nicht ändert. Aber die Realität kann ganz anders aussehen. Und das ist völlig in Ordnung, allerdings auf Kosten der Erkenntnis, dass dies Auswirkungen auf den geplanten Sprint hat und somit die (nahen) Zukunftserwartungen nicht mehr hinreichend gewährleistet werden können.

Ich persönlich überlasse dies der Person mit der höchsten Autorität in dieser Diskussion. Der Sprint kann bei Bedarf vermasselt werden, aber nicht ohne zu akzeptieren, dass die während der Sprintplanung gemachten Garantien faktisch null und nichtig sind.

Eine kleine Ausnahme: Ich würde kleinere Dinge wie das Ändern einer Farbe zulassen, wenn Sie in Ihrem Sprint noch nicht einmal mit diesem Ticket begonnen haben oder wenn die Korrektur weniger Zeit in Anspruch nimmt, als zu erklären, warum Sie es nicht tun werden ( im übertragenen Sinne). Es hat keinen Sinn, sich über wirklich harmlose Dinge zu streiten, wenn ihre Auswirkungen vernachlässigbar sind.

Davon abgesehen könnte Ihre Situation anders sein. Beispielsweise ist die Person, die sich auf Ihren geplanten Sprint verlässt, möglicherweise nicht dieselbe Person, die jetzt fordert, dass der Sprint vermasselt wird. Das ist ein ganz anderes Problem, denn es erfordert zuerst, dass Sie die letztere Person an die erstere verweisen.

Ohne Genehmigung würde ich mir den Sprint nicht von Außenstehenden vermasseln lassen. Mit der Zustimmung können Sie auf den vorherigen Punkt verweisen, dass dies von Natur aus bedeuten muss, dass die Sprintziele null und nichtig sind.

Dies ist meine Ansicht darüber, wie man sich der Entwicklung im Allgemeinen nähert. Ich erwähne es, weil es hilft, die Punkte zu erklären, die ich im nächsten Abschnitt anspreche.

Ein Vertrag ist hier meiner Meinung nach nicht der richtige Weg. Es ist unnötig formell und wird eine defensive Haltung fördern. Sie können einen Sprint nicht so behandeln wie einen Festpreisvertrag (wo Sie tatsächlich genau so vorgehen: Unterschreiben Sie die angeforderte Arbeit und weichen Sie nie davon ab).

Was Sie hier versuchen, ist, Ihre individuellen Sprints zu einem Wasserfall zu machen, was nicht nur dem ursprünglichen Ziel von Scrum zuwiderläuft, sondern Sie auch in den Arsch beißen kann, wenn Sie aus irgendeinem Grund kein Ziel erreichen. Ein PO, der ziemlich gegen seinen Willen gezwungen ist, einen Vertrag zu unterzeichnen, selbst wenn er dem überhaupt zustimmt, wird wahrscheinlich Schadensersatz verlangen, wenn der gesamte Vertrag nicht geliefert wird. Willst du wirklich diese Knochen rollen?

Es können jedoch vertragliche Vereinbarungen zwischen Ihrem Unternehmen und dem Kundenunternehmen bestehen, die dies ersetzen. Wenn beispielsweise das Kundenunternehmen den gesamten Vertragsstecker ziehen wird, wenn Sie entweder ein Sprintziel nicht erreichen oder seinen Launen nicht folgen, ist dies eine Situation, die zum Scheitern verurteilt ist.

Wenn Ihr Unternehmen aus irgendeinem Grund nicht in der Lage ist, dieses Verhalten angemessen einzuschränken, müssen Sie möglicherweise ein Kommunikationsformat zwischen Ihrem Unternehmen und dem Kunden nachdrücklich durchsetzen – aber ich würde argumentieren, dass dies in diesem Stadium der Beziehung der Fall ist Vertrauenslosigkeit verkommen und Systeme wie Scrum oder Agile funktionieren in einer solchen Atmosphäre einfach nicht. Sie müssten fast zwangsläufig in einen Wasserfallansatz verfallen, bei dem jede Iteration bis zu einem fast legalen Grad rigoros definiert und vereinbart wird, bevor Sie mit der Arbeit daran beginnen.

Insgesamt möchte ich Sie dringend bitten, einen kooperativen Geist mit Ihrem PO zu fördern und ihm die Konsequenzen zu erklären, wenn er den Sprint durcheinander bringt; und wenn sie darauf bestehen, müssen sie der Annullierung der aktuellen Sprint-Ziele grundsätzlich zustimmen (dh sie erhalten eine Teilmenge, aber nicht die vollständige Menge der festgelegten Ziele).

Wenn sie dem nicht zustimmen, dann sollten Sie nichts zustimmen, was im Sprint nicht geplant war.

Wenn beide Optionen fehlschlagen und Ihr Unternehmen nicht in der Lage ist, sich einfach von diesem Kunden zu lösen und nach einem wirklich Scrum-freundlichen Kunden zu suchen, scheint Ihr letzter Ausweg darin zu bestehen, den Scrum-Ansatz zu beenden und sich stattdessen für einen Wasserfall-Ansatz zu entscheiden.