Cross-Functional-Teams

Scrum: Spezialisten oder Generalisten – was braucht das Team?
Kommentare

Spezialisten sind jene im Team, die mit dem Wissen auf ihrem Gebiet eine wichtige Stütze für Projekte sind. Doch leider gibt es sie nicht allzu oft. Und was passiert, wenn man Scrum nutzt, um seine Projekte umzusetzen – wie lässt sich das Spezialwissen ausfallsicher in ein ganzes Team transportieren?

Der Artikel beschreibt einige Probleme, die in Scrum mit Spezialisten auftreten können und skizziert Lösungsansätze.

Mittwochmorgen, 09:00 Uhr. Gestern war Sprint Planning. Es sind einige spannende User Stories für die nächsten zwei Wochen im Backlog vorhanden. Fangen wir gemäß der Priorisierung an: ,,Als Kunde möchte ich meine Artikel filtern können, um gemeinsame Artikel zu erhalten“. Kein Problem, ist nur eine „Fünfer“-User-Story und klingt nach Optimierung der Datenbankabfrage. Sollte schnell erledigt sein, mit Günther, unserem Datenbankexperten.
Mittwochmorgen, 09:10 Uhr. Günther hat gerade mitgeteilt, dass er krankgeschrieben ist – und zwar die ganze Woche. Dann fange ich mit einer anderen Story an und warte bis Günther wieder da ist.
Montagvormittag, 11:23 Uhr. Warum hat die Story nur fünf Story Points? Das ist mindestens eine acht. Da haben wir uns wieder auf Günthers Aussage verlassen. Das könnte ganz schön knapp werden mit der Fertigstellung der Story.
Mittwochnachmittag, 13:00 Uhr. Günther ist da, hat aber keine Zeit. Als Datenbankexperte ist er in einem Meeting bis 15:00 Uhr, um eine grobe Planung für die nächsten anstehenden Stories abzugeben.
Dienstagmorgen, 10:00 Uhr, Sprint Review. Die Story wurde nicht abgeschlossen. Die Punkte, warum wir die Story nicht abgeschlossen haben, werde ich in der Retrospektive erwähnen.

Kennen Sie das Problem? Sie haben ein Teammitglied, das über fundiertes Spezialwissen verfügt, und Sie sind bei manchen Stories darauf angewiesen. Allerdings ist die Verfügbarkeit nicht immer hundertprozentig gegeben, da obige Szenarien auftreten können. Und Sie fragen sich, wie können Sie mit so einer Situation umgehen? Wie schaffen Sie es, dieses Spezialwissen in einem Team zu verbreiten? Wie schaffen Sie eine Grundlage für die Schätzung einer User Story, sodass nicht durch den Experten eine zu starke Beeinflussung entsteht? Wie regeln Sie die Verfügbarkeit? Beginnen wir jedoch zunächst einmal mit den grundsätzlichen Fragen.

Was ist ein Spezialist oder Experte?

Laut Duden ist ein Spezialist ,,jemand, der auf einem bestimmten (Fach-)Gebiet über besondere Kenntnisse und Fähigkeiten verfügt.“ Das Fachgebiet kann ein Geschäftsbereich, eine Branche, eine Technologie oder ein Prozess sein. Die Aneignung des fundierten Wissens kann durch jahrelange Erfahrung erfolgt sein, durch intensive und gezielte Ausbildung oder durch ein Alleinstellungsmerkmal, da man z. B. der Einzige ist, der sich innerhalb eines Unternehmens mit einem Bereich auskennt. Es gibt also unterschiedliche Gruppen von Experten:

