Ein Problem ist in letzter Zeit aufgetreten, als wir Stories aufschlüsselten. Das Szenario ist wie folgt: Während der Produktinkrementplanung skizzieren wir eine Anzahl von X Stories für den PI. Dies wird in Jira mit Story Points aufgezeichnet, die jeder Story zugeordnet sind. Wenn wir in die Sprint-Planung einsteigen, stellen wir oft fest, dass die ursprünglichen Geschichten zu weit gefasst sind oder eine Geschäftsanforderung nicht erfüllen.
Also zwei Fragen:
Zugegeben, es ist ein Werkzeugproblem, aber ist es die Norm, die neuen Geschichten mit dem Original zu verknüpfen? Wenn die Originalgeschichte sagen wir 20 Story Points und die Substory 10 hat, würden Sie 10 von der Originalstory abziehen, um Doppelzählungen zu vermeiden?
Indem Sie entschieden haben, dass Sie Geschichten aus dem Original herausbrechen müssen, haben Sie ein besseres Verständnis der Geschichte gewonnen und sollten nicht länger davon ausgehen, dass Ihre Schätzung der ersten Geschichte korrekt war. In dem speziellen Fall, den Sie angeben, würde ich die ursprüngliche Geschichte neu einschätzen, nachdem Sie sie auseinandergenommen haben.
Um noch einen Schritt weiter zu gehen, ist es wichtig zu wissen, dass das, was Sie getan haben, sehr natürlich ist und der Rest des Teams wahrscheinlich genauso denken wird. Um dies zu umgehen, teilen wir die Geschichte oft in neue Geschichten auf, anstatt die Anstrengung aus einer Geschichte herauszubrechen. Dann fragen Sie den Product Owner, ob die neuen Stories das liefern, wonach er in der ursprünglichen Story gesucht hat. Dies ermöglicht es dem Team, gute Gespräche über den Aufwand und die Story Points für jede Story zu führen, ohne eine Voreingenommenheit gegenüber ihren vorherigen Annahmen zu haben.
Die ursprüngliche Geschichte kann gelöscht oder als Referenz aufbewahrt werden, je nachdem, was für Sie am besten funktioniert, würde aber niemals bearbeitet werden. (es würde wie jedes andere Epos behandelt werden)
Wenn Sie in einem Scrum-Team sind, gibt es nur eine Art von Story … und zwar eine umsetzbare, wertschöpfende Story. Es sollte keine Hierarchie geben, die Story Points beinhaltet.
Möglicherweise haben Sie ein Epic oder Feature oder eine andere Form eines übergeordneten, weniger definierten Konzepts, das Geschichten verknüpft, aber diese werden im Allgemeinen nicht anhand von Story-Punkten geschätzt.
Ist es also üblich, Geschichten mit dem Original zu verknüpfen ... Ich würde nein sagen. Da die ursprüngliche Geschichte so klingt, als wäre sie nicht umsetzbar, sollte sie neu geschrieben oder in echte Benutzergeschichten aufgeteilt werden, die den INVEST-Prinzipien folgen. Sobald die ursprüngliche Story aufgeteilt ist, entfernen Sie die ursprünglichen SP-Schätzungen und lassen Sie das Team nur die umsetzbaren Storys schätzen. Konvertieren Sie das Original bei Bedarf in ein Epic.
Sie können die übergeordnete Entität weiterhin für andere Zwecke wie Portfolioplanung/Roadmapping behalten oder wenn Ihr Kunde die übergeordnete Entität als eine seiner Geschäftsanforderungen bezeichnet. Ich hasse es, diese Dinge zu sagen, da sie sich vom grundlegenden Scrum entfernen, aber viele Unternehmen verwendeten gemischte Scrum-/Wasserfall-Praktiken auf Programm-/Portfolioebene, um ihre mittel- und langfristigen Planungsanforderungen zu erfüllen.