Wir haben eine „schwere“ Geschichte, die nicht in kleinere Geschichten zerlegt werden kann. Es wird mehrere Sprints umfassen.
Wir können die Geschichte gut in Aufgaben zerlegen, aber Aufgaben scheinen Abstraktionen zu sein, die nur wenige Stunden lang sind.
Was wir brauchen, ist eine Abstraktion, die jeden Sprint vorantreibt – mit einem gut definierten Ergebnis (ähnlich einer Story, aber intern), Punktschätzung usw. Was ist kleiner als eine Story, aber größer als eine Aufgabe? Wie wird so etwas normalerweise gehandhabt?
In den Fällen, in denen dies mit meinen Teams passiert ist, suchen wir nach den kleinsten testbaren Slices, die wir herstellen können, selbst wenn wir wissen, dass wir sie nicht veröffentlichen würden. Zum Beispiel haben wir uns mit einem Drittanbieter zusammengeschlossen und wollten eine einmalige Anmeldung zwischen ihm und unserer Website durchführen. Unsere Geschichte war:
In order purchase products on the 3rd party site
As a registered customer
I want to log in using my existing information
Es ist ziemlich schwer zu knacken, also hat es immer noch einen Kundenwert, aber es waren ein paar Wochen Aufwand erforderlich, um das Single Sign-On zum Laufen zu bringen - weitaus größer, als wir in einem Sprint akzeptieren würden.
Am Ende hatten wir eine Reihe kleinerer Geschichten, die zwar recht technisch waren, aber alle zu einem Ergebnis führten, das wir einem nicht-technischen Product Owner vorführen konnten. Um dorthin zu gelangen, haben wir uns angesehen, welche Schritte das Team unternehmen musste, um technisch dorthin zu gelangen, und festgestellt, wo es Ergebnisse gab, die der PO gerne verifizierte.
Wir hatten jedoch immer noch ein paar große Brocken ohne überprüfbares Ergebnis. Um dies zu umgehen, haben wir eine Webseite in unserer App erstellt, die Dinge wie Benutzer-IDs, Benutzerrollen usw. ausgibt, die an den Drittanbieter weitergegeben werden, damit der Besteller sehen kann, dass die App etwas tut und trotzdem die richtigen Informationen erhält es tat noch nichts mit den Daten.
Wir haben auch die herausgebrochenen Geschichten, die Teil der großen Geschichte waren, farblich gekennzeichnet, damit wir den Fortschritt des gesamten Features auf unserem Board sichtbar gemacht haben.
Nicht ideal, aber das ist der beste Ansatz, den wir bisher geschafft haben.
Was wir brauchen, ist eine Abstraktion, die jeden Sprint antreibt[.]
Dies wird allgemein als Sprintziel bezeichnet. Das Sprint-Ziel ist ein wesentlicher (aber oft übersehener) Bestandteil erfolgreicher Scrum-Implementierungen.
Wir haben eine „schwere“ Geschichte, die nicht in kleinere Geschichten zerlegt werden kann. Es wird mehrere Sprints umfassen.
Das wird dir auf Dauer Schmerzen bereiten. Es kommt sehr selten vor, dass ein Epos nicht in Geschichten der richtigen Größe zerlegt werden kann, aber es kann passieren, wenn:
Ihre "schwere" Geschichte leidet wahrscheinlich unter mehr als einem dieser Problembereiche, und ich vermute, sie könnte als komplexe Geschichte eingestuft werden . In User Stories Applied Mike Cohn sagt:
Anders als die zusammengesetzte Story ist die komplexe Story eine User Story, die von Natur aus umfangreich ist und nicht einfach in eine Reihe von konstituierenden Storys zerlegt werden kann. Wenn eine Geschichte aufgrund der damit verbundenen Ungewissheit komplex ist, möchten Sie die Geschichte möglicherweise in zwei Geschichten aufteilen: eine investigative Geschichte und eine, in der das neue Feature entwickelt wird.
Mit anderen Worten, solche Stories können sicherlich zerlegt werden, aber die richtige Stufe der Zerlegung kann zunächst Änderungen an der Art und Weise erfordern, wie Sie Stories erstellen oder das Product Backlog verwalten. Diese Änderungen sind definitiv eine Untersuchung wert, wenn die Alternative darin besteht, sich auf ein Epic festzulegen, das die grundlegenden iterativen Prinzipien des Frameworks ignoriert.
Wir können die Geschichte gut in Aufgaben zerlegen, aber Aufgaben scheinen Abstraktionen zu sein, die nur wenige Stunden lang sind.
Das ist in Ordnung. Granularität ist Geschmackssache, aber hier sind einige allgemein anerkannte Prinzipien der Scrum-Granularität:
Wenn Aufgaben viel größer werden, werden sie schwer genau abzuschätzen. Wenn Sie sie zu klein machen, erhöhen sie nur den Prozessaufwand.
Jede gegebene User Story muss jedoch in einen einzigen Sprint passen, bevor sie akzeptiert wird. Sonst ignoriert man das Time-Box-Prinzip und tappt in die „20 % der Story sind zu 80 % fertig“-Falle.
Was wir brauchen, ist eine Abstraktion, die jeden Sprint antreibt ... [in Richtung] eines klar definierten Ergebnisses [.]
Dies ist der Hauptzweck des Sprint-Ziels. Bei jedem Sprint sollten sich der Product Owner und das Team auf ein übergreifendes Sprint-Ziel einigen, das den Geist des minimal freisetzbaren Inkrements für den Sprint widerspiegelt. Storys, die das Sprint-Ziel nicht ansprechen, sollten wahrscheinlich vom Product Owner während der Backlog-Grooming- oder Sprint-Planung herausgefiltert oder depriorisiert werden.
Eine weitere Verwendung des Sprint-Ziels besteht darin, das grundlegende Maß für den Erfolg des Sprints bereitzustellen. Per Definition ist jeder Sprint, der sein Sprintziel erfüllt, ein erfolgreicher Sprint.
Es ist auch nicht ungewöhnlich, Sprints zu haben, die keine freischaltbare Funktion produzieren (z. B. Sprints, die nicht funktionalen Anforderungen, Toolketten- oder Prozessverbesserungen oder Story-Spikes gewidmet sind). Im Falle von Story-Spikes zum Beispiel ein Sprint-Ziel wie:
Überprüfen Sie die verfügbare Literatur zur Wirksamkeit des Embiggen eines Jabberwock.
könnte durchaus angebracht sein. Ein solches Ziel ist messbar, möglicherweise nachweisbar und mit Sicherheit ein Kandidat für starres Timeboxing.
Scrum ohne Sprint-Ziele ähnelt in gewisser Weise dem Fliegen ohne Flugzeug: Es mag konzeptionell einfacher sein, einfach mit den Armen zu schlagen, aber es ist unwahrscheinlich, dass Sie an Ihrem beabsichtigten Ziel ankommen.
Sind Sie sicher, dass Sie die Geschichte nicht aufteilen können?
Wenn Sie zum Beispiel eine Geschichte über "Benutzer können sich für den Erhalt wöchentlicher E-Mails anmelden" haben, können Sie sie in etwas wie "System kann E-Mails senden", "System kann Benutzer für den Empfang von E-Mails registrieren" und dann "Benutzer kann sich anmelden" aufteilen. oder etwas ähnliches.
Können Sie Ihre Geschichte nicht auf ähnliche Weise trennen?
kthxbai
Was wir brauchen, ist eine Abstraktion, die jeden Sprint antreibt ...
Normalerweise werden Geschichten verwendet, um den Sprint voranzutreiben. Geschichten sollten klare Akzeptanzkriterien haben, damit alle Beteiligten den Stand der Geschichte nachvollziehen können. Eine Story sollte so schnell wie möglich vom PO akzeptiert werden (nicht am Ende eines Sprints oder im Sprint-Review).
Normalerweise ist jede Geschichte in Aufgaben unterteilt, die ungefähr zwischen 1h liegen. -1d. Damit können Sie Ihren Sprint-Tasks-Burndown anhand eines Diagramms nachverfolgen . Dies hilft dir, Muster wie zu schnell oder zu langsam zu erkennen, um deinen Sprint voranzutreiben. Wenn Sie mit 100 Aufgaben für einen 2-wöchigen Sprint beginnen, messen Sie jeden Tag, wie viele noch offen sind (einschließlich brandneuer).
Einige sehr reife Teams verwenden sogar keine Aufgaben, sondern nur Geschichten , die sie wie von Jeff Sutherland beschrieben niederbrennen. Sie haben ungefähr 100-200 Geschichten, die sie in einem Story-Burndown-Diagramm verfolgen.
Ein weiterer Faktor ist die Größe einer Geschichte . Ich vergewissere mich immer, dass Stories geschätzt werden (mit Planungspoker oder ähnlichem), indem ich die sogenannte Fibonacci-Range 1,2,3,5,8,13,... anwende. Dann lasse ich das Team die Obergrenze der Aufteilung wählen: normalerweise an 13 oder 8 große Storys müssen geteilt werden (vertikal, nicht wie pro sw-arch-layer), bevor sie in einem Sprint bearbeitet werden können.
Zu Story-Splitting-Strategien siehe:
Ich gebe Ihnen eine direkte Antwort: Es gibt nichts Kleineres als eine Geschichte, aber Größeres als eine Aufgabe .
Die gute Nachricht ist, dass es fast keine Geschichte gibt, die nicht aufgeschlüsselt werden kann.
Sagen Sie zum Beispiel, Ihre Geschichte lautet "Als Benutzer möchte ich in der Lage sein, den Jimjab zu frobnisieren", und das ist definitiv ein Monat Arbeit für mehrere Leute. Wie geht's? Wahrscheinlich erfordert dies eine Datenbankänderung. Schreiben Sie also eine Geschichte: "Als Entwickler muss die Datenbank geändert werden, damit ich die "frobnicate"-Geschichte implementieren kann.
Vielleicht müssen Sie den Testrahmen verbessern, damit Sie die Jimjams validieren können: "Als Tester muss der Testrahmen modifiziert werden, damit ich die "frobnicate"-Geschichte testen kann.
Vielleicht muss die Oberklasse der Jimjam-Klasse erweitert werden: „Als Entwickler muss die MasterJab-Klasse erweitert werden, damit ich die „frobnicate“-Geschichte implementieren kann.
Usw.
Verbringen Sie viel Zeit damit, darüber nachzudenken, und ich bin mir sicher, dass Sie Ihre Geschichte (die eigentlich ein Epos ist) in sprintgroße Geschichten aufteilen können. Sag dir selbst, dass du es schaffen kannst, und es wird passieren.
Wenn die Story zu groß ist, um in einen Sprint zu passen, dann sollte es ein Epos sein . Sie würden dieses Epos dann in kleinere Geschichten aufteilen und diese dann in Aufgaben aufteilen. Auf diese Weise können Sie die Fertigstellung des Epos auf mehrere Iterationen verteilen und gleichzeitig die Geschichten, aus denen es besteht, immer abschließen (und somit Ihr Sprintziel erreichen).
Wenn Sie die Geschichte nicht in Teile aufteilen können, die klein genug sind, um sie in einer Iteration zu vervollständigen, dann gibt es ein Problem damit, wie die Geschichte geschrieben wurde oder mit den Techniken, die Sie verwenden, um sie zu zerlegen. Es spielt (aus meiner Sicht) keine Rolle, ob die Aufgaben nur ein paar Stunden dauern, aber wenn Sie denken, dass diese zu klein sind, können Sie versuchen, ein paar zusammenhängende Aufgaben zu bündeln, damit Sie nicht das Gefühl haben, zu messen etwas, das zu klein ist, um sinnvoll gemessen zu werden.
Ziffusion
Willl