I-Shaped-Spezialist: Dieser Spezialist ist der Guru in einem Thema, er ist der klassische Experte. Er kennt sich in einem Thema hervorragend aus. Seine Aufgaben beschränken sich nur auf seinen Expertenbereich. Bei Neukonzeptionen ist er gefragt, da er aufgrund seiner langjährigen Erfahrung sehr viel Wissen mitbringt und so Vor- und Nachteile des Themengebiets kennt. Problematisch wird es für den I-Shaped-Spezialisten, wenn sein Wissen nicht mehr benötigt wird. Es ist schwierig, ihn weiter zu beschäftigen, da er sich in anderen Themengebieten nicht auskennt.
T-Shaped-Spezialist: Dieser Spezialist ist eine Erweiterung des I-Shaped-Spezialisten. Er besitzt ebenfalls in einem Bereich fundiertes Wissen. Er unterscheidet sich insofern vom I-Shaped-Spezialisten, als dass er zusätzlich zum Fachwissen ein Breitenwissen besitzt. Somit besitzt er noch Wissen in anderen Bereichen (Abb. 1). Die Vorteile liegen klar auf der Hand: Der T-Shaped-Spezialist kann im Gegensatz zum I-Shaped-Spezialisten weitere Aufgaben im späteren Verlauf des Projekts übernehmen, die nichts mit dem Fachwissen zu tun haben.

Der Generalist grenzt sich insofern von den Spezialisten ab, als dass er sich nicht auf einen Bereich fokussiert, sondern mehr die Synthese zwischen den einzelnen Bereichen im Blick hat. Der Generalist interessiert sich für alle Themengebiete und kann diese geschickt kombinieren. Der leichte Umgang mit allen Kollegen ist gegeben. Es fällt ihm allerdings schwer, sich mit Spezialisten auf hoher fachlicher Ebene zu unterhalten, da ihm unter Umständen das nötige Spezialwissen fehlt.

Abb. 1: T-Shaped-Spezialist

Abb. 1: T-Shaped-Spezialist

Teamfähigkeit

Gute Teamplayer sind ein Muss in jedem Scrum-Team. Doch was zeichnet ein gutes Team und deren Zusammensetzung aus? Zum Thema Teamfähigkeit und -zusammensetzung erschien in diesem Jahr ein Artikel in der Tageszeitung „Die Welt“. Dort heißt es: „Ein gutes Team ist heterogen. Dabei bringt jedes Teammitglied unterschiedliche Kompetenzen mit, die zur Lösung der Aufgaben beitragen. Jeder muss das gemeinsame, schriftlich festgehaltene Ziel vor Augen haben. Zudem ist jedem klar, wie er als Teammitglied zur Erfüllung des Gesamtziels beiträgt. Das Team sollte die Fähigkeit zur Metakommunikation haben. Es ist wichtig, auch mal eine Pause einzulegen und über die Qualität der Zusammenarbeit zu sprechen. Dabei könnten folgende Themen eine Rolle spielen: Wie läuft die Zusammenarbeit? Was stört mich an meinen Teamkollegen? Was fand ich sehr gut bei der Zusammenarbeit? Was kann für die Zusammenarbeit verbessert werden? Können konkrete Maßnahmen eingeleitet werden? Dabei ist wichtig, dass die Rollen und die Verantwortungsbereiche im Team klar definiert sind.“

Um diese Dinge zu klären, bietet sich die Sprint-Retrospektive an. Der englische Forscher Meredith Belbin hat in den Siebzigerjahren die verschiedenen Teamtypen definiert. Er identifizierte Typen, die durch ihre Charakterzüge und Persönlichkeit bestimmt sind und in jedem Team enthalten sein sollten. Zum einen gibt es den Macher, der die Zielvorgaben streng verinnerlicht hat. Dabei arbeitet er planvoll und strategisch und scheut Alleingänge nicht. Ab und zu kommt es vor, dass er sich zu viel vornimmt. Der Botschafter oder Kreative ist nach außen orientiert. Er findet schnell Kontakt im Team und hat viele Ideen. Leider liegt sein Schwerpunkt dabei nicht auf Detailarbeit, und er verliert rasch die Motivation. Der Moderator integriert und koordiniert. Es geht ihm ums Große und Ganze, und er steuert den Prozess, auch wenn er selbst nicht das Team leitet. Häufig bringt er jedoch zu wenige eigene Vorschläge ein und hält sich mit eigenen Ideen vornehm zurück. Dazu kommen Trittbrettfahrer, die im Team ein wenig untertauchen wollen und kaum eigene Leistung zeigen. Zudem gibt es auch die notorischen Verweigerer, deren Strategie vor allem darin besteht, Vorschläge anderer Teammitglieder permanent abzulehnen. Der Experte oder Analytiker arbeitet planvoll. Er hat keine Scheu vor schwierigen Arbeiten, neigt aber dazu, sich vom Team abzukapseln und sich ins Exil zurückzuziehen (siehe dazu „Team Roles at Work“ von R. Meredith Belbin). In reiner Form treten diese Typen meist nicht in Erscheinung. Doch die Typologie hilft dabei, gute Teams zusammenzustellen.

