Wir arbeiten derzeit an einem Projekt, bei dem wir viele Änderungswünsche erhalten, und der Kunde besteht darauf, dass wir die Änderungen im aktuellen Sprint liefern sollen!
Kann ich die neue Arbeit als neue Aufgabe zum Sprint-Backlog hinzufügen? Manchmal ändert sich der Aufwand der Aufgaben, früher war es ein 18-Stunden-Job, aber jetzt ist es ein 32-Stunden-Job.
Wie kann ich diese Änderungen berücksichtigen, ohne ein seltsames Burndown-Diagramm zu erstellen? Ist es in Ordnung, Aufgaben zu einem laufenden Sprint hinzuzufügen?
Kann ich das als neue Aufgabe zum Sprint Backlog hinzufügen?
Ja, Sie können einem laufenden Sprint Storys hinzufügen, wenn das Team damit einverstanden ist. Es ist jedoch keine gute Praxis, da es die Nützlichkeit und Vorhersagefähigkeit der Methodik verringert.
Manchmal ändert sich der Aufwand der Aufgabe, wie früher war es ein 18-Stunden-Job, jetzt ist es ein 32-Stunden-Job
Das ist relativ unwichtig: Stories werden deshalb nicht in Stunden, sondern in Punkten gemessen: Die Zeitschätzungen können während des Sprints variieren. Das heißt, Sie müssen nur die verbleibende Zeit im Auge behalten , nicht die verstrichene Zeit .
Wenn Sie der Meinung sind, dass Geschichten als einfach eingeschätzt wurden und mit zunehmender Entwicklung des Sprints komplexer werden, gibt es möglicherweise einige zugrunde liegende Probleme:
Hatten Sie während des Planungstreffens genügend Informationen, um die Geschichte richtig einzuschätzen? Mit anderen Worten, ist der Umfang konstant geblieben, aber die Komplexität der Aufgabe höher als prognostiziert?
Haben Sie die ursprüngliche Story richtig eingeschätzt, aber der Kunde hat seine Meinung während des Sprints geändert? Wenn sie dies getan haben, weil sie berechtigterweise ihre Meinung geändert haben, sollten Sie die Geschichte aufgeben und eine neue beginnen. Wenn sie stattdessen Umfang hinzufügen, sollten Sie dafür neue Geschichten zum Backlog hinzufügen .
Wie kann ich diese Änderungen berücksichtigen, ohne ein seltsames Burndown-Diagramm zu erstellen? Ist es in Ordnung, Aufgaben zu einem laufenden Sprint hinzuzufügen?
Ja, Burndown-Diagramme können manchmal nach oben statt nach unten gehen. Es ist aber wahrscheinlich nicht etwas, was Sie wollen!
Alles in allem - das sind die Grundregeln, an denen Sie sich orientieren sollten:
Nur das Team kann neue Stories in einem Sprint annehmen . Sie können ihnen nicht aufgezwungen werden. Dies widerspricht einfach den grundlegenden agilen Prinzipien.
Neuer Umfang sollte immer eine neue Geschichte sein.
Eine neue Story kann einem Sprint hinzugefügt werden, wenn Sie eine entsprechend große Story herausnehmen (die neue Story muss vom Team geschätzt werden, und das Team muss diese Änderung als machbar akzeptieren).
Ein deutlich veränderter Sprint kann abgebrochen werden. Sie können den Sprint stoppen und mit einem neuen Planungsmeeting von Grund auf neu beginnen. Versuchen Sie natürlich, dies zu vermeiden, wenn Sie können.
Wenn neue Informationen auftauchen, könnte das Team feststellen, dass es länger (oder kürzer!) dauern wird, eine Geschichte zu entwickeln. Dies wird erwartet. Story Points ändern sich nicht, verbleibende Stunden ändern sich.
Wenn neue Informationen auftauchen, stellt der Product Owner möglicherweise fest, dass er mehr Geschichten (oder weniger!) benötigt als ursprünglich angenommen. Dies wird erwartet. Fügen Sie ungestraft Geschichten aus dem Backlog hinzu oder entfernen Sie sie. Fügen Sie Storys nur dann zum Sprint hinzu oder entfernen Sie sie aus dem Sprint, wenn das Team der Änderung zustimmt und sich dazu verpflichtet.
Wir arbeiten derzeit an einem Projekt, bei dem wir viele Änderungswünsche erhalten, und der Kunde besteht darauf, dass wir die Änderungen im aktuellen Sprint selbst liefern sollen!
Dies ist ein Zeichen dafür, dass Sie Scrum falsch machen. Während es sicherlich Grenzfälle gibt, in denen Storys zum Sprint hinzugefügt oder daraus entfernt werden können oder wenn das Sprint Backlog Aufgaben erhält oder verliert, die zum Erreichen des aktuellen Sprintziels erforderlich sind, ist das hier nicht wirklich das Problem. Stattdessen scheint das Problem zu sein, dass der Kunde nicht über den Product Owner arbeitet, um den Fortschritt zu überprüfen und den Umfang an den vom Framework definierten Wendepunkten anzupassen:
Stakeholder sollten den Umfang innerhalb des aktuellen Sprints nicht ohne die aktive Mitarbeit des Product Owners und eine ausdrückliche vorzeitige Beendigung des aktuellen Sprints ändern dürfen. Ein Verstoß gegen dieses Prinzip führt zu unsichtbarer Arbeit und nicht erfasstem Overhead für das Projekt, was ein großes Tabu ist.
Das soll nicht heißen, dass das Entwicklungsteam nicht mit den Stakeholdern oder einem in einer User Story definierten Endbenutzer zusammenarbeiten kann, um eine In-Sprint-Story zu klären oder Einblicke in die optimale Implementierung eines Features zu erhalten, aber solche Interaktionen sollten es nicht den Umfang ändern oder das während der Sprint-Planung definierte Sprint-Ziel kompromittieren.
Der Product Owner und der Scrum Master müssen mit den Stakeholdern zusammenarbeiten, um die Integrität des Sprints durchzusetzen und sie darüber aufzuklären, wann (und wie) Änderungen am Projektumfang innerhalb des Scrum-Frameworks vorzunehmen sind.
Das Ideal
Alle Anforderungen sind vollständig vorhersehbar. Indem Sie im Voraus genügend Analysen durchführen, wird zusätzliche Arbeit entdeckt, bevor der Sprint beginnt. Eine genaue Schätzung wird daher möglich sein, und diese Frage wird sich nie stellen.
Die Realität
Teile Ihres Projekts werden neue Dinge sein, die Sie noch nie zuvor gemacht haben (andernfalls wäre es genau dasselbe Projekt, das Sie zuvor gemacht haben, und das passiert nie). Entdeckungen sind unvermeidlich, sowohl in der Analyse als auch in der Entwicklung. Sie können Dinge nicht schätzen, die Sie noch nie zuvor getan haben, und der Versuch, dies zu tun, führt normalerweise zu Schwierigkeiten und / oder zu einer Auffüllung der Schätzung.
Was ist dagegen zu tun
Erkenne, dass es in der Entwicklung immer Ungewissheit gibt, und sei erwachsen damit. Am Ende des Sprints können Sie sich darauf konzentrieren, Feedback von Ihren Stakeholdern zu erhalten, und dieses Feedback ist weitaus wichtiger als jede Story-Point-Schätzung.
Streitigkeiten über diese Entdeckungen führen oft dazu, dass Menschen mehr Zeit damit verbringen, die neuesten und riskantesten Elemente eines Projekts im Voraus zu analysieren. Die Analyse ist nicht so gut darin, diese Entdeckungen auszuräumen, wie es tatsächlich der Fall ist, etwas zu liefern (oder Wasserfallmethoden würden funktionieren). Wenn diese Entdeckungen gemacht werden, ist es also sehr wichtig, sich auf die Lieferung und das Feedback zu konzentrieren.
Andernfalls setzt die Analyseparalyse ein, und diese Elemente werden stattdessen ans Ende des Projekts verschoben, wenn keine Zeit bleibt, auf sie zu reagieren.
Der Zweck der Schätzung und Geschwindigkeitsmessung ist dreifach:
Pure Scrum schreibt keine Story Points und Geschwindigkeitsmessungen vor. Anstatt Versprechungen rund um Punkte zu machen, ziehen Sie es in Betracht, Versprechungen zu Aspekten der Bedürfnisse von Stakeholdern zu machen, zu denen Sie etwas zum Zwecke des Lernens und Feedbacks liefern oder präsentieren werden. Indem Sie sich frühzeitig mit den riskantesten Aspekten eines Projekts befassen, lernen Sie schnell, minimieren das Projektrisiko (und helfen, genauere Pläne zu erstellen) und gewinnen das Vertrauen der Stakeholder, indem Sie die Dinge ansprechen, die sie nachts nicht schlafen lassen.
Unter keinen Umständen sollten die Story Points dazu verwendet werden, das Team zu „bestrafen“. Das wird nur zu einer Kluft zwischen dem PO und anderen Teammitgliedern führen, und der PO sollte Teil desselben Teams sein.
Wenn Sie nach einem Nachverfolgungsmechanismus suchen und die Umfangsänderungen regelmäßig stattfinden, sollten Sie stattdessen ein Burn-up- Diagramm oder CFD in Betracht ziehen. Auf diese Weise können Sie Ihre Arbeit längerfristig mit dem Geltungsbereich vergleichen und auch sehen, wie sich der Geltungsbereich selbst ändert.
Es gibt einige Möglichkeiten, ungeplante Arbeit während eines Sprints zu bewältigen. Als agiler Praktiker haben Sie eine Reihe von Ansätzen. Idealerweise bestimmt das Entwicklungsteam, was während eines Sprints getan werden kann und was nicht. Wenn jedoch ein von der Bestellung aufgeworfenes Problem in den Sprint eingefügt werden muss, können Sie Folgendes tun:
1/ Absorbiere es.
2/ Brechen Sie betroffene Stories auf und übertragen Sie sie auf folgende Sprints
3/ Artikel ersetzen, um Geschwindigkeit anzupassen.
4/ Erstellen Sie ein Element „Ad-hoc-Ausgabepuffer“. Lässt unerwünschte POs oder komplexe Probleme zu, die erst nach Arbeitsbeginn vollständig bearbeitet werden können.
5/ Priorisierung verbessern (dh „Nein“ sagen).
6/ Identifizieren und entfernen Sie Abhängigkeiten (dh entfernen Sie Blocker aus dem Sprint, bis die Ursache behoben ist)
7/ Prozess an Kanban anpassen.
(Quelle: https://medium.com/agilelab/strategies-for-handling-unplanned-work-during-sprint-2f89697509ff )
Ich denke auf jeden Fall, dass Sie das Thema „Änderungswünsche des Kunden“ angehen müssen, vielleicht auf vertraglicher Ebene. Änderungen sind der Todfeind der Softwareentwicklung, insbesondere wenn diese Änderungen einfliegen, während das betroffene Stück geschrieben wird. Dem Kunden muss klar gemacht werden, dass eine solche undisziplinierte Herangehensweise ihn am Ende Geld kosten und die Stabilität des Produkts, auf das er sich verlassen möchte, gefährdet.
In meiner frühesten Beraterzeit las ich ein Buch über Beraterverträge des verstorbenen Hermann Holtz (geborene „Hermann Holz“), in dem er einen Rahmenvertrag und Aufgabenaufträge beschrieb. Die Arbeit sollte ausgeführt werden, indem Aufgabenaufträge erstellt, die Genehmigung des Kunden für jeden einzelnen eingeholt, Kosten dafür angehängt und dann der Auftrag ausgeführt wurden. Ich benutze dieses System seit über dreißig Jahren mit großem Erfolg.
(Der Herr hat eine Reihe ausgezeichneter Bücher geschrieben. Ich empfehle sie.)
Der entscheidende „Gewinn“ besteht darin, dass der Änderungsanforderungsprozess in den Augen des Kunden formalisiert und mit „Geldausgaben“ verknüpft wird. Der Prozess, diesen Auftrag zu definieren, bis zu dem Punkt, an dem der Kunde seinen John Hancock dazu bringen muss, ist an und für sich äußerst wertvoll. Es reduziert auch die Wahrscheinlichkeit von Missverständnissen erheblich. Ich habe immer höflich klargestellt: „Ihre Unterschrift ist eine verbindliche Vollmacht, die Arbeiten wie beschrieben auszuführen. Sollten Sie es sich anders überlegen, ist das ein weiterer Auftrag.“
Ich habe die meisten meiner Aufträge durch Empfehlungen erhalten, und mehrere potenzielle Kunden sagten, dass sie von meiner Beratung angezogen wurden, weil wir ein Aufgabenauftragssystem verwendeten. Ich weiß, dass dies der Schlüssel zu unserer langfristigen Rentabilität war.
Bauunternehmer und andere Hersteller von materiellen Dingen wenden diese Praktiken routinemäßig an. Sie gelten gleichermaßen für den Bau von immateriellen Dingen wie Computersoftware, die weitaus komplizierter sind.
Pawel Polaczyk
Harisch