Blog-Serie – Teil 3 von 5
In diesem Teil sehen wir uns an, wie sich dieses Thema im skalierten Umfeld darbietet. Skaliertes Umfeld bedeutet, es arbeiten mehrere Teams an einem Produkt.
Das es hier anders aussehen kann, als wenn nur ein Team an einem Produkt arbeitet, lässt sich schon dadurch vermuten, dass wir jeweils einen eigenen Beitrag dafür erstellt haben. Aber was sind die großen Unterschiede? Wir betrachten dafür zwei Themen, die Auswirkungen auf „Epic, Feature und Storys“ haben bzw. haben können. Anforderungsebenen und Aufgabenverteilung.
Anforderungsebenen und Verantwortlichkeiten
Wenn wir uns verschiedene Frameworks wie SAFe oder Scrum@Scale ansehen, dann sehen wir, dass es neben den Product Ownern der einzelnen Scrum-Teams weitere Rollen mit zum Teil ähnlichen Aufgaben haben. In Scrum@Scale gibt es Chief Product Owner und in SAFe das Product Management. Üblicherweise werden diesen Rollen Verantwortlichkeiten für eine bestimmte Anforderungsebene zugewiesen. Häufig sind die Product Owner für Storys und Chief Product Owner bzw, Product Management für Features (manchmal auch Epics) zuständig. Somit kann man die Frage was eine Story, Feature und Epic jeweils ist durch die Verantwortlichkeiten festlegen. Wer kann entscheiden? Wer ist verantwortlich? Liegt es in der Hand eines Product Owners, dann können wir von einer Story sprechen. Falls es dazu zum Beispiel einen Chief Product Owner benötigt, dann sind wir eher auf Feature oder Epic Ebene unterwegs.
Aber das allein ist nicht alles. Denn die Team-Aufteilung und damit einhergehenden Aufgabenverteilung hat darauf auch einen großen Einfluss
Aufgabenverteilung
Bei der Aufgabenverteilung geht es um die Frage, welches Team welche Aufgaben bekommt. Oder anders gesagt welche Backlog Items. Sinnvollerweise bekommt ein Team nicht irgendwelche Backlog Items zugeschoben, sondern die Teams bekommen Verantwortlichkeiten. Diese haben Einfluss auf die Zerlegung der Backlog Items und dementsprechend, was eine Story sein kann.
Wir setzen voraus, dass eine Story immer nur von einem Team umgesetzt wird. Falls in einer Story mehrere Teams betroffen sind, dann muss diese nochmals zerlegt werden. Also ist die Zusammensetzung der Teams und deren Verantwortlichkeiten entscheidend für den Inhalt einer Story.
Betrachten wir zwei Beispiele:
In einem Smart Home System soll die Möglichkeit geboten werden, remote Gäste ins Haus zu lassen.
- Stellen wir uns vor, dass alle benötigten Skills in einem Scrum Team vereint sind, dann könnte
– das Feature „Remote Einlass“ sein und
– Storys z.B. „Klingel remote anzeigen“, „Tür remote entriegeln“, „Remote Audio Gespräch“ sein. Natürlich auch in Abhängigkeit wieviel das Team in einem Sprint schafft. Andere Teams wären dann zum Beispiel für die smarte Lichtsteuerung zuständig - In dem zweiten Szenario sind nicht alle Skills in einem Team vereint. In diesem Fall sagen wir mal ist die App-Entwicklung in einem eigenen Team untergebracht. Dann könnte
– das Feature wiederum „Remote Einlass“ sein, aber
– die Storys entsprechend der Teams geschnitten sein. Zum Beispiel „Tür in der App freigeben“ (Team App) und „Tür bei Remote-Freigabe entriegeln“ (für das andere Team) sein.
Wir sehen also, dass eine Story aus dem ersten Szenario hier nochmals zerlegt werden würde, da mehrere Teams daran arbeiten müssen.
Dies sind aber nur mögliche Beispiele. Und die tatsächliche Aufteilung wird auch von der Dauer für die Umsetzung beeinflusst.
So sagt man bei Storys, dass sie am Ende in einem Sprint umgesetzt werden sollten und Features innerhalb von 8-12 Wochen.
Alles, was viel mehr Aufwand bedeutet, könnte als Epic bezeichnet werden. Aber auch das sind nur Daumenwerte.
Wir sehen auch hier ist die Aufteilung Epic, Feature und Story sehr stark von verschiedenen Bedingungen abhängig. Wodurch es sehr schwer ist eine konkrete und allgemein gültige Regel abzuleiten.
Im letzten Teil dieser Serie werden wir uns die Definitionen zu Epic, Feature und Story in SAFe ansehen.
Bleiben Sie dran und diskutieren Sie gerne über Kommentare zu den einzelnen Beiträgen mit.
Ihre SOPHISTen