Cross-Functional-Teams

Das Entwicklungsteam besitzt bei Scrum viele Freiheiten und kann durch seine Selbstorganisation bestimmen, wie es die Aufgaben erledigt. Dabei spielt die Besetzung eine wichtige Rolle. Interdisziplinär oder Cross-Functional-Team sind hier die Schlagwörter. Laut Ken Schwaber besteht ein Cross-Functional-Team aus Mitgliedern, die ihren Teil dazu beitragen, die Anforderungen in ein potenzielles Inkrement umzusetzen. Die Gesamtheit und das Zusammenspiel des kompletten Teams sind ausschlaggebend für den Erfolg. Scrum gibt nicht vor, dass jedes Teammitglied alles können muss. Die klassischen Rollen in einem Softwareprojekt werden somit nebensächlich und das Team rückt in den Vordergrund. Innerhalb des Teams werden Softwarearchitekten, Datenbankadministratoren oder Tester benötigt. Allerdings sollte die Besetzung des Teams so gewählt werden, dass die Umsetzung der Anforderungen möglich ist. Abhängigkeiten durch Spezialisten erschweren den Abschluss einer User Story und führen zu Wartezeiten. So sind drei Szenarien für die Zusammensetzung des Entwicklungsteams vorstellbar:

Variante 1: Das Team besteht aus verschiedenen I-Shaped-Spezialisten, wobei jeder einen bestimmten Bereich des benötigten Wissens abdeckt. Das kann dazu führen, dass nicht immer Arbeit für alle gleichzeitig vorhanden ist, da die Experten die anderen Bereiche nicht kennen.
Variante 2: Das Team ist mit Generalisten ausgestattet. Das bedeutet, dass niemand wirklich in einem Wissensbereich ein Spezialist ist. Das Wissen zu den einzelnen Themen ist oberflächlich, aber breit gefächert.
Variante 3: Das Team ist eine Mischung aus Variante 1 und 2. Es gibt sowohl Generalisten, als auch wenige oder nur einen I-Shaped-Spezialisten im Team. Diese Variante haben wir in der Realität häufig angetroffen.

Es sind noch vier weitere Subvarianten denkbar, die sich aus den Hauptvarianten bilden: Das Team besteht aus verschiedenen T-Shaped-Spezialisten (Variante 1a) oder aus einem Mix aus I-Shaped und T-Shaped-Spezialisten (Variante 1b). Diese Varianten sind Variante 3 gleichzusetzen. Hinzu kommen Variante 3a – das Team besitzt sowohl Generalisten als auch wenige oder nur einen T-Shaped-Spezialisten – und Variante 3b – das Team besitzt sowohl Generalisten als auch eine Mischung aus I-Shaped- und T-Shaped-Spezialisten. Auf die Subvarianten geht der Artikel nicht weiter ein, da der T-Shaped-Spezialist aufgrund seiner Definition sowohl ein Spezialist als auch ein Generalist ist. Somit wirken sich die folgenden Probleme nur bei einem I-Shaped-Spezialisten auf den Entwicklungsprozess aus. Für weitere Informationen zu Cross-Functional-Teams siehe folgenden Artikel.

Probleme

Innerhalb von interdisziplinären Teams kann es auch zu Problemen kommen. Der Ausfall eines Spezialisten ist schwer zu kompensieren, da die Verfügbarkeit des Experten nicht immer hundertprozentig gewährleistet ist oder das Team die Komplexität einer User Story nicht richtig einschätzt. Diese Probleme werden anhand der oben beschriebenen Varianten dargestellt und Lösungsansätze skizziert.

