Scrum at a glance

Rollen, Events & Artefakte

Das Scrum Framework definiert Scrum Rollen, Events und Artefakte. Aber was bedeutet das und wie könnte es umgesetzt werden?

1 I Drei Rollen

Zunächst zu den Rollen. Anders als im traditionellen Projektmanagement gibt es im Scrum Framework nur 3 Rollen:

Was vielleicht auffällt: Es gibt keinen Projektmanager. Und es gibt keine hierarchische Beziehung in diesem Team. Das Team ist ein selbstbestimmtes Team ohne Hierarchie, das sich durch die Zielerreichung steuert. Aber zunächst zu den Rollen.

1.1 Der Product Owner versteht sich als "Value Maximizer". Er hat eine Vision für das Endprodukt. Er ist in erster Linie für die kontinuierliche Priorisierung des Backlogs zuständig, so dass gewährleistet ist, das der "added value" eines Sprints maximiert wird. Der Product Owner ist für den wirtschaftlichen Erfolg des Produkts verantwortlich, agiert als "Stimme des Kunden" und vertritt die Wünsche und Anforderungen der Stakeholder gegenüber dem Development Team. 

1.2 Der Scrum Master versteht sich als "Enabler". Der Scrum Master ist verantwortlich für die Einhaltung der Prozesse und unterstützt und coacht das Team und die Organisation diesbezüglich. Er ist für das Team ein "servant leader". Er unterstützt bei der Beseitigung von Hindernissen und Problemen, agiert häufig auch außerhalb des Teams in der Organisation als Mediator und moderiert die Abläufe und Scrum Aktivitäten.

1.3 Das Development Team ist für die Entwicklung des Produkts verantwortlich. Es besteht meist aus 5-9 Personen, ist cross-funktional aufgestellt, arbeitet selbstorganisiert und ist bestenfalls örtlich zentriert.

2 I Fünf Events 

Events sind die regelmäßigen Scrum Meetings. Der Scrum Sprint an sich zählt aus als ein Event.

2.1 Scrum Sprint: In Scrum wird iterativ vorgegangen, d.h. in einzelnen Sprints. Die Länge eines Sprints sollte zwischen 2 und 4 Wochen liegen. Die Sprintlänge ist für alle Sprints in einem Projekt vorab festgelegt, gleich und ändert sich im Verlauf des Projektes nicht. In jedem Sprint wird ein Sprintziel festgelegt. Das Resultat eines jeden Sprints ist ein sogenanntes Inkrement, auch MVP genannt.

2.2 Sprint Planning Meeting: Der Product Owner und Development Team diskutieren das Scrum Backlog, das der Product Owner priorisiert hat. Die User Stories mit der höchsten Priorität stehen oben. Das Team diskutiert, welche der priorisierten User Stories in den nächsten Sprint genommen werden und prüfen, ob diese User Stories ausreichend genau spezifiziert sind, damit sie ohne Unterbrechung abgearbeitet werden können. Die empfohlene Dauer des Sprint Planning Meetings beträgt 2 Stunden je Sprint Woche. 

2.4 Sprint Review Meeting: Das Sprint Review findet am Ende des Sprints statt. Das Team stellt die Ergebnisse des Sprints gegenüber allen interessierten Stakeholdern des Projektes vor und bittet um Feedback. Die Dauer des Review Meetings wird mit einer Stunde je Sprintwoche empfohlen.

2.5 Sprint Retrospektive: Die Sprint Retrospektive findet am Ende des Sprints statt. Das Scrum Team reflektiert den vergangenen Sprint und bespricht Ideen für die Verbesserung der Zusammenarbeit. Die Dauer des Meetings wird mit einer Stunde je Sprint Woche angesetzt.

Anbei ein möglicher Ablauf, bei dem der nächste Sprint immer dienstags startet. Die angegebenen Zeiten richten sich nach der offiziellen Empfehlung. Ich habe jedoch die Erfahrung gemacht, dass die angegebenen Zeiträume bei Unternehmen, in denen Scrum noch nicht fest etabliert ist, aufgrund der Länge schwer akzeptiert werden. Gerade beim Sprint Review Meeting wird es häufig nicht möglich sein, die Stakeholder für die relativ lange Zeit zu blocken - oder die Teilnahme fällt gering aus. Darüber hinaus hängt es stark von der Bedeutung des Projektes ab, welche Zeiträume als angemessen akzeptiert werden. Daher schlage ich im Falle von Akzeptanzproblemen eine Kürzung der Events auf die Hälfte der angegebenen Zeit vor - außer für das Daily.

3 I Drei Artefakte

3.1 Product Backlog: Das Product Backlog enthält alle Anforderungen an das Projekt. Diese müssen ausreichend spezifiziert, priorisiert und der Aufwand muss geschätzt sein. Neue Anforderungen können jederzeit ergänzt werden. 

3.2 Sprint Backlog: Das Sprint Backlog enthält alle Anforderungen, die innerhalb des aktuellen Sprints umzusetzen sind. Es wird im Sprint Planning zwischen Product Owner und Entwicklungsteam erarbeitet. 

3.3 Produkt Increment: Das Produkt Increment ist die Summe aller bisher gelieferten (Teil-) Ergebnisse aus den bereits abgeschlossenen Sprints. Das Produkt Increment sollte jederzeit auslieferbar und muss entsprechend ausreichend getestet sein (MVP).