SCRUM: Anleitung für Einsteiger

Inhaltsverzeichnis

1. Einleitung
2. Gründe für den Erfolg
3. Grundlagen
   • 3.1 – Der Begriff Scrum
   • 3.2 – Empirische Prozesskontrolle
   • 3.3 – Die 3 Säulen
   • 3.4 – Die 5 Values
4. Wie funktioniert Scrum?
   • 4.1 – Scrum Rules
   • 4.2 – Scrum Prozess
   • 4.3 – Die Events
   • 4.4 – Die Rollen
   • 4.5 – Die Artefakte
5. Unsere Trainings
6. Agiles Consulting

Scrum ist der absolute agile Superstar. Wer Projekte managt oder sich mit dem Thema Projektmanagement beschäftigt, kommt um das Thema Agilität nicht mehr herum. Und Agilität bedeutet heutzutage Scrum. Denn in mehr als 85 Prozent aller agilen Projekte wird Scrum angewandt. Obwohl das Scrum Framework bereits vor mehr als 20 Jahren entwickelt wurde, erleben wir in Deutschland erst seit kurzem den wirklichen Durchbruch dieser revolutionären Methode im Projektmanagement. Es gibt aktuell in Deutschland einen regelrechten Boom. Wie kommt das? Nun, letztlich liegen die Grundprinzipien und Ansätze, die mit Scrum vermittelt werden, absolut am Zahn der Zeit: das hierarchische Projektmanagement hat ausgedient. Autonome, sich selbst managende Teams sind heute eine Selbstverständlichkeit. Themen wie Holocracy, Design Thinking zeigen ganz deutlich: die Macht liegt heute beim Team beziehungsweise den Mitarbeiterinnen und Mitarbeitern. Und dieser Trend zeigt sich auch beim Managen von Projekten.

Einleitung

Da es das Framework schon einige Jahre gibt, haben sich in den letzten Jahren immer mehr Autoren, Berater und Experten darangemacht, die Methodik weiterzuentwickeln, zu verändern und zu ergänzen. So entstanden viele Varianten und Abwandlungen von Scrum. Die beiden Gründer des Frameworks Jeff Sutherland und Ken Schwaber betonen aber in ihrem Scrum Guide, dass das Framework nur in seiner Reinform angewendet den erwünschten Effekt liefern kann. Der Guide wurde 2010 zum ersten Mal herausgegeben und fasst auf wenigen Seiten die Regeln und Prinzipien des Scrum Frameworks zusammen. Zuletzt wurde er 2020 aktualisiert und hat dabei auch wieder ein paar Seiten abgespeckt. Denn die beiden Gründer wollen das Framework immer leaner gestalten.

In der Realität muss das Framework allerdings oft adaptiert werden, um in allen Branchen und Teams zu funktionieren. Das muss aber jedes Scrum Team für sich selbst herausfinden. In dieser Anleitung beschränken wir uns deshalb auf die offiziellen Regeln des Frameworks und gehen dabei in die Tiefe.

Scrum: Gründe für den Erfolg