Schätzungen von User Stories

In Scrum wird eine User Story vorerst auf seine Komplexität geprüft und vom Entwicklungsteam bewertet. Das Ergebnis der Schätzungen von User Stories unterscheidet sich in den drei Varianten:

1. Die Spezialisten schätzen unterschiedlich, da sich jeder Experte nur in seinem Bereich auskennt und somit die anderen Bereiche schwer einschätzen kann.
2. Den Generalisten fehlt das fundierte Wissen, um die User Story adäquat bewerten zu können, sodass hier eine hohe Diskrepanz zwischen eigentlicher und tatsächlicher Schätzung liegt.
3. Die Generalisten lassen sich durch den Spezialisten stark beeinflussen, da sich dieser besonders gut auskennt und die anderen Teammitglieder dazu verleitet, seine Schätzung anzunehmen.

In allen drei Varianten kann es zu sehr unterschiedlichen Schätzungen kommen, sodass sich die Konsensfindung als schwierig erweist. Eine Möglichkeit, dieses Problem zu umgehen, ist das Vergleichen von User Stories, sodass sich die Größe einer Story ins Verhältnis mit anderen Stories setzen lässt. Dadurch können Aussagen getroffen werden, ob eine Aufgabe kleiner, gleich groß oder größer als eine andere ist. Diese Aussage kann sich vom Generalisten zum Spezialisten stark unterscheiden. So empfindet der Spezialist die Aufgabe als einfach und unkompliziert, da er fundiertes Wissen besitzt und sich mit den Gegebenheiten der Aufgabe auskennt. Das Gegenteil ist beim Generalisten der Fall, der es als mühsam ansieht, die Aufgabe mit seinem vorhandenen Wissen zu erfüllen.  Diese Denkweise ist leider ein Irrtum, da die Definition der Größe einer User Story nichts mit Zeitaufwand oder Vorwissen zu einem Thema zu tun hat. Vorwissen erhöht zwar die Umsetzungsgeschwindigkeit, aber die Aufgabe wird dadurch nicht größer. Dieses Umdenken fällt den meisten Teammitgliedern schwer und festigt sich erst im Laufe der Zusammenarbeit.

Eine weitere Möglichkeit, eine User Story zu schätzen, ist das „Estimation Game“ von Steve Bockman. Das Spiel basiert ebenfalls auf dem Vergleich von User Stories. Hier zieht jedes Teammitglied in der ersten Runde nacheinander eine User Story und hängt diese an eine Wand. Dabei werden die Stories links und rechts an den bereits hängenden User Stories gemäß ihrer Größe verteilt. Eine Story, die weiter rechts hängt, ist größer, als eine, die weiter links hängt. Stories, die von der Größe gleich sind, hängen übereinander. In der zweiten Runde werden die Story ganz links mit der niedrigsten Größe und die Story ganz rechts mit der höchsten Größe bewertet. Nun werden alle Stories gemäß ihrer Größe gruppiert und das Team hat somit die Aufgaben gemeinsam bewertet. Durch das Nacheinandersetzen der Stories bekommen die Generalisten ein Gefühl für spezielle Aufgaben und können sie im Verhältnis zu Aufgaben setzen, die sie besser bewerten können. Der Einfluss der Experten ist nicht so groß, da eine gemeinsame Diskussion über jede Story stattfindet. Das Setzen der Story gemäß ihrer Größe sorgt für eine offene Kommunikation innerhalb des Teams – somit ist jedes Teammitglied bei jeder Story gefragt und das Team als Ganzes übernimmt die Bewertung. Fehlt den Generalisten jegliches Spezialwissen, empfiehlt sich je nach Wissensstand eine Einarbeitungs-Story oder sogar ein Einarbeitungs-Sprint, in dem die Grundlage für die Schätzung geschaffen wird. Dadurch ist ein Teil oder sogar das komplette Team in der Lage, sich dieses Spezialwissen anzueignen.

