Aus meiner Sicht haben wir drei Ebenen:
Epic - Umfassender Überblick darüber, was schön zu tun wäre. (Normalerweise mehr als ein Sprint)
Story - Definiertere und strukturiertere Ansicht. (Was kann in einem Sprint getan werden)
Aufgabe - Geschichte, die in Komponenten (Backend, DB, Frontend, iOS usw.) unterteilt ist (was an einem Tag erledigt werden kann)
Lassen Sie die Leute auf der Website bezahlen
Lassen Sie die Leute in der mobilen App bezahlen
(* - gleiches Ticket)
Es gibt eine Möglichkeit, ein Epic in Jira zu erstellen. Und wir können Geschichten zu Epen hinzufügen . Wir können nicht jede Story in Aufgaben aufteilen , um eine schöne Struktur zu haben. Aber so wie ich es verstehe, gibt es einen gemeinsamen Weg. Es geht darum, Unteraufgaben für Storys zu erstellen . Welcher Unterschied wird es zu Tasks selbst sein? Und dann können wir diese Stories mit der Federerstellungsfunktion eines Boards zu unserem Sprint mitnehmen. SONDERN.
Eine Geschichte sollte für sich alleine lieferbar sein (wenn sie fertig ist). Es ist am besten, sich die ganze Zeit an diese Konvention zu halten.
Wenn es um Jira geht, sollte jeder Eintrag entweder eine Story oder ein Bug sein . Alles, was kein Fehler ist, ist eine Geschichte. Wie Sie bereits betont haben, stiften andere Typen nur noch mehr Verwirrung, wenn sie eingeführt werden. Wir verwenden diesen vereinfachten Ansatz schon seit einiger Zeit und hatten nie Probleme damit. Offensichtlich werden Epics immer noch verwendet, wenn mehrere Geschichten und/oder Fehler involviert sind, die sich möglicherweise über mehrere Sprints erstrecken.
Wir haben die Verwendung von 3 Ebenen angepasst, wie Sie gesagt haben, wobei die letzte Unteraufgaben sind. Wir erstellen so viele Implementierungsunteraufgaben wie nötig, aber wir nehmen auch alle anderen Aktionen, die in unserer Definition of Done enthalten sind, als Unteraufgaben auf. Auf diese Weise sind wir sicher, dass DoD gilt, wenn eine Geschichte geschlossen wird.
In Bezug auf Ihre Fragen:
Schätzen Sie nur Geschichten, niemals Teilaufgaben. Es ist vollkommen in Ordnung, wenn das Team während der Diskussion der Schätzung Teilaufgaben erstellt, aber es sollte seine Schätzungen als Team für die gesamte Geschichte abgeben und dabei alles berücksichtigen, was für die Fertigstellung in einem freigabefähigen Zustand erforderlich ist. Die Mitglieder können ihre Gedanken darüber austauschen, was in den verschiedenen Unteraufgaben enthalten ist, aber es liegt am Team, sich auf eine gemeinsame Schätzung zu einigen. Das Summieren der Schätzungen für jede Teilaufgabe, die von verschiedenen Teammitgliedern bereitgestellt werden, wird nicht gleich sein (zumindest auf der Verpflichtungsebene).
Verwenden Sie die verbleibende Schätzung. Wir ziehen es vor, die verbleibende Arbeit in unserer Sprint-Planungssitzung zu schätzen und zu verwenden (1 Punkt in Ihrem Fall). Wenn Sie die ursprünglichen Punkte behalten, müssen Sie die Menge der erledigten Arbeiten im Auge behalten, was unnötiges Ballast ist. Außerdem besteht der Zweck darin, jede Story innerhalb des geplanten Sprints abzuschließen, und das Team wird darin immer besser, wenn sie ein paar Sprints gemeinsam durchlaufen. Der "verlorene" Aufwand spielt keine große Rolle, da das Wichtigste die Menge an Arbeitsfunktionalität ist, die Sie liefern.
Mein Team hat JIRA-Unteraufgaben als Aufgaben verwendet – die mechanischen Aufschlüsselungsdetails einer Story.
JIRA „Tasks“ hingegen befinden sich auf der gleichen Ebene wie Stories, unterscheiden sich jedoch dadurch, dass sie keinem Benutzer einen direkten Geschäftswert bringen. Beispielsweise könnten „Compiler optimieren“, „[neue Technologie] erforschen“ und „Testabdeckung erhöhen“ alle als JIRA-Aufgaben in Frage kommen. Auch diese können eigene Unteraufgaben haben.
In Bezug auf Ihre Fragen...
Die Schätzung wird vom Team vorgenommen, das die Arbeit des Teams repräsentiert. Nicht von Einzelpersonen. Dies ist Teil des Zwecks eines funktionsübergreifenden Teams und eines gemeinsamen Codebesitzes. Menschen besitzen keine Geschichten. Das gesamte Team tut es.
Mein Team hat es in beide Richtungen versucht. Zuerst haben wir versucht, die alte Schätzung beizubehalten. Unsere Überlegung war, dass „das Wissen um den Aufwand, den wir hineingesteckt haben, nicht verloren geht“. Mit der Zeit stellten wir fest, dass sich niemand wirklich darum kümmerte , und es wurde verwirrend, Geschichten mit etwa 10 Punkten zu führen, die noch 30 Minuten Arbeit enthielten. Also entschieden wir uns am Ende für eine Umstellung, und es funktionierte viel besser. Das passt ohnehin besser zur ganzen Idee von Agile; Wenn Sie mehr/bessere Informationen zu dieser Schätzung haben (die Tatsache, dass sie zu 90 % fertig ist), warum sollten Sie sie dann nicht aktualisieren?