Auch ein Scrum Team kategorisiert die Arbeiten eines Projekts in übergeordnete Ebenen. Diese werden Epics genannt und fassen Storys einer gewissen Ähnlichkeit, beispielsweise ein Produkt oder ein Modul, zusammen. Der zeitliche Aspekt, also wann ein Epic abgeschlossen wird, ist weniger wichtig.
Liste der Epics eines Projekts
Nachdem Epics definiert wurden, werden die Storys erstellt, die das Team zu diesem Zeitpunkt vorhersehen kann, und in das Backlog gestellt. Auch die Kategorisierung wird durchgeführt, d.h. die Storys werden Epics zugeordnet.
Bei diesem Story-Finding werden Aufwände der Storys oder deren Komplexität nur am Rande behandelt. Völlig uninteressant ist, ob die Story von der Kapazität oder den zeitlichen Vorstellungen des Auftraggebers (Product Owner), den Budgets oder den Renditeerwartungen des Unternehmens darstellbar ist. Die Story muss allerdings so formuliert sein, dass sie in einem Sprint geschafft werden kann.
Backlog in Jira
Backlog in Can Do
Diese Storys – genauer User-Storys – bezeichnen Arbeiten, die ein konkretes Ergebnis, idealerweise etwas zum Sehen oder Klicken, liefern. Sie sind also weniger kleine technische Entwicklungsschritte, sondern eher aus einem Anwendungsfall heraus (Use Case) zu gestalten.
Für eine Story können auch Unteraufgaben definiert werden. Jede dieser Unteraufgaben gehört also zur Story und kann von verschiedenen Mitgliedern des Teams parallel in einem Sprint entwickelt werden. Diese Unteraufgaben sind dann eher die detaillierten Entwicklungsarbeiten, die als Ergebnis zu einer erfolgreichen, abgeschlossenen Story führen.
Eine Story die automatisch in Can Do als Arbeitspaket erzeugt wurde.
Eine sehr gute organisatorische Besonderheit während eines Sprints sind tägliche Treffen des Teams (Daily Scrum). Hier tauscht sich das Team fachlich aus.
Zusätzlich soll ermittelt werden, welches Teammitglied möglicherweise verzögert vorankommt und seine Storys, bis Sprint-Ende nicht schafft. Die anderen Teammitglieder leisten dann Unterstützung, damit auch wirklich alle Storys geschafft werden. Es ist also eine Zusammenarbeit aller für einen erfolgreichen Sprint nötig. Das setzt eine Teamkultur und gewisse Solidarität voraus. Wird eine Story nicht geschafft, ist nicht der eine Entwickler schuld, sondern das gesamte Team hat es eben nicht geschafft.
Ist der Sprint abgeschlossen, wird mit dem Product Owner das Ergebnis besprochen und der nächste Sprint vereinbart. Erfolgreich war ein Sprint, wenn alle Storys, die am Anfang vereinbart wurden, auch abgeschlossen wurden