Verfügbarkeit des Spezialisten im Team

Die Verfügbarkeit spielt eine wichtige Rolle bei der Planung eines Sprints in Scrum. Durch ein hochverfügbares Team können mehr User Stories umgesetzt werden:

Variante 1: Innerhalb des Spezialistenteams können vereinzelt die Spezialisten nicht verfügbar sein. Somit wird der Bereich des fehlenden Spezialisten nicht abgedeckt. Die Aufgaben der anderen Experten werden bearbeitet.
Variante 2: Die Generalisten haben das Problem, dass sie einen Experten außerhalb ihres Teams benötigen. Dadurch sind sie an die Verfügbarkeit des Spezialisten gebunden und müssen ihre Planung dementsprechend anpassen.
Variante 3: Grundsätzlich plant jedes Teammitglied die Kapazität ein, die es für den aktuell zu planenden Sprint zur Verfügung hat. Daraus ergibt sich eine Gesamtkapazität für das Team. Anhand dieser Kapazität legt dann in der Regel das Team fest, welchen Umfang die Aufgaben (Tasks) des Sprints beinhalten können. Somit wird die Gesamtkapazität auf alle Tasks aufgeteilt. Da der Spezialist aber hauptsächlich in seinem Spezialbereich arbeiten kann, verzerrt dieser Sachverhalt diese Schätzung. Eine Lösung des Problems ist, die Kapazität mehrgleisig zu planen. Es wird die Kapazität der Generalisten und die Kapazität des Spezialisten ermittelt. Dadurch werden die Kapazitäten auf die spezifischen Tasks aufgeteilt. Dies erhöht, je nach Anzahl der Spezialisten im Team, den Aufwand und die Komplexität der Planung.

Ein weiteres Problem tritt dann auf, wenn der Spezialist noch in anderen Teams benötigt und verplant wird. Das daraus resultierende Konstrukt kann so komplex werden, dass ein zusätzliches Planungsmanagement etabliert werden muss, das diese Problemstellung in die Hand nimmt.

Ausfall des Spezialisten durch Urlaub oder Krankheit

Ein zusätzliches Problem tritt durch geplante oder ungeplante Abwesenheiten, wie z. B. Krankheit oder Urlaub des Spezialisten auf. Das größere Problem ist der längere Ausfall des Spezialisten aufgrund einer Krankheit. User Stories, die hochpriorisiert im Product Backlog liegen, können dadurch gefährdet sein, da der Spezialist eine bestimmte Aufgabe nicht erledigen kann. Im schlimmsten Fall wird das Sprintziel nicht erreicht. Der Ausfall eines Spezialisten stellt sich in den drei Varianten wie folgt dar:

Variante 1: Ein bestimmter Wissensbereich ist im Team nicht abgedeckt; diesen kann das Team somit nicht bedienen.
Variante 2: Da keine Spezialisten im Team existieren, kann hier auch kein Ausfall entstehen. Besteht eine Abhängigkeit zu einem Spezialisten außerhalb des Teams, führt der Ausfall und die niedrige Verfügbarkeit zu Engpässen, und Aufgaben werden nicht erledigt.
Variante 3: Den Ausfall des Spezialisten muss das Team kompensieren: Entweder übernimmt ein anderes Teammitglied die anstehenden Aufgaben oder das Team organisiert einen adäquaten Ersatz für den Ausfall.

Wichtig ist es, Ausfallzeiten von Teammitgliedern, insbesondere von Spezialisten, so früh wie möglich zu erfassen, um dies in die Planungen des Product Backlog miteinfließen zu lassen. Dabei kann es natürlich vorkommen, dass geplante Abwesenheiten mit umsetzungskritischen Terminen kollidieren. Dafür muss das Team eine Lösung finden. Bei ungeplanten Abwesenheiten sollte ein Notfallplan existieren, welcher die Abwesenheit des Spezialisten übergangsweise ermöglicht. Ist es möglich, die User Story aus dem Sprint Backlog zu nehmen, so sollte diese wieder in das Product Backlog verschoben werden. Ersatzweise wird eine alternative Story in den Sprint gezogen, die von Generalisten umgesetzt werden kann. Eine weitere Lösung wäre, den Schnitt der User Story so anzupassen, dass die Expertenanteile in eine separate Story ausgelagert werden, die der Spezialist zu einem späteren Zeitpunkt durchführt.

