Ich probiere Scrum in einem kleinen Ein-Personen-Projekt aus. Während meines ersten Sprints wurde mir klar, dass alle von mir ausgewählten Geschichten wirklich episch sind und in viel kleinere Stücke zerlegt werden sollten. Das Problem ist, dass ich zu wenige Story Points ausgewählt habe, dh eine Aufteilung würde bedeuten, dass ich Storys von 0,25, 0,1 Story Points der ursprünglichen Epics habe.
Mein Instinkt sagt mir, die Epen nach dem Sprint aufzuschlüsseln und neu zu schätzen. Da dies der erste Sprint ist, werden historische Daten nicht durcheinander gebracht und ich kann von Null anfangen.
Was denken Sie?
Bevor ich antworte, sollte ich darauf hinweisen, dass ich die Schätzung und Geschwindigkeit von Scrum, wie es traditionell gemacht wird, wirklich hasse, also, während dies Ihnen einige Ideen geben könnte, fühlen Sie sich frei, Ihren bestehenden Prozess entsprechend anzupassen.
Der Grund, warum Sie „Epics“ in kleinere Storys und Features aufteilen müssen, ist, dass sie nicht in die Timebox eines Sprints passen. Es gibt nur wenige Gründe, Timeboxes zu schätzen und zu verwenden:
Stakeholder-Feedback einholen
Sie müssen die Dinge nicht aufschlüsseln, um Feedback zu erhalten, wenn Sie sich nur darauf konzentrieren, etwas zu tun, das das Feedback der Stakeholder einholt. Wählen Sie aus, wozu Sie Ihrer Meinung nach Feedback benötigen, bringen Sie dann etwas zum Laufen und machen Sie es innerhalb der Timebox immer realistischer (und wenn Sie frühzeitig Feedback erhalten können, umso besser!). jemand, dann bringe ich es mit einer Hash-Karte im Speicher zum Laufen, dann koppele ich es mit den Persistenzschichten und von dort der Datenbank ( wenn die Benutzer sowieso die Interessengruppen sind, die mir am besten Feedback geben können).
Vertrauen der Stakeholder gewinnen
Wenn Ihre Stakeholder Ihnen nicht vertrauen, konzentrieren Sie sich darauf, etwas Wertvolles zu liefern . Möglicherweise müssen Sie Ihre „Epics“ aufteilen, um dies zu tun, aber dies sollte Ihr Fokus sein, anstatt „etwas innerhalb des Sprints zu erledigen“. Wenn dies der Fall ist, wählen Sie kleine, sichere Dinge, die Sie einfach und schnell erledigen können, denn Ihre Beziehung zum Stakeholder ist wahrscheinlich das größte Risiko. Nachdem Sie ihr Vertrauen gewonnen haben, können Sie anfangen, die kniffligen Dinge auszuprobieren und ihr Feedback einzuholen.
Releaseplanung und Umfangsanpassung
Wenn Sie den Umfang basierend auf der Historie anpassen möchten, können Sie dies jederzeit mit den ursprünglichen „epischen“ Schätzungen tun. Dies sind Schätzungen, daher sind sie wahrscheinlich falsch; Sie können eine kleine Auswahl davon nicht verwenden, um die Zukunft vorherzusagen, daher wird die Umfangsanpassung wahrscheinlich kontinuierlich sein und kleiner werden, wenn Sie sich der Veröffentlichung nähern. (Idealerweise erstellen Sie ein Minimum Viable Product und veröffentlichen es trotzdem, daher ist dieser Punkt strittig).
Unsicherheit und Missverständnisse entdecken
Wenn Sie Schätzungen verwenden, um Missverständnisse aufzudecken, können Sie dennoch einige übersehen. Ich schlage vor, stattdessen durch Beispiele zu sprechen, wie die Anwendung funktionieren könnte, a la BDD.
Teilen Sie sie nach und nach auf
Anstatt sich darauf zu konzentrieren, genügend kleine Storys für einen Sprint zu haben, finden Sie es möglicherweise sinnvoller, sich auf die Gründe für den Sprint überhaupt zu konzentrieren. Woran auch immer Sie als Ergebnis arbeiten, bringen Sie es an die Tafel, und das Leben wird mit kürzeren Planungsmeetings viel einfacher.
Es kann hilfreich sein, wenn Sie herausfinden, ob es sich bei Ihren „Epics“ um Fähigkeiten handelt (bietet beispielsweise die Möglichkeit, mit Kupfer zu handeln) oder um Funktionen (eine von potenziell vielen konkreten Benutzeroberflächen, die die Fähigkeit bieten). Das Aufteilen von Fähigkeiten in Funktionen und das Skizzieren einiger Wireframes vor dem Sprint ist meiner Meinung nach in Ordnung. Lassen Sie danach dem Entwicklerteam die Freiheit, die Geschichten nach eigenem Ermessen aufzuteilen, basierend auf den oben genannten Prinzipien. Dies wird Ihnen auch helfen, ein selbstorganisiertes Team zu bekommen, und gibt dem Team einen klaren Fokus für jede Timebox.
Craig Larman sagte mir, dass der ursprüngliche Grund für monatelange Sprints darin bestand, dass man sich tatsächlich auf kleine Releases konzentrieren konnte, wobei nur die verschiedenen MVPs vom Unternehmen priorisiert wurden. Feedback war die ganze Zeit verfügbar, und wie viel innerhalb dieses Monats erreicht und veröffentlicht werden konnte, lag vollständig beim Entwicklerteam. Ich denke, diese ursprüngliche Vision von Scrum wurde beschädigt und wird sehr vermisst.
Wenn Sie daran denken, Ihre Geschichten in Aufgaben aufzuteilen, lesen Sie bitte auch dies .
Epics werden immer in kleinere Teile zerlegt, bevor der Sprint beginnt. Versuchen Sie, sich darauf zu konzentrieren , Wert zu liefern (vom Kunden gefordert und auch wichtig), also kümmern Sie sich nicht um Ihre historischen Daten. Wenn das Epos am wichtigsten ist, zerlegen Sie es und beginnen Sie, daran zu arbeiten. Nach ein paar Sprints haben Sie genug Erfahrung und Daten, um die Geschwindigkeit zu ermitteln und zu nutzen.
Planen Sie einen abgeschlossenen Sprint nicht neu. Stattdessen:
Behandeln Sie Datenanomalien als solche und lassen Sie nicht zu, dass sich Ihr Scrum-Framework um Datenpunkte dreht, die nicht als strenge Vorgaben oder unfehlbare Vorhersagen gedacht sind.
Während meines ersten Sprints wurde mir klar, dass alle von mir ausgewählten Geschichten wirklich episch sind und in viel kleinere Stücke zerlegt werden sollten.
Wenn es dein erster Sprint ist, lernst du noch Geschichten einzuschätzen und deine eigene Kapazität einzuschätzen, daher ist mit Schätzfehlern zu rechnen. In Ihrem speziellen Fall haben Sie jedoch zwei Möglichkeiten:
Hier geht es weniger um die Story-Point-Zuordnung als vielmehr um die Entscheidung, ob Sie Ihre Kapazität für den Sprint richtig eingeschätzt haben. Wenn Sie denken, dass Sie genug Geschichten schreiben können , um Ihr Sprintziel zu erreichen, dann versuchen Sie es.
Scrum erfordert keine Perfektion; es erfordert lediglich, dass Sie prüfen und sich anpassen und frühzeitig scheitern, wenn ein Scheitern unvermeidlich ist. Wenn Sie in diesem Sprint Wert liefern können, machen Sie es – und verwenden Sie dann das, was Sie in diesem Sprint gelernt haben, um Ihren Schätzungs- und Planungsprozess beim nächsten Mal zu verfeinern. Lässt sich während des Sprints kein Wert ableiten, dann ist eine vorzeitige Beendigung sicherlich angebracht.
Wenn Sie mit einer großen Geschichte oder einem Epos konfrontiert sind, können Sie die Geschichte im Sprint Backlog sicherlich in Aufgaben der richtigen Größe aufteilen. Sie erhalten nur Punkte für Product Backlog-Storys, die Sie bis zum Ende des Sprints abschließen, aber die Zerlegung einer Story in Aufgaben hat mehrere Vorteile:
Scrum erfordert nicht, dass Sie alle Storys während des Sprints abschließen, obwohl dies offensichtlich eines der Ziele ist. Das eigentliche Ziel ist es, das Sprintziel zu erreichen. Wenn Sie Ihre Storys im Sprint-Backlog richtig zerlegen, stellen Sie möglicherweise fest, dass Sie eine oder mehrere Storys fertigstellen können, die das Sprint-Ziel erreichen, obwohl Sie nicht alle User Stories abgeschlossen haben. Das wäre ein Gewinn!
Mein Instinkt sagt mir, die Epen nach dem Sprint aufzuschlüsseln und neu zu schätzen. Da dies der erste Sprint ist, werden historische Daten nicht durcheinander gebracht und ich kann von Null anfangen.
Bitte tun Sie dies nicht. Wenn Sie dies tun, sind Sie bereits auf dem Weg, Geschwindigkeit als Managementziel und nicht als Kapazitätsplanungstool oder WIP-Grenze zu behandeln.
Überprüfen Sie auf jeden Fall Ihren Backlog-Grooming- und Sprint-Planungsprozess und sehen Sie, wo Ihre Einschätzung – und vielleicht noch wichtiger, Ihr Prozess zur Auswahl einer angemessenen Anzahl von Storys aus dem Product Backlog – schief gelaufen ist. Dies ist eine wertvolle Anwendung des Sprint-Retrospektiv-Prozesses.
Die nachträgliche Neuschätzung oder Neuplanung Ihres Sprints ist jedoch Zeitverschwendung – es sei denn, Sie haben Ihren Sprint vorzeitig beendet und sind zur Sprint-Planung zurückgekehrt. Wenn Sie das nicht tun, behalten Sie Ihre Datenpunkte und fahren Sie mit dem Prozess fort.
Am Ende eines Sprints liefern Ihnen Ihr Sprint-Backlog, Story-Schätzungen und Burn-Down-Diagramme Daten zur Überprüfung Ihres Prozesses. Diese Daten umfassen im Allgemeinen:
Eine Story-Schätzung ist nur ein einzelner Datenpunkt mit ein paar damit verbundenen Interpretationen. Wenn es sich um ungültige Daten handelt, können Sie sie verwerfen. In Ihrem Fall kann es sich jedoch durchaus um gültige Daten handeln, in dem Sinne, dass sie ein zugrunde liegendes Prozessproblem genau widerspiegeln, das sich auf die Produktivität Ihrer aktuellen Scrum-Implementierung auswirkt. Wenn das der Fall ist, dann behalte den Datenpunkt!
Die Schätzung erfordert naturgemäß mehr Erfahrung und einen größeren Datensatz, als Sie in einem einzigen Sprint gewinnen können. Wenn Sie es nicht schaffen, Ihren Prozess im Laufe der Zeit zu korrigieren, wird Ihr einzelner Datenpunkt schließlich zu einem statistischen Ausreißer . Wikipedia sagt:
Einige Datenpunkte werden weiter vom Stichprobenmittelwert entfernt sein, als als vernünftig erachtet wird. Dies kann auf zufällige systematische Fehler oder Fehler in der Theorie zurückzuführen sein, die eine angenommene Familie von Wahrscheinlichkeitsverteilungen erzeugt haben, oder es kann sein, dass einige Beobachtungen weit vom Zentrum der Daten entfernt sind. Ausreißerpunkte können daher auf fehlerhafte Daten, fehlerhafte Verfahren oder Bereiche hinweisen, in denen eine bestimmte Theorie möglicherweise nicht gültig ist. Bei großen Stichproben ist jedoch mit einer geringen Anzahl von Ausreißern zu rechnen (und dies nicht aufgrund einer anomalen Bedingung).
Mit anderen Worten, eine Sprint-Planungssitzung liefert nützliche Ausreißer, wenn:
Dies sind alles wertvolle Informationen für den Inspektions- und Anpassungsprozess. Lernen Sie aus der Erfahrung und verwerfen Sie dann entweder die Ausreißer oder bewahren Sie sie für zukünftige Analysen auf. Letztendlich ist Ihre Wahl in dieser Angelegenheit genau das und wirkt sich nicht so sehr auf die Wirksamkeit des Gesamtrahmens aus, wie Sie vielleicht denken.
Einige wirklich gute Punkte hier - lassen Sie mich noch ein oder zwei Cent werfen.
Erstens machen Sie Scrum nicht wirklich, wenn Sie eine Person sind, die als Product Owner, Scrum Master und das Entwicklungsteam fungiert. Um den Scrum-Leitfaden zu zitieren: „Die Rollen, Artefakte, Ereignisse und Regeln sind unveränderlich.“ Es ist keine schlechte Sache, ich mache selbst agile Entwicklung – nehme viele Hinweise von Scrum und arbeite in einem Zwei-Personen-Team – auf zwei Plattformen; Also, wirklich, es ist nur ich für meine Plattform.
Die ideale Größe eines Teams beträgt laut der Bewertung, die Sie bei Scrum.org vornehmen können und die im Leitfaden impliziert wird, 6 +/- 3. Laut dem Leitfaden verlieren Sie eine Vielfalt an Wissen, wenn Sie unter 3 Entwickler fallen, und wann Wenn Sie über 9 kommen, erhöhen Sie das Potenzial für die Bildung von Unterteams und die Verringerung der Kommunikation zwischen den Teams.
Story Points sind nur eine Methode, um den für eine bestimmte Story/Aufgabe erforderlichen Aufwand abzuschätzen, was eine gängige Praxis ist, aber nicht Teil des Scrum-Frameworks ist. Schließlich ist Scrum als Framework ziemlich locker und ermöglicht es Ihnen, alles zu tun, was Sie tun müssen, um die Arbeit zu erledigen ... all die anderen Dinge wie Geschichten und Epics, Story-Point-Schätzung anstelle von Stunden usw. sind hübsch viel persönliche Präferenz (laut den ursprünglichen Gründern).
Okay, technische Details beiseite, jetzt zum eigentlichen Kern Ihrer Frage, der Zerstäubung und Schätzung der Arbeit.
Es hört sich so an, als hätten Sie ein Problem mit der Rückstandspflege – verbunden mit einem Problem mit der Schätzmethode. Wenn Sie unbedingt darauf bestehen, Story Points zu verwenden, ist eine Idee, die einfachste Story zu finden, die Sie finden können – das wird 1 – es ist eine bekannte Basis der Komplexität, mit der alle anderen Storys verglichen werden können. Persönlich bevorzuge ich immer noch zeitbasierte Schätzungen - aber, ganz nach Ihrer Wahl, akzeptieren Sie einfach, dass die Chancen stehen: (1) Sie werden sich irren; (2) wenn sich Ihre Definition von erledigten Änderungen/Verbesserungen ändert, steigt der Aufwand für den technischen Abschluss einer Level-1-Story im Verhältnis zu Zeit und Komplexität, aber Sie werden den tatsächlichen Wert nicht ändern; und (3) mit fortschreitender Entwicklung eines Projekts werden Ihre Schätzungen in ihrer Unrichtigkeit zunehmen, wenn sie nicht vor jeder Iteration angepasst werden.
Dieser letzte Punkt ist ein Aspekt des Abrutschens in einen „hyperproduktiven“ Zustand, der wirklich unsere Unfähigkeit ist, die Entwicklung unseres Systems vorherzusagen und wie die Teile schließlich zusammenpassen und plötzlich ein Ticket im Wert von 500 (geschätzt auf 30 Tage) verursachen. um auf etwa 100 (6 Tage) zusammenzubrechen.
In Bezug darauf, wie man einen Rückstand aufbaut und pflegt – ich neige dazu, hoch anzufangen und auf einen ganzen Tag zu atomisieren, um etwas von Anfang bis Ende zu erledigen. In meiner Praxis bedeutet dies also, dass eine Story-/Anforderungsschätzung 8 Stunden oder weniger betragen muss, einschließlich des Schreibens von Unit-Tests, codiert, umgestaltet, dokumentiert und (optional) von jemand anderem überprüft (ziemlich schwierig bei einer Ein-Personen-Operation). Was in der Regel zu so etwas wie einem WBS mit „Build Fantabulous Product“ an der Spitze führt, das dann zerlegt, auf wiederverwendbare Bereiche überprüft wird usw. usw.
Wenn Sie sich für den Sprint zu viel vorgenommen haben und nicht alle Elemente vor dem Ende der Timebox abschließen können, muss der SM – Sie müssen den PO informieren – und dann muss der PO entscheiden, ob Sie den Sprint aufgeben möchten Sprint oder nicht, basierend auf allen Informationen, die von externen Stakeholdern und dem Rest des Teams erhalten wurden (weil nur der PO einen Sprint abbrechen kann). Machen Sie sich keine Sorgen um die Gültigkeit der historischen Daten – es ist Ihre erste Iteration, und Sie müssen zwei oder drei weitere durchführen, bevor Sie genügend Datenpunkte haben, um überhaupt in Erwägung zu ziehen, sie auf „wissenschaftliches“ Verbesserungspotenzial zu überprüfen.
Lassen Sie mich abschließend auf das Agile Manifest zurückkommen und sagen, verzetteln Sie sich nicht in den Prozessen (Scrum, XP usw.) und den Tools (Storys, Epics, Story Points, Burn-Down-Charts usw.) - und konzentrieren Sie sich auf die Interaktionen, die Sie mit Ihrem Team haben (auch wenn es eine Art virtuelles Team unter Ihren Stacker-Kollegen ist), und fühlen Sie sich frei, den Plan aufzugeben (den Sprint abzuschließen, weil Sie die Arbeit geplant und sich der Arbeit verschrieben haben) – das ist vollkommen akzeptabel - Besser anhalten und eine neue Richtung wählen, als weiter in die falsche Richtung zu gehen, nur weil Sie es gesagt haben.
Scrum-Leitfaden http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf#zoom=100
Selbstorganisation: Jeff Sutherland http://www.youtube.com/watch?v=M1q6b9JI2Wc
Scrum-Framework: Lyssa Adkins http://www.youtube.com/watch?v=_BWbaZs1M_8
Scrum ua: Ken Schwaber http://www.youtube.com/watch?v=IyNPeTn8fpo
Agiles Manifest: http://agilemanifesto.org
Denken Sie daran, dass SCRUM-Teams aus 7 Personen +/-2 bestehen sollten, sodass Sie es möglicherweise umständlich finden, in einem Ein-Mann-Team zu planen, zu schätzen, die Geschwindigkeit zu berechnen, der SM zu sein usw.!
Andreas klar