9 von 10 Projekten in Handelsunternehmen, die agil gemanagt werden, werden mit Scrum gemanagt. Agilität ist im Trend – und Scrum ist es umso mehr. Weltweit nutzen mehr als 12 Millionen Menschen das Framework als Methode im Projektmanagement. Jedes zweite Großunternehmen setzt auf agile Methoden. 65% der deutschen Unternehmen hält Projekte, die agil gemanagt werden für erfolgreicher. (https://www.bitkom-research.de/de/pressemitteilung/scrum-koenig-unter-den-agilen-methoden). Die Zahlen sprechen für sich, nicht wahr? Doch was ist das Geheimnis hinter dem Erfolg des Frameworks? Wir haben dafür einige Gründe gefunden.

Scrum ist einfach …

Scrum besteht aus nur sehr wenigen Regeln und ist somit sehr einfach. Konkret besteht es aus nur drei Verantwortlichkeiten, fünf Events und drei Artefakten. Diese Einfachheit ist aus unserer Sicht der Hauptfaktor für den Erfolg von Scrum. Denn oft wird versucht, die Komplexität unserer Zeit und unserer Umwelt durch entsprechend komplexe Ansätze und Methoden zu managen. Der von Jeff Sutherland und Ken Schwaber veröffentlichte Scrum-Guide beschreibt das Framework allerdings auf mittlerweile lediglich 14 Seiten.

Scrum ist agil …

Und agil bedeutet Scrum. Keine andere Methodik, kein anderer Ansatz, keine andere Technik hat sich im Rahmen von Agilen Projekten so erfolgreich durchgesetzt wie das Scrum Framework. Wie schon beschrieben, setzen 85 Prozent aller agil gemanagten Projekte Scrum ein. Von Marktführerschaft zu sprechen wäre hier schon untertrieben. Zumal man davon ausgehen kann, dass die 15 Prozent, die von sich behaupten, dass sie nicht Scrum einsetzen, zumindest teilweise Aspekte von Scrum verwenden. So hat sich beispielsweise ein Daily Stand up in so gut wie allen agilen Projekten als Standard durchgesetzt.

Scrum ist hierarchielos …

Scrum gibt einen großen Teil der „Macht“ zu Managen und Organisieren an das Team zurück. Projektmanager und Projektmanagerinnen im klassischen Sinne gibt es nicht mehr. Die Annahme, die dem zugrunde liegt, ist, dass die Teams selbst ausreichend Motivation und genug Wissen haben, um sich selbst zu organisieren, und selbst am besten wissen, wie sie ein vorgegebenes Ziel erreichen. Und das ganz ohne detaillierten Projektplan und ganz ohne jemanden, der ihnen sagt, wann sie was genau zu tun haben. Es gibt in einem Scrum-Projektteam kein Hierarchiegefälle, sondern lediglich klar definierte Accountabilities (früher genannt: Rollen). Jeder und jede respektiert jeden und jede als gleichwertig und kennt die eigene Rolle ganz genau. So funktioniert Scrum.

Scrum ist pragmatisch …

Scrum kommt mit erstaunlich wenig Administration aus. Denkt man daran, wie viel Energie klassischen Wasserfall-Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentlichen Management des Projekts geht, wird schnell klar, warum Scrum so erfolgreich ist. All dieser Aufwand entfällt bei Scrum nahezu gänzlich. Scrum ist einfach pragmatischer und effizienter als andere Methoden. Kommunikation findet nicht mehr in Form von langen E-Mails, E-Mail-Ketten und Powerpoint-Präsentationen statt, sondern direkt von Angesicht zu Angesicht, ohne Medienbrüche, von Mensch zu Mensch. Probleme werden nicht über Ampeln kommuniziert, sondern direkt mit dem Betroffenen besprochen.

Scrum funktioniert …

Oft beschreiben die Gründer von Scrum, Jeff Sutherland und Ken Schwaber, Scrum mit sehr plakativen Aussagen wie beispielsweise „Wie Sie mit Scrum in der Hälfte der Zeit doppelt so viel erreichen können“. Diese Aussagen sind sicherlich etwas überspitzt. Dennoch kann man neidlos eingestehen, dass die Methodik von Scrum aufgrund der bereits oben beschriebenen Merkmale sehr effektiv und effizient ist – und deswegen einfach funktioniert. Andernfalls wäre es nicht möglich, dass Scrum so erfolgreich ist und seit über 20 Jahren weltweit immer größere Verbreitung findet

Scrum: Die Grundlagen

Was ist Scrum? Eine Methode, ein Tool, eine Technik, ein Prozess? Keines von allem. Fangen wir damit an, woher der Begriff kommt …

Scrum: Der Begriff

Der Begriff Scrum lässt sich auf die beiden japanischen Wirtschaftswissenschaftler Nonaka und Takeuchi zurückführen. Sie schreiben in ihrem im Jahr 1986 erschienenen Artikel „The New Product Development Game“ über den von ihnen so genannten „Rugby-Approach“. Dieser bedient sich einer Analogie aus dem Rugby. Sie gehen davon aus, dass einer der außergewöhnlichsten Erfolgsfaktoren von sehr erfolg- reichen Produktentwicklungsteams die räumliche Nähe des Teams während der Entwicklungsarbeit ist. So wie bei dem aus dem Rugby stammende Gedränge, welches Scrum genannt wird und bei dem viele Spieler eng zusammenstehen. Denn auch diese Teams arbeiten als kleine und selbstorganisierte Einheiten. Sie bekommen von außen nur eine grobe Richtung vorgegeben. Es bleibt in der Umsetzung jedoch ihnen überlassen, wie sie ihr gemeinsames Ziel erreichen. Und diese Art der Zusammenarbeit soll auch Projekte erfolgreich machen.

Dieser Rugby-Approach wurde dann mehr als zehn Jahre später von den Gründern von Scrum, Jeff Sutherland und Ken Schwaber, zu einem Framework für Softwareentwicklungsprojekte weiterentwickelt: Und dieses Framework nannten sie mit einem entsprechenden Verweis auf den Artikel von Nonaka und Takeuchi: Scrum. Da die Anfänge des Frameworks schon mehr als 20 Jahre zurückliegen und Scrum immer erfolgreicher geworden ist, haben sich immer mehr Scrum-Varianten entwickelt. Dies liegt daran, dass viele Autoren, Berater und Experten von dem erfolgreichen Framework ihren wirtschaftlichen Anteil abhaben wollten. So wurde der Kern dessen, was Scrum ausmacht, immer stärker verfälscht. Dieses Problem haben auch die beiden Scrum-Gründer, Jeff Sutherland und Ken Schwaber, erkannt und aus diesem Grunde im Jahr 2010 den Scrum-Guide veröffentlicht. Dieser wurde letztmalig in Jahr 2020 überarbeitet. Er fasst den Kern und das Grundverständnis von Scrum nach Sutherland und Schwaber zusammen.

Scrum: Empirische Prozesskontrolle

Die wissenschaftliche Basis von Scrum ist die Theorie der empirischen „Prozesssteuerung“, kurz auch „Empirie“ bzw. im Englischen Empirical Theory genannt. Die Empirie besagt, dass Wissen auf Erfahrung basiert. Und dass Entscheidungen auf der Basis von diesem bestehenden Wissen erfolgen. Scrum stellt durch seinen iterativen und inkrementellen Ansatz sicher, dass in regelmäßigen und kurzen Abständen die Möglichkeit zur Überprüfung und Anpassung besteht.

So wird regelmäßig Erfahrungen in Wissen transferiert. Dieses Wissen wiederum wird dann genutzt, um immer wieder Entscheidungen zu treffen. Je mehr Erfahrung, je mehr Wissen, und umso bessere Entscheidungen können getroffen werden. durch dieses Vorgehen können Risiken minimiert, frühzeitig erkannt und auch gegengesteuert werden.

Scrum: Die 3 Säulen

Transparency – Transparenz

Offene Kommunikation und das Teilen von Wissen ist die Grundlage für Transparenz. Zudem sollten das gesamte Vorgehen beziehungsweise der Prozess in einem agilen Projekt für alle Beteiligten transparent sein. Dies umfasst insbesondere auch die verwendeten Begriffe in einem Projekt. Jeder sollte unter den verwendeten Begriffen das gleiche verstehen. Als ein typisches Beispiel in einem Projekt zu nennen ist, dass es ein einheitliches Verständnis von „Done“ – also wann etwas erledigt ist – gibt. An welchen genauen Kriterien festzumachen ist, dass etwas erledigt ist.

Inspection – Überprüfung

Inspection bedeutet, dass alle Vorgehensweisen und Arbeitsergebnisse regelmäßig überprüft werden. In einem nach Scrum gemanagten Projekt bedeutet dies, dass das Team in regelmäßigen Abständen die Artefakte dahingehend überprüft, ob diese und ihre Ausgestaltung geeignet sind, um das jeweilige Sprint-Ziel zu erreichen. Die Überprüfung darf jedoch nicht so oft stattfinden, dass sie die eigentliche Projektarbeit behindert. Sie muss stets effizient bleiben. Die Überprüfungen müssen in einer Weise stattfinden, dass auch sie einen Mehrwert für die Projektarbeit darstellen.

Adaption – Anpassung

Adaption bedeutet das Anpassen an die Rahmenbedingungen, um nach jedem Sprint schneller und besser zu werden und das Ziel effizient zu erreichen. Wenn im Rahmen einer Überprüfung festgestellt wird, dass das Vorgehen oder die Arbeitsergebnisse ein nicht akzeptables Limit überschreitet, müssen Anpassungen vorgenommen werden. Diese Anpassungen müssen möglichst kurzfristig, ohne unnötigen Zeitverzug entschieden werden, um unnötige weitere Abweichungen zu verhindern.

Die fünf Values von Scrum

Denn die fünf Values sorgen dafür, dass die drei Säulen von Scrum gelebt werden. Wir beschreiben diese fünf Values im Folgenden kurz – in Anlehnung an den Scrum-Guide. Wir finden, hier ist es jedem Scrum-Team selbst überlassen, wie es diese Values konkret für sich definiert, lebt und umsetzt. Diese Vorgehensweise folgt der grundsätzlichen Logik von Scrum, einfach zu sein, wenige Regeln aufzustellen und die Ausgestaltung im Sinne der Flexibilität dem Projektteam zu überlassen. Grundsätzlich ist es auch so, dass Scrum zwar klare Regeln aufsetzt. Im Sinne von Überprüfung und Anpassungen können die Regeln jedoch für jedes Projekt im Detail so konkretisiert werden, dass sie auf das jeweilige Projekt und für das jeweilige Projektumfeld passen. Trotz sehr klarer und eindeutiger Regeln bietet Scrum, wie gesagt dennoch Raum zur individuellen Ausgestaltung.

Courage – Mut

Die Mitglieder des Scrum-Teams haben den Mut, die richtigen Dinge zu tun und an den Herausforderungen und Problemen im Projekt zu arbeiten.

Focus – Fokussierung

Jeder fokussiert sich auf die Arbeit des aktuellen Sprints und auf die Ziele des Scrum-Teams.

Commitment – Selbstverpflichtung

Jeder verpflichtet sich, persönlich die Ziele des Scrum-Teams zu unterstützen und zu erreichen.

Respect – Respekt

Die Mitglieder des Scrum-Teams respektieren sich und befähigen sich gegenseitig, kompetente und unabhängige Individuen zu sein.

Openness – Offenheit

Das Scrum-Team und seine Stakeholder einigen sich darauf, bezogen auf die Arbeit und die mit dieser verbundenen Herausforderungen offen zu sein.

Wie funktioniert Scrum?

Im Folgenden erklären wir, wie Scrum funktioniert, also welche Methoden und Techniken im Rahmen das Scrum Frameworks zum Einsatz kommen. Der Kern der Methode ist der Scrum-Prozess. Dieser Begriff stammt nicht von den Vätern von Scrum, sondern wurde von uns aus didaktischen Gründen definiert. Im Rahmen des Scrum-Prozesses wird im Wesentlichen dargestellt, welche Events und welche Artefakte wie zusammenspielen und in welchem zeitlichen Verlauf erfolgen. Letztlich zeigt der Scrum-Prozess, wann welche Events stattfinden und welche Artefakte wann zum Einsatz kommen.

Die Scrum Rules

Die Scrum Rules sind im Scrum Guide niedergeschrieben. Sie beschreiben, wie die wesentlichen Elemente von Scrum – Roles, Events und Artefacts – zusammen­spielen. Sie liefern also beispielsweise die Antwort darauf, wann welches Event stattfindet, welche Rollen in welchem Event anwesend sind, welche Aufgaben sie hierbei haben – oder auch welche Rolle für welches Artefact zuständig ist. Die Details der Regeln werden im weiteren Verlauf dieses Buchs ausführlich erklärt.

Accountabilities

Die Accountabilities regeln die Aufgaben jedes einzelnen Teammitglieds, je nachdem, welche der drei festgelegten Accountabilities jemand einnimmt. Jede Verantwortlichkeit hat konkrete Aufgaben, Rechte und Pflichten. Die drei Accountabilities, die früher Rollen genannt wurden sind: Product Owner, Scrum Master und Developers.

Artefakte

Dies sind bestimmte Tools und Techniken, die die Anwendung von Scrum erfolgreich machen und notwendig sind, den Projektablauf effizient zu gestalten. Die Artefakte sind: Sprint Backlog, Product Backlog und Inkrement.

Events

Sie regeln Form, Frequenz und Inhalte der Kommunikation zwischen den Accountabilities und den Mitgliedern im Projekt.

Rules

Regeln bestimmen das Zusammenspiel und die Wechselwirkungen der Accountabilities, Artefakte und Events.

Dieses Scrum-Rahmenwerk beziehungsweise Scrum Framework ist in dieser Form auch im von Jeff Sutherland und Ken Schwaber veröffentlichten Scrum-Guide so beschrieben. Alle weiteren Komponenten und Elemente, die über diese hier genannten Komponenten hinausgehen, wurden von anderen Autoren und von Praktikern im Laufe der Jahre zu Scrum ergänzt. Es ist nicht zu empfehlen, dass Scrum durch die Ergänzung anderer Elemente verfälscht wird. Zumindest wenn man ein Projekt rein agil managen will. Elemente aus Scrum in das klassische Projektmanagement zu übernehmen kann hingegen durchaus Sinn machen.

Die einzelnen Accountabilities gemäß Scrum stehen während des gesamten Scrum-Pro­zesses in Interaktion. Um einen Gesamtüberblick von Artefakten und Events der jeweils zum jeweiligen Zeitpunkt eingebundenen Rollen zu bekommen, haben wir den Scrum Framework-Überblick erstellt.

Der Scrum Prozess

Der Prozess beginnt, wenn ein oder einige Stakeholder ein Produkt benötigen. Die Anforderungen an das Produkt werden dann in einem so genannten Product Backlog gesammelt. Das Product Backlog ist also die Zusammenfassung aller Produkteigenschaften, die das finale Produkt umfassen sollte. Nachdem das Product Backlog vollständig ist, beginnt man mit dem Sprint Planning. Hier wird geplant, welche Produktfeatures im kommenden Sprint umgesetzt werden sollen. Diese Teilmenge der Produkteigenschaften wird dann in ein Sprint Backlog überführt. Das Sprint Backlog umfasst somit alle Produkt­eigenschaften die im kommenden Sprint umgesetzt werden sollen. Diese sind sozusagen das Sprint-Ziel.

Danach beginnt der Sprint. Der Sprint ist die eigentliche Phase der Produktentwicklung. Im Rahmen der Produktentwicklung erfolgt dann ein täglicher Austausch des Teams im Rahmen des Daily. Nach Abschluss des Sprints sollten als Ergebnis neue Produkteigenschaften für das Produktinkrement hervorgebracht werden. Ein Produktinkrement ist hierbei ein fertiger Teil des Gesamtproduktes. Nach dem Sprint besteht die Möglichkeit des Überprüfens und Anpassens in Form eines Sprint-Reviews. Hierbei wird das Produkt, das entwickelt wird, überprüft und gegebenenfalls angepasst. So besteht einerseits die Möglichkeit für alle, die nicht selbst am Entwicklungsprozess beteiligt waren, Informationen über den aktuellen Entwicklungsstand zu erhalten, wie beispiels­weise die Stakeholder. Alle diejenigen, die an der Entwicklung direkt beteiligt waren, erhalten so das Feedback, inwiefern sie sich mit der Arbeit im letzten Sprint bezogen auf die Produkteigenschaften des gesamten Produkts angenähert haben.

Die Scrum Events

Events gemäß Scrum finden immer in persönlicher Form statt. Sie erfolgen regelmäßig, um kontinuierlich überprüfen und anpassen zu können. Alle Events haben ein festes Zeitfenster. Dieses Zeitfenster wird auch Timebox genannt. Das bedeutet, dass für jedes Event ein Zeitrahmen vorgegeben ist, der auf jeden Fall eingehalten wird. Die Einhaltung dieses Zeitfensters ist Aufgabe des Scrum Masters. Gibt es dennoch mehr Themen als es die Zeit des Events hergibt, so werden diese Themen auf das nächste Event verschoben.

Charakteristik von Events

Events nach Scrum haben eine ganz spezielle Charakteristik, die Events nach Scrum erst „typisch“ Scrum werden lassen. Diese lassen sich wie folgt beschreiben.

Regelmäßigkeit

Um den iterativen Charakter von Scrum sicherzustellen, finden die Events bei Scrum regelmäßig statt. Es gibt eine feste Frequenz, in denen die Events stattfinden. Diese Frequenz wird nicht verändert oder angepasst. Sie wird während des gesamten Projekts konsequent verfolgt. Auch der Ort der jeweiligen Events sollte immer der gleiche sein. Diese Regelmäßigkeit und die klare Definition von Frequenz und Ort stellen den Fluss und die Effizienz des SCRUM-Prozesses sicher.

Timebox

Für jedes Event ist ein fester Zeitrahmen vorgegeben. Das bedeutet, dass für jedes Event vorher ein Zeitfenster festgelegt wurde. Dieses wird auf jeden Fall eingehalten. Wenn das Zeitfenster abgelaufen ist, ist das Event beendet. Es gibt keine Verlängerung des Events. Themen, die noch offen sind, werden dann im nächsten Event besprochen beziehungsweise auf das nächste Event verschoben. Zudem finden die Events gemäß Scrum immer zum gleichen Zeitpunkt, also bezogen auf die Uhrzeit und den Wochentag, statt. Dies vermindert den koordinativen Aufwand der Event-Organisation. Eine Verschiebung von Events oder immer wieder neue Festlegung des Zeitpunkts von Events ist bewusst nicht vorgesehen.

Die fünf Events von Scrum

Nach Scrum gibt es genau fünf Events, die im Rahmen eines nach Scrum gemanagten Projektes stattfinden. Weitere Events sind nicht vorgesehen. Es ist jedoch wichtig zu erwähnen, dass dies nicht bedeutet, dass es keine Kommunikation außerhalb der Scrum-Events geben darf. Nur die Art und Anzahl der Events selbst ist klar vorgeben.

Der Sprint

Das Ziel des Sprints ist es, die jeweiligen Ziele beziehungsweise das jeweilige Ziel, das sich die Developers für den jeweiligen Sprint vorgenommen haben, zu erreichen. Konkret sind die im Rahmen des Sprints umzusetzenden Produkteigenschaften in Sprint Backlog festgehalten. Der Sprint selbst ist kein eigenständiges Event, sondern die Klammer um mehrere Events, die innerhalb des Sprints stattfinden. Insofern gibt es keine konkrete Form, wie der Sprint selbst stattfindet. Die Events, die innerhalb des Sprints stattfinden, sind: Sprint Planning, Daily Scrum, die Entwicklungsarbeit, der Sprint Review und die Retrospektive. Teilnehmer innerhalb des Sprints sind der Product Owner, der Scrum Master, die Developers (Entwickler*innen) und die Stakeholder.

Der Sprint selbst wird nicht moderiert, da er wie schon erwähnt eine Klammer bzw. einen Container um mehrere Events darstellt. Insofern gibt es auch keine Agenda des Events selbst. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. Der Anspruch an die Qualität der Arbeit darf nicht geändert werden. Der Scope des Sprints darf zwischen dem Product Owner und dem Entwicklungsteam verhandelt werden, wenn er dem Lernen dient. Die Agenda des Sprints ist quasi die Abarbeitung des Sprint Backlogs. Innerhalb des Sprints haben die beteiligten Rollen die Aufgaben, Kompetenzen und Verantwortung, die ihnen auch grundsätzlich gemäß ihrer Rollendefinition zukommen. Das Ergebnis des Sprints ist die Abarbeitung der für den Sprint vorgesehen Produkteigenschaften gemäß dem Product Backlog.

Wie lange dauert ein Sprint?

Die Dauer des Sprints ist unterschiedlich. Ein Sprint kann wenige Tage gehen bis hin zu einem Monat. Die maximale Dauer des Sprints sind vier Wochen beziehungsweise ein Monat. Wichtig ist, dass die Sprints immer die gleiche Dauer haben. Hintergrund ist, dass es sich erwiesen hat, dass die Leistungsfähigkeit der Sprint-Teams am höchsten ist, wenn die Dauer jeweils gleich lange ist. Grundsätzlich kann man sagen, dass Sprints immer so kurz wie nur möglich sein sollten. Wenn ein Sprint zu Ende ist, beginnt schon der nächste Sprint. Es gibt demnach quasi keine Pause zwischen den einzelnen Sprints. Auf jeden Sprint folgt sofort der nächste Sprint.

Wie viele Sprints innerhalb eines Scrum-Projektes stattfinden, ist unterschiedlich. Letztendlich finden Sprints statt, so lange das Produkt bzw. die Dienstleistung, die entwickelt wird, besteht. Die Struktur innerhalb eines Sprints ist auch immer die gleiche. Ein Sprint beginnt immer mit dem Sprint Planning als erstem Event.

Das Sprint Planning

Das Ziel des Sprint Plannings ist, den jeweils anstehenden Sprint zu planen. Der Sprint erfolgt in Form eines Präsenz-Events, das immer als allererstes Event eines Sprints stattfindet. Das Sprint Planning findet einmal pro Sprint statt. Jeder Sprint beginnt damit.

Am Sprint Planning nimmt das gesamte Scrum-Team teil, also der Product Owner, der Scrum Master und die Developers. Das Sprint Planning dauert bei einem Sprint von vier Wochen maximal acht Stunden. Dauert der Sprint weniger als vier Wochen, passt sich die Dauer des Sprint Plannings auch entsprechend proportional an und ist kürzer.

Der Scrum Master ist dafür verantwortlich, dass das Sprint Planning stattfindet und dass alle Mitglieder des Scrum-Team verstehen, was das Ziel des Events ist. Er ist zudem dafür verantwortlich, dass das Sprint Planning im vereinbarten Zeitfenster bezüglich der Dauer bleibt. Das Sprint Planning ist in zwei Teile gegliedert.

Das Daily Scrum

Nachdem das Spring Planning abgeschlossen wurde, beginnt das Entwicklungsteam seine Arbeit. Konkret bedeutet dies, dass es die Aufgaben, die im Sprint Planning definiert wurden, im Team selbstorganisiert bearbeitet. Wichtig ist hierbei, dass die Developers die Aufgaben nacheinander abarbeiten und im Idealfall gemeinsam und gleichzeitig am gleichen Backlog Item arbeiten. Während dieser Entwicklungsarbeit trifft sich das Scrum-Team physisch einmal an jedem Tag, an dem gearbeitet wird, zum Daily Scrum.

Dieses findet immer zur gleichen Zeit am gleichen Ort statt. Grund hierfür ist, dass die organisatorische Arbeit der Eventplanung und die Komplexität reduziert werden soll. Die Dauer des Daily Scrum ist auf maximal 15 Minuten beschränkt. Das Ziel des Daily Scrum ist, dass sich die Developers abstimmen und synchronisieren.

Wie läuft das Daily Scrum ab?

Bei jedem Daily Scrum wird die Entwicklungsarbeit für die nächsten 24 Stunden geplant. Hierbei werden immer zuerst die Arbeit der letzten 24 Stunden transparent gemacht und ein Ausblick auf die Aufgaben der nächsten 24 Stunden gegeben. Die Developers besprechen hierbei den Fortschritt der letzten 24 Stunden mit Hinblick auf das Sprint-Ziel. Zudem analysiert es, wie der Fortschritt bezogen auf die Backlog Items, die im Sprint Backlog sind, ist. Hauptziel des Daily SCRUM ist es, die Wahrscheinlichkeit zu maximieren, dass die Entwicklerinnen und Entwickler das Sprint-Ziel auch erreichen.

Die Agenda des Events wird von den Developers selbst festgelegt. Es gibt keine konkreten Vorgaben gemäß Scrum, wie das Daily Scrum strukturiert werden soll, so lange alles darauf abzielt, dass das Sprint-Ziel erreicht wird. Es gibt Developer Teams, die strukturierte Fragen nutzen, wie die folgenden:

1. „Was habe ich gestern für die Developers getan, um das Sprint-Ziel zu erreichen?“
2. „Was werde ich heute für die Developers tun, um das Sprint-Ziel zu erreichen?“
3. „Gibt es irgendwelche Hindernisse, die mich oder die Developers dar­an hindern, das Sprint-Ziel zu erreichen?“

Andere Developer Teams hingegen nutzen das Daily Scrum für ausführliche Diskussionen. Die genaue Agenda des Daily Scrum ist dem Scrum-Team letztlich freigestellt, so lange es darum geht, das Sprint-Ziel zu erreichen und die maximale Dauer von 15 Minuten einzuhalten.

Der Sprint Review

Der Sprint Review findet immer am Ende der Entwicklungsarbeit statt. Er dient dazu, die wichtigsten Ergebnisse aus dem Sprint zu präsentieren und um zu überprüfen und gegebenenfalls anzupassen. So kann der neueste Stand des Produktinkrements transparent gemacht werden, und das Product Backlog kann entsprechend aktualisiert werden. Der Sprint Review findet in Form eines physischen Events statt. Der Product Owner lädt zu dem Event ein. Das gesamte Team ist beim Sprint Review anwesend. Zudem sind auch die Stakeholder mit eingeladen. So erhalten sie einen Überblick über den neuesten Stand der Entwicklungsarbeit und können dem Entwicklungsteam gleichzeitig Feedback geben.

Die Präsentation der Ergebnisse des Sprints dient im Wesentlichen dazu, Feedback zu ermöglichen und die Zusammenarbeit zu fördern. Der Sprint Review dauert maximal vier Stunden bei einem Sprint, der vier Wochen dauert. Wenn die Dauer des Sprints kürzer ist, dann sollte auch der Sprint Review entsprechend angepasst werden. Der Scrum Master ist dafür verantwortlich, dass das Event stattfindet und dass alle den Grund des Events kennen. Zudem unterstützt der Scrum Master dabei, dass jeder, der am Event teilnimmt, dazu beiträgt, dass das Event in dem festgelegten Zeitrahmen bleibt.

Der Sprint Review hat typischerweise die folgende Agenda:

• Die Developers stellen die Arbeit vor, die erledigt, „Done“ ist und beantworten Fragen über das Produktinkrement.
• Der Product Owner läutert, welche Items des Product Backlog erledigt, also „Done“ sind und welche nicht.
• Der Product Owner diskutiert das Product Backlog in seinem aktuellen Stand. Er gibt einen Ausblick auf künftige Lieferdaten und Ziele basierend auf dem aktuellen Fortschritt (sofern dies notwendig ist).
• Die gesamte Gruppe (Scrum-Team und Stakeholder) arbeitet zusammen daran, was als nächstes getan werden sollte, so dass der Sprint Review einen wertvollen Input für das nächste Sprint Planning liefert.
• Überprüfung, wie sich der Markt oder der potenzielle Einsatzbereich des Produkts geändert haben könnte bezogen darauf, was der beste nächste Schritt wäre.
• Überprüfung des Zeitplans, des Budgets, der potenziellen Ressourcen und des Markt für das nächste anstehende Release bezüglich der Funktionen und Capabilities des Produkts.

Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog. Das Product Backlog kann auch grundlegend angepasst werden, wenn sich neue Möglichkeiten ergeben.

Die Sprint-Retrospektive

Das Ziel der Sprint-Retrospektive ist, Feedback einzuholen, um den Entwicklungsprozess organisatorisch und strukturell zu verbessern. Es geht also nicht um Feedback zur erzielten Arbeit wie beim Sprint Review, sondern um die Arbeitsweise, wie sie war und was verbessert werden kann. Im Kern geht es darum, dass Verbesserungspotenzial bezogen auf Menschen, Interaktionen, Prozess und Werkzeuge identifiziert wird.

Das Event findet immer nach dem Sprint Review und vor den kommenden Sprint Planning statt. Das Event erfolgt in Form eines Präsenz-Events. An dem Event nimmt das gesamte Team, nicht jedoch die Stakeholder teil. Dies liegt daran, dass die Sprint Retrospektive sich auf eine Verbesserung der Entwicklungsarbeit bezieht, also die Art und Weise, wie das Entwicklungsteam inklusive dem Rest des Teams zusammengearbeitet hat. Der Fokus der Stakeholder liegt jedoch auf dem Ergebnis dieses Prozesses, also dem Produkt. Die Dauer des Events ist auf maximal drei Stunden begrenzt bei einem Sprint von einer Dauer von vier Wochen. Bei einem kürzeren Sprint dauert die Sprint Retrospektive entsprechend kürzer.

Der Scrum Master ist für die Organisation des Events zuständig. Zudem muss er dafür sorgen, dass alle Teilnehmer den Grund des Events kennen. Er nimmt an dem Event teil, da er für die Einhaltung der Regeln verantwortlich ist. Die Sprint-Retrospektive ist eines der wesentlichsten Events, in denen der Scrum Master die Einhaltung der Regeln überprüfen und eventuell coachend aktiv werden kann. Er hat auch dafür Sorge zu tragen, dass das Event produktiv und positiv verläuft. Zudem sollte er oder sie alle Teilnehmen dazu anhalten, dass das Event im geplanten Zeitrahmen bleibt.

Die folgenden Ziele des Events bestimmen seine Agenda:

• Überprüfung des vergangenen Sprints mit Fokus auf die Menschen, Beziehungen, Prozesse und Tools.
• Identifikation und Strukturierung der Themen, die gut gelaufen sind, und potenzieller Verbesserungsfelder.
• Erstellung eines Plans, um die Verbesserungsfelder umzusetzen.

Im Rahmen der Retrospektive werden verschiedene Methoden genutzt, um Feedback einzuholen. Die einfachste Art und Weise ist es, eine Metaplanwand in drei Felder zu teilen: Liked, Learned, Lacked. Jedes Mitglied des Teams schreibt auf eine Metaplankarte, was ihm zu diesen drei Punkten einfällt, und pinnt es an die Wand. Der Scrum Master moderiert dann das, was an die Wand gepinnt wurde, und erarbeitet mit dem Team die Verbesserungspotenziale und einen Plan, wie diese umgesetzt werden können.

Die Accountabilities

Scrum kennt eine sehr einfache und übersichtliche Definition der unterschied­lichen Accountabilities im Rahmen des Scrum-Frameworks. Für jede dieser Verantwortlichkeiten ist ganz klar beschrieben, was ihre Aufgaben sind und welche Kompetenzen und Verantwortungen sie haben. Es ist wichtig, dass jedes Mitglied des Scrum-Teams weiß, welche Verantwortlichkeit er oder sie hat und welche Erwartungen an diese (früher genannt) Rolle gestellt werden. Dies ist notwendig, um Scrum erfolgreich umzusetzen. Während die Werte nach Scrum für alle Mitglieder des Scrum-Teams gelten, so definieren die Accountabilities für jedes einzelnes Teammitglied andererseits ganz konkret und individuelle Aufgaben.

Das Scrum-Team

Das Scrum-Team arbeitet selbstorganisiert und interdisziplinär. Letztlich geht man gemäß Scrum davon aus, dass das Scrum-Team hoch motiviert ist und selbstständig entscheiden kann, wie es das jeweilige Ziel erreicht. Es erledigt seine Arbeit, ohne dabei auf Personen von außerhalb des Scrum-Teams angewiesen sein zu müssen. Zudem sind Scrum-Teams interdisziplinär und bestehen aus maximal 10 Personen.

Interdisziplinär bedeutet hierbei, dass die Teams interdisziplinär bezüglich ihrer Fähigkeiten und Fertigkeiten gemischt sind. Oft werden in Projekten, die nicht nach Scrum gemanagt werden, einzelne Teilprojekte nach Funktionsträger*innen oder Fachbereichen gebildet. Ein Beispiel hierfür ist ein Teilprojekt für die Produktstrategie und ein Teilprojekt für die IT-Umsetzung. In Scrum werden diese einzelnen Personen und Themen alle gemeinsam in einem Team vereint. Eine Trennung in Teilprojekte gibt es so nicht mehr.

Die Scrum Stakeholder

Das Framework kennt insgesamt drei Rollen, diese werden in ihrer Gesamtheit als Team bezeichnet. Alle diejenigen, die nicht Teil des Teams sind, jedoch ein Interesse an der Entwicklung des Produktes bzw. Wissen über das Produkt haben, werden Stakeholder genannt. Stakeholder sind also nicht Teil des Teams selbst. Und dennoch nehmen sie am Prozess in jeweils unterschiedlicher Weise teil. Typische Stakeholder in Projekten sind: Kund*innen, Benutzer*innen, Management.

Überblick der Scrum Accountabilities

Weitere Accountabilities kennt Scrum im Kern nicht. Dennoch gibt es für das Management größerer Einheiten und mehrerer Teams andere Frameworks, wie beispielsweise das Scaled Agile Framework oder das Large Scale Scrum. Diese stellen Weiterentwicklungen von Scrum dar und gehen nur teilweise auf die Ursprünge von SCRUM zurück. Wie gesagt, sind diese Frameworks nicht Kern der eigentlichen Methode. Deswegen werden wir auf diese auch nicht weiter an dieser Stelle eingehen. In Scrum gibt es lediglich drei Accountabilities, welche sich auch als absolut ausreichend zum Management eines agilen Projekts erwiesen haben.

Scrum kennt im Kern also nur drei Accountabilities: den Product Owner, den SCRUM Master und die Developers. Die Hauptaufgaben dieser Accountabilities sind die folgenden:

• Product Owner: Er vertritt die Interessen des Auftraggebers oder des Kunden. Er ist verantwortlich für den geschäftlichen Erfolg des Produkts.
• Scrum Master: Er ist die dienende Führungsperson (Servant Leader) und verantwortlich für die Implementierung der SCRUM-Regeln. Wir sprechen hier gerne vom Regelhüter, Moderator und Coach. In englischer Sprache wir oft von „Servant Leader“ gesprochen.
• Developers/Entwickler*innen: Die Developers entwickeln das Produkt. Sie sind verantwortlich dafür, sich selbst so zu organisieren, um das jeweilige Ziel des Sprints zu erreichen. Die Entwicklerinnen und Entwickler sind zusammen das Herzstück von Scrum. Sie sind für den wichtigsten Teil im Rahmen eines Scrum-Projektes zuständig: das Entwickeln des Produktes.

Der Product Owner

Der Product Owner ist für das „Was“ zuständig. Was wird umgesetzt, um den Wert des Produktes zu maximieren? Er hat die folgenden Aufgaben, Verantwortungen und Kompetenzen:

Aufgaben des Product Owners

Der Product Owner ist während des gesamten Prozesses sehr aktiv eingebunden. Er hat zu Beginn des Prozesses die Aufgabe, in Abstimmung mit den Stakeholder die Ausstattungsmerkmale des zu entwickelnden Produktmerk­male abzustimmen. Zudem hat er diese Produktmerkmale dann entsprechend auch strukturiert in Form eines Product Backlogs zu managen. Sein wesentliches Werkzeug ist das Product Backlog. Während der Entwicklungsarbeit selbst zieht er sich etwas zurück und überlässt die wichtigsten Entscheidungen den Developers selbst.

Nach einem Sprint beziehungsweise zum Ende des Sprints wird er wieder aktiver in der Form, dass er seinen Blick darauf lenkt, ob im Rahmen der Entwicklungsarbeit die wichtigsten Product Backlog Items abgearbeitet wurden. Konkret hat er die folgenden Aufgaben:

• Wertmaximierung des Produkts durch Priorisierung des Product Backlogs
• Wert der Arbeit der Developers optimieren
• Product Owner kann diese Aufgaben alleine erfüllen oder delegieren
• Product Owner bleibt jedoch verantwortlich
• Hat eine Vision für das Produkt und brennt für das Produkt

Kompetenzen des Product Owners

Der Product Owner hat die Kompetenz für die folgenden Themen:

• Er hat die Kompetenz, als einziger im Scrum-Team den Developers Aufgaben, in Form von im Backlog definierten Anforderungen zu übertragen.
• Er handelt im Auftrag der Stakeholder, wie beispielsweise des Kunden oder des Managements, beziehungsweise er vertritt deren Interessen im Rahmen des Scrum-Prozesses. Und hat alle Vollmachten bezogen auf das Produkt, um es erfolgreich zu machen.
• Dem Product Owner „gehört“ quasi das Produkt. Im Idealfall ist er auch derjenige, der über das Budget verfügt, das notwendig ist, um das Produkt zu entwickeln.
• Er ist Eigentümer des Product Backlogs und legt die Kompetenz die Backlog Items im Product Backlog fest bzw. priorisiert sie.

Verantwortung des Product Owners

Der Product Owner ist verantwortlich für die folgenden Themen:

• Verantwortung für den finanziellen Erfolg des Produktes
• Wertmaximierung des Produktes allgemein und in jedem Sprint
• Management und Pflege des Product Backlogs
• Einträge im Product Backlog müssen klar formuliert werden
• Einträge im Product Backlog sollen so sortiert werden, dass Ziele und Missionen optimal erreicht werden
• Die gesamte Organisation muss den Product Owner respektieren
• Entscheidungen des Product Owner müssen in Inhalt und Reihenfolge des Product Backloks sichtbar sein.

Der Product Owner ist eine Rolle im Scrum-Team, die nur von einer einzelnen Person durchgeführt werden darf. Dies hat den Grund, dass nur so sichergestellt werden kann, dass es immer eine eindeutige Priorisierung der Backlog Items gibt. Zudem gibt es so stets klare Antworten auf Fragen sowohl des Entwicklungsteams als auch der Stakeholder. Er hat zudem die Verantwortung, die Ziele und Anforderungen der Stakeholder zu bündeln und im Rahmen der Entwicklungsarbeit zu vertreten.

Aus diesem Grund hat der Product Owner quasi zwei Gesichter; eines, das den Stakeholdern zugewandt ist: Hier geht es darum, fortlaufend die Anforderungen der Stakeholder zu verstehen, zu sortieren und bündeln. Und ein weiteres Gesicht, das den Developern zugewandt ist: Hier ist seine Aufgabe, die Entwicklungsarbeit durch klare Vorgaben im Product Backlog effizient zu gestalten. Und auch Entwicklungsergebnisse nach klar definierten Abnahmekriterien zu bewerten beziehungsweise abzunehmen.

Der Scrum Master

Der Scrum Master ist quasi für alles, was ein Scrum-Projekt für ein Scrum-Projekt charakteristisch macht, verantwortlich: Die Scrum-Regeln. Er stellt sicher, dass alles während des Sprints nach den Vorgaben von Scrum abläuft.

Aufgaben des Scrum Masters

Der Scrum Master wird auch als „Servant Leader“ bezeichnet. Übersetzt heißt dies, dass er oder sie eine „dienende Führungskraft“ ist. Was bedeutet das? In Scrum gibt es keinen mit Führungskompetenzen ausgestatteten Projektleiter beziehungsweise Projektmanager. Jedoch hat der Scrum Master viele Aufgaben, die sonst einem klassischen Projektmanager zugesprochen würden. Denn er hat den gesamten Prozess und seine Kommunikations- und Event-Strukturen nach den Regeln von Scrum zu gestalten. Hierbei ist seine Rolle die eines Coachs beziehungsweise eines Moderators.

Der Scrum Master hat die Aufgabe, die anderen Teammitglieder im Team dazu zu befähigen, die Regeln von Scrum für eine möglichst effiziente Projektarbeit anzuwenden. Er hat auch dafür Sorge zu tragen, allen, die nicht Teil des Teams sind, zu vermitteln, wie die Interaktion mit dem Scrum-Team erfolgreich sein kann. Zudem unterstützt er alle dabei, diese Interaktionen so zu gestalten, dass sie einen maximalen Wert der Arbeit des Scrum-Teams sicherstellen.

Verantwortung des Scrum Masters

Die Rolle des Scrum Master ist dafür verantwortlich, dass alle Beteiligten die Scrum-Theorie, Praktiken, Regeln und Werte verstehen. Der Scrum Master verbreitet also die Scrum Botschaft innerhalb der Organisation.

Kompetenzen des Scrum Masters

Ein Scrum Master hat die folgenden Themen als Kompetenz: Der Scrum Master hat die Kompetenz, alle Scrum-Teammitglieder darauf hinzuweisen, wenn Scrum-Regeln nicht richtig angewendet wurden. Zudem hat er die Kompetenz, jederzeit Maßnahmen zu ergreifen, die dazu notwendig sind, das Verständnis der Scrum-Regeln im Scrum-Team zu stärken und so auch deren Anwendung zu verbessern.

Da der Scrum Master diese unterstützende Funktion im Rahmen des Scrum-Prozesses hat, werden seine Aufgaben im Folgenden so strukturiert, dass deutlich wird, welche Aufgaben er unterstützend für die anderen Rollen innerhalb des Scrum-Teams hat und welche auch für alle außerhalb des Scrum-Teams.

Grundsätzliche Aufgaben des Scrum Masters

Der Scrum Master ist somit ein Regelhüter im Rahmen des Prozesses. Er oder sie hat zu jedem Zeitpunkt im Rahmen der Entwicklungsarbeit, der Events etc. sicherzustellen, dass alle Beteiligten sich an die Regeln gemäß Guideline halten, und auch alle Events in der entsprechenden Form stattfinden. Er oder sie fungiert hierbei als Moderator*in und Coach. Dies bedeutet, dass der Scrum Master zu keiner Zeit als Projektmanager oder Projektleiter agiert; die Aufgabe ist lediglich unterstützend im Scrum-Prozess. Das Ziel ist es, das Team zu befähigen, nach den Regeln zu arbeiten und effizient zu sein.

Die Developers 

Die Developers sind für das „Wie“ verantwortlich: Wie wird das Produkt entwickelt und umgesetzt?

Charakteristiken der Developers

Developers nach haben ganz spezielle Charakteristika, die den Spirit von Scrum ausmacht. Diese werden im Folgenden beschrieben.

Teamgröße

Die Developers bilden zusammen ein Team bestehend aus drei bis neun Teammitgliedern. Es werden sieben Personen als optimal angesehen. Im Rahmen dieser Berechnung werden der Scrum Master und der Product Owner nicht mitgezählt. Sie sind zwar Mitglieder des Teams, jedoch nicht der Developers.

Selbstorganisierend

Die Developers haben keine Projektleiter oder Teilprojektleiter. Sie organisieren sich selbst. Es ist die Aufgabe der Organisation beziehungsweise des Unternehmens, alles dafür zu tun, dass die Developers sich selbst organisieren und managen können. Es sorgt für alle Kompetenzen und Ressourcen, die hierzu erforderlich sind. Die einzige Vorgabe, die die Entwicklerinnen und Entwickler von dem Product Owner bekommt, ist die Art und die Priorität der Produkteigenschaften, die in allen Sprints umgesetzt werden sollen. Diese sind im so genannten Product Backlog gespeichert. Wie die Developers die Produkteigenschaften des Sprint Backlogs und die Ziele des Sprints erreichen, ist allein den Teams überlassen.

Interdisziplinär

Wie beschrieben, arbeiten die Developers interdisziplinär. Das bedeutet, dass verschiedene Kompetenzen und Fähigkeiten innerhalb des Teams vorhanden sind.

Keine Titel

Innerhalb der Developers gibt es keine Titel. Die Rollen innerhalb des Entwicklungsteams sind alle gleichrangig. Titel sind damit nicht relevant. Das bedeutet jedoch nicht, dass es nicht unterschiedliche Aufgabenverteilungen innerhalb der einzelnen Developers gibt. Diese Aufgabenverteilung ist jedoch stets durch die jeweilige Aufgabe definiert und manifestiert sich nicht durch die Vergabe eines Titels innerhalb der Developers.

Die Developers bleiben als Ganzes verantwortlich

Die Entwicklerinnen und Entwickler können zwar Aufgaben innerhalb des Teams mit unterschiedlichen Kompetenzen organisieren, dennoch bleiben sie immer gemeinsam für die Erreichung des Ziels eines Sprints verantwortlich. Keiner der Developers trägt mehr oder weniger Verantwortung als ein anderer im Team. Sie sind immer gemeinsam als Team verantwortlich für den Erfolg.

Aufgaben der Developers

Die Hauptaufgabe der Developers ist es, das Produkt richtig zu bauen beziehungsweise zu entwickeln. Die Developers sind die einzigen, die am Inkrement arbeiten. Alle anderen Aufgaben der Developers haben sich dieser Hauptaufgabe unterzuordnen und sind lediglich unterstützend, um dies während des Sprints sicherzustellen.

Es ist wichtig, dass die einzelnen Aufgaben beziehungsweise Tasks an die verschiedenen Developers übertragen werden. Die Aufgabenverteilung unter den Entwickler*innen nehmen diese selbst vor. Im Idealfall arbeiten möglichst viele der Developers an einem Backlog Item. Es sollte vermieden werden, dass zu viele Mitglieder des Entwicklungsteams an zu vielen unterschiedlichen Backlog Items parallel arbeiten. Es gilt also das Prinzip der Fokussierung und der priorisierten Abarbeitung nacheinander. Auch bei der Verteilung unterschiedlicher Aufgaben auf verschiedene Mitglieder der Developers bleibt die Verantwortlichkeit beim gesamten Team.

Verantwortung der Developers

Die Developers haben die folgenden Themen zu verantworten:

• Verantwortung für die Entwicklung des aktuellen Inkrements
• Priorisierung der Aufgaben der einzelnen Developers
• Organisation des Daily Scrum (Räume etc.)
• Tägliche Teilnahme und Mitwirkung im Daily Scrum
• Leitung des Daily Scrum nach den Regeln von Scrum
• Tracking des Fortschritts im Sprints inklusive Aktualisierung der Tools die hierfür verwendet -werden (bspw. Taskboard, SprintBurn-down Chart )

Kompetenzen der Developers

Die folgenden Themen gehören zu den Kompetenzen der Developers:

• Eigentümer des Sprint Backlogs. Nur das Entwicklungsteam darf Veränderungen am Sprint Backlog vornehmen.
• Entscheidungskompetenz darüber, „wie viel“, also Menge und Umfang im Rahmen des Sprint Plannings

Optimale Anzahl an Developers

Optimal sind zwischen drei und neun Developers. Bei weniger als drei besteht die Gefahr, dass eine Lücke bei den Fähigkeiten entsteht. Teams, die größer als neun Personen sind, haben einen sehr hohen Koordinationsaufwand. Bei diesen Berechnungen werden der Scrum Master und der Product Owner nicht einberechnet. Diese werden nur dann mitgezählt, wenn sie auch bei der Abarbeitung der Backlog Items mitwirken. Während des gesamten Prozesses sollten die Developers möglichst aus denselben Personen bestehen. Grund hierfür ist, dass sich im Rahmen des Prozesses so eine bessere Lernkurve darstellen lässt. Zudem kann das Gelernte im Rahmen der Interaktion der Teammitglieder besser fortgeführt werden.

Die Artefakte

Wie bereits erwähnt, gibt es hier drei Artefakte. Diese sind die folgenden: das Product Backlog, das Sprint Backlog und das Inkrement.

Das Product Backlog

Was ist das Ziel des Product Backlogs?

Das Product Backlog ist eine Auflistung aller Produktfeatures, die das Produkt, wenn es entwickelt ist, enthalten soll. Die Produktfeatures im Product Backlog werden Product Backlog Items genannt. Sie sind in einer bestimmten Reihenfolge nach Priorität geordnet. Es stellt die einzige Quelle aller Anforderungen an das Produkt und aller Änderungen, die am Produkt vorgenommen werden, dar. Das Product Backlog besteht, so lange das Produkt besteht. Es beinhaltet auch alle bereits abgearbeiteten Backlog Items bzw. Userstories.

Das Product Backlog ist nie vollständig, es lebt während des gesamten Entwicklungsprozesses und wird ständig überprüft und angepasst. Die erste Version des Product Backlogs zeigt die anfänglich nach besten Wissen und Gewissen bekannten Anforderungen. Das Product Backlog verändert sich im Zeitverlauf in dem Maße, wie sich der Einsatzbereich des Produkts und auch das Produkt selbst ändert. Das Product Backlog ist also sehr dynamisch. Es verändert sich ständig, um festzustellen, was das Produkt erfordert, um angemessen, wettbewerbsfähig und nützlich zu sein.

Wenn ein Produkt existiert, existiert auch ein Product Backlog. So ist die Welt von Scrum. Das Product Backlog beinhaltet also langfristig alle Features, Funktionen, Anforderungen, Verbesserungen, Änderungen, die in künftigen Versionen des Produkts enthalten beziehungsweise umgesetzt werden sollten. Jeder dieser Einträge im Product Backlog wird Product Backlog Item genannt. Jedes Product Backlog Item hat mehrere Attribute: Beschreibung, Priorisierung, Schätzung etc. Meist enthalten Product Backlog Items auch eine Beschreibung der Abnahmekriterien, die im Rahmen der Abnahme durch den Product Owner das „Done“ definieren.

Wer ist für das Product Backlog zuständig?

Für das Product Backlog ist der Product Owner zuständig. Er hat die Verantwortung, das Product Backlog zu erstellen und es während des gesamten Prozesses zu pflegen. Er ist insbesondere für seinen Inhalt, seine Struktur, die Priorisierung der Backlog Items und seine Verfügbarkeit zuständig.

Wie kommt das Product Backlog zur Anwendung?

Das Product Backlog kommt während des gesamten Prozesses zur Anwendung. Es stellt zu jeder Zeit die Basis bezüglich der Transparenz des zu entwickelnden Produktes dar. Das Product Backlog ist die Sammlung mehrerer Back­log Items, die letztlich in ihrer Gesamtheit alle Funktionen, die das zu entwickelnde Produkt umfasst. Im ersten Schritt ist ein Product Backlog Item nur die Bezeichnung einer Anforderung wie beispielsweise „Außen-Pool“.

Das Sprint Backlog

Was ist das Ziel des Sprint Backlogs?

Das Ziel des Sprint Backlogs ist, den Developers transparent zu machen, welche Backlog Items im Rahmen des Sprints wie umgesetzt werden sollen. Zudem gibt es zu jedem Zeitpunkt des Sprints Auskunft über den aktuellen Stand der Entwicklungsarbeit der Developers und darüber, welche Aufgaben noch zu erledigen sind, um das Sprint-Ziel zu erreichen. Um eine kontinuierliche Verbesserung sicherzustellen, enthält es auch mindestens eine Verbesserungsmaßnahme, die im Rahmen der letzten Sprint Retrospektive als wichtig beziehungsweise als von hoher Priorität identifiziert wurde. Das Sprint Backlog ist letztlich eine Teilmenge der Backlog Items aus dem Product Backlog. Die Auswahl dieser Backlog Items aus dem Product Backlog für das Sprint Backlog erfolgt im Rahmen des Sprint Plannings.

Wer ist für das Sprint Backlog zuständig?

Die Verantwortung für das Sprint Backlog liegt einzig bei den Entwicklerinnen und Entwicklern. Alle Anpassungen und Veränderungen am Sprint Backlog dürfen nur durch die Developers durchgeführt werden. Die Voraussetzung dafür, dass ein Backlog Item in das Sprint Backlog überführt wird, ist erstens, dass es ausreichend detailliert ist. So detailliert, dass die Developers alle Informationen transparent haben, die notwendig sind, um das Backlog Item im Rahmen des Sprints abzuarbeiten. Und zweitens muss das Backlog Item vom Entwicklungsteam für den anstehenden Sprint ausgewählt worden sein, so dass dieses das Item als umsetzbar bezüglich ihrer eigenen verfügbaren Kapazität während des Sprints einschätzt.

Wie kommt das Sprint Backlog zur Anwendung?

Das Sprint Backlog enthält einen Plan, wie das Inkrement geliefert und damit das Sprint-Ziel erreicht wird. Konkret enthält das Sprint Backlog eine Planung des Entwicklungsteams, welche Funktionalität das nächste Produktinkrement sein wird, und über die Entwicklungsarbeit, die erforderlich ist, um die Funktionalität in ein „Done“ zu überführen. Dieser Plan muss so detailliert sein, dass er auch im Daily genutzt und verwendet werden kann.

Das Inkrement

Das Inkrement ist das Produkt in seinem aktuellsten Auslieferungszustand inklusive allem, was im aktuellen Sprint umgesetzt wurde.

Was ist das Ziel des Inkrements?

Das Inkrement wird oft auch Produktinkrement genannt. Es umfasst alle Product Backlog Items, die im Rahmen der vergangenen Sprints umgesetzt wurden. Zudem umfasst es den Wert aller Inkremente, die in den vorherigen Sprints umgesetzt wurden. Das Inkrement ist quasi immer das aktuelle Produkt in seinem letzten Release-Zustand. Das Inkrement stellt einen wichtigen Bestandteil und Anteil zur Erreichung des Projektziels oder der Produktvision dar.

Wer ist für das Inkrement zuständig?

Die Developers sind für die Erstellung eines übergabefähigen Inkrements zum Ende jedes Sprints verantwortlich. Nach dessen Fertigstellung ist das Inkrement an den Product Owner zu übergeben. Der Product Owner ist dafür zuständig, die Entscheidung zu treffen, ob er das Inkrement releasen beziehungsweise in Betrieb nehmen möchte. Er kann das Produkt zwar abnehmen und dennoch entscheiden, dass er es nicht releasen möchte.

Wie kommt das Inkrement zur Anwendung?

Am Ende jedes Sprints übergeben die Developers ihre Arbeit in Form des auslieferfähigen Inkrements an den Product Owner. Wichtige Voraussetzung der Übergabe ist, dass das Inkrement auslieferfähig ist. Hierzu gehört, dass es einerseits der „Definition of Done“ des Teams entspricht und auch in einem potenziell auslieferbaren Zustand ist. Diese Überprüfung sollte bei einem gut eingespielten Team nicht erst bei Übergabe des Inkrements an den Product Owner erfolgen, sondern schon im Rahmen des Sprints durchgeführt werden. Das Inkrement muss releasefähig sein. Unabhängig davon, ob der Product Owner es für geeignet hält oder nicht.

Unsere Trainings!

Du suchst Trainings, Informationen und Medien – wie zum Beispiel ein Glossar oder relevante Templates – oder Du willst einfach nur wissen, was es mit dem beliebten Framework auf sich hat? Dann bist Du hier vollkommen richtig! Scrum ist in den letzten Jahren zur führenden Methodik für agiles Projektmanagement herangereift. Über 90 Millionen Menschen weltweit arbeiten inzwischen mit der Erfolgsmethodik. Informiere Dich jetzt oder starte noch heute mit einem Training – Du entscheidest. Informiere Dich jetzt oder starte noch heute mit Deinem Training!

Hier bei den Agile Heroes erhältst Du Zugriff auf ein Training, das absolut nach scrum.org konzipiert und in zwei Spezifikationen verfügbar ist: Professional Scrum Master (PSM I) & Product Owner (PSPO I). Wichtig: Beide Trainings sind sowohl als zweitägige Präsenz-Schulung sowie als Online-Kurse verfügbar. Lediglich die darauf aufbauende Professional Scrum Master (PSM II) Schulung wird derzeit ausschließlich als Präsenz-Workshop angeboten. Verändere Deine Arbeitsweise, betrachte Herausforderungen viel kreativer und entwickle Lösungsansätze, die nur im Rahmen einer Gruppendynamik realisierbar sind. Scrum ist bei uns als Training so ausgelegt, dass keinerlei Vorkenntnisse nötig sind. Einfach loslegen und durchstarten!

Rent your own Scrum Master!

Projekte und deren Erfolg sind stark abhängig von der Grundstruktur, der Interaktion zwischen den einzelnen Akteuren. Im Projektmanagement ist Agilität nicht nur Ausdruck von einem offenen, transparenten System, sondern Voraussetzung für gutes Gelingen. Du benötigst professionelle Unterstützung bei einem Projekt? Dann bist du hier genau richtig. Frage jetzt einen unserer Experten als externe Projekt-Unterstützung für deinen Projekt-Erfolg an. Unsere Berater sind zertifiziert, erfahren und stehen zum Teil schon morgen für dich, dein Team, dein Projekt oder dein Unternehmen bereit. Was wir Dir bieten? Eine erfahrene, durch unzählige Projekte geprägte Perspektive auf Dein Vorhaben. Jeder unserer Scrum Master ist zertifiziert und steht Dir einzeln oder im Team zur Verfügung, um Dein Entwicklungsteam bestmöglich zu betreuen.

Welche Vorteile bietet ein externer Scrum Master?

Ein agiles Projektmanagement auf Basis von SCRUM bietet die einmalige Chance, wertvolle Gruppendynamiken zu entfachen. Die Aufgabe des SCRUM Masters besteht darin, als eine Art „Servant Leader“ zu agieren und ein Verständnis dafür zu schaffen, Interaktion im Team zu optimieren. Mit unserer Hilfe baust Du effektiv Hindernisse ab, skalierst einzelne Aspekte und schaffst die Basis für schnelle, konsequente Erfolge.

Du willst mehr erfahren?

Du möchtest mehr erfahren? Sieh Dich einfach auf unserer Webseite um oder nehme direkt Kontakt zu uns auf, um die AGILE HEROES besser kennenzulernen. Wir beraten Dich zum bestmöglichen Einsatz eines externen Scrum Masters. Egal ob als Einzel-Projektmanager oder im Team, für uns ist keine Aufgabe zu komplex. Wirf einen Blick auf die Profile unserer agilen Spezialisten – wir freuen uns, Dich und Dein Unternehmen besser kennenzulernen!