Aufbau von Spezialwissen

Um Wissen im Unternehmen aufzubauen, gibt es mehrere Möglichkeiten: Durch Schulungen, eigenständige Weiterbildung oder auch durch die Zusammenarbeit mit Wissensträgern lässt sich Wissen aufbauen. Bei Schulungen besteht die Möglichkeit, das fehlende Wissen durch einen externen Trainer einzukaufen. Bei der eigenständigen Weiterbildung liegt das Selbststudium im Fokus. Bei der Zusammenarbeit mit Wissensträgern kann das vorhandene Wissen an andere Teammitglieder weitergegeben werden. In allen Fällen muss der Mitarbeiter dieses neue Wissen aufnehmen wollen, um das Erlernte später anwenden zu können. Der Fortbildungsprozess kann längere Zeit in Anspruch nehmen, da nur in seltenen Fällen das neu Erlernte sofort perfekt umgesetzt werden kann. Auch beim späteren Anwenden des Erlernten baut der Mitarbeiter durch weitere Erfahrungen sein neu gewonnenes Wissen weiter aus.

Zusammenfassung

In der Softwareentwicklung sind Spezialisten notwendig, allerdings ist die Abhängigkeit zu ihnen ein Risikofaktor. Das interdisziplinäre Team sollte aus einem guten Mix aus Generalisten und Spezialisten bestehen. Somit ist es möglich, spezielle Themen zu bearbeiten, gleichzeitig aber auch weitere Teammitglieder miteinzubeziehen, sodass das Expertenwissen verbreitet wird. Dabei unterscheidet sich die Zusammensetzung eines Teams, d. h. je nach Art des Experten. Das Einbinden und Beschäftigen eines T-Shaped-Spezialisten erweist sich als einfacher, da dieser durch das vorhandene Breitenwissen auch die Aufgaben der Generalisten bearbeiten kann. Zusätzlich sind die Aufgaben mit notwendigem Fachwissen durch den T-Shaped-Spezialisten umsetzbar. Der I-Shaped-Spezialist kann dagegen nur die spezifischen Aufgaben umsetzen, in denen sein fundiertes Wissen gefordert ist. Somit gestaltet sich die Durchführung von anderen Aufgaben als schwierig.

Unabhängig davon, welche Zusammensetzung für das Scrum-Team gewählt wird, hat die Kommunikation oberste Priorität. Klare Absprachen während des Sprints und die Planungen von Fehlzeiten, gerade die von Spezialisten, können Abhängigkeiten reduzieren. Somit kann das Team die User Stories erfolgreich bearbeiten. Je besser das Wissen innerhalb des Teams verbreitet ist, desto besser werden die Schätzungen der User Stories. Dies pendelt sich mit der Zeit ein, weshalb häufige Wechsel der Teammitglieder kontraproduktiv sind. Der Ausfall des Spezialisten zu einem frühen Zeitpunkt des Projekts kann zu erheblichen Problemen bei der Umsetzung der Aufgaben führen. Mangelndes Wissen und falsche oder ungenaue Schätzungen können die Folge sein. Grundsätzlich sollte sich neben dem Spezialisten noch mindestens ein Teammitglied damit beschäftigen, Spezialwissen aufzubauen. Ausfälle werden damit kompensiert und eine Streuung des Wissens ist garantiert.

Scrum
Scrum ist ein Rahmenwerk, innerhalb dessen Menschen komplexe, adaptive Aufgabenstellungen angehen können. Dadurch sind sie in der Lage, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern. Das Rahmenwerk sorgt für Transparenz zwischen Produktmanagement und dem Entwicklungsvorgehen. Hierdurch können sich beide Seiten überprüfen, verbessern und anpassen („inspect & adapt“). Innerhalb von Scrum gibt es verschiedene Rollen, Ereignisse und Artefakte.Rollen in Scrum
Der Product Owner, der Scrum Master und das Entwicklungsteam bilden das Scrum-Team. Der Product Owner (PO) ist für die fachliche Priorisierung und das Management des Product Backlogs verantwortlich. Der PO definiert neue Stories innerhalb des Product Backlogs und sortiert sie gemäß der aktuellen Priorisierung ein. Er ist für das fachliche Verständnis zuständig und muss dafür sorgen, dass das Entwicklungsteam sämtliche fachliche Fragen beantwortet bekommt, die zur Umsetzung der Story notwendig sind. Der Scrum Master ist für die Einhaltung des Scrum-Prozesses zuständig, indem er dafür sorgt, dass das Scrum-Team die Theorie, Praktiken und Regeln von Scrum befolgt. Das Entwicklungsteam bearbeitet die Aufgaben gemäß der Priorisierung des PO und sorgt dafür, dass am Ende eines Sprints ein potenziell lieferbares Inkrement entsteht. Das Team – nicht die einzelnen Teammitglieder – verfügt über das nötige Wissen, um seine Arbeit zu verrichten und User Stories zu implementieren. Es ist nicht von Dritten abhängig.Ereignisse in Scrum
Innerhalb eines Sprints wird ein potenziell lieferbares Inkrement erstellt. Der Sprint ist zeitlich auf einen Monat oder weniger limitiert. Der Sprint ist ein Container und beinhaltet die Sprint-Planung, Dailies, das Sprint-Review und die Sprint-Retrospektive. Ein Sprint besitzt immer ein Sprint-Ziel, welches erreicht werden muss. Während der Sprint-Planung wird beschlossen, welche Arbeiten für den kommenden Sprint anstehen. Die Planung ist für einen einmonatigen Sprint zeitlich auf acht Stunden oder weniger begrenzt. Der Product Owner legt die Priorisierung fest und das Team verpflichtet sich, die Punkte im Sprint Backlog abzuarbeiten. Das Team definiert die Tätigkeiten, die notwendig sind, um die jeweiligen Backlog-Einträge umzusetzen.Daily Scrum
Im täglichen, 15-minütigen, am selben Ort und zur selben Uhrzeit abgehaltenen Daily werden folgende drei Fragen beantwortet:
• Was habe ich seit gestern zum Sprint-Ziel beigetragen?
• Was werde ich heute für die Erreichung des Sprint-Ziels beitragen?
• Was hat mich bei meiner Arbeit behindert, um das Sprint-Ziel zu erreichen?
Das Daily ist ein Instrument, um den Fortschritt sichtbar zu machen und eventuelle Anpassungen vorzunehmen.

Sprint-Review
Nach dem Ende eines Sprints wird das erreichte Sprint-Ziel und das potenzielle Produktinkrement gesichtet. Hierfür nehmen neben dem Scrum-Team auch die Stakeholder teil. Diese können sich das Inkrement und die implementierten Backlog-Einträge anschauen. Sind Anpassungen notwendig, werden diese mit dem Scrum-Team gemeinsam erarbeitet. Das Sprint-Review ist auf vier Stunden für einen einmonatigen Sprint begrenzt.

Sprint-Retrospektive
Nach dem Review folgt die Retrospektive, an der nur das Scrum-Team teilnimmt. Für einen einmonatigen Sprint ist die Retrospektive auf drei Stunden begrenzt. Die Retrospektive dient dazu, auf den Sprint zurückzublicken und Probleme und Errungenschaften aufzudecken, die dazu führen, dass das Scrum-Team besser miteinander arbeitet.

Artefakte in Scrum
Bei den Artefakten handelt es sich um das Product und Sprint Backlog, sowie um das Inkrement, welches am Ende eines Sprints entsteht.

Aufmacherbild: Conceptual image of businessteam working cohesively. Interaction and unity von Shutterstock / Urheberrecht: Sergey Nivens

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -