Scrum-Glossar von A bis Z
Scrum – das ist agiles Projektmanagement, das ursprünglich für die Softwareentwicklung geschaffen wurde, aber auch für Ingenieure immer interessanter wird. Es bedient sich einer eigenen Sprache. Ingenieur.de erklärt die wichtigsten Begriffe im Scrum-Glossar.
Quelle: panthermedia.net/timbrk
Hier geht es zur Methode Scrum
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
B wie Backlog
Das Product Backlog listet die Produktanforderungen auf und ordnet sie. Es ist dynamisch und wird kontinuierlich weiterentwickelt. Alle Arbeiten des Entwicklungsteams basieren auf dem Product Backlog. Der Product Owner verantwortet die Pflege des Product Backlogs, vor allem die Reihenfolge beziehungsweise Priorisierung der Einträge. Das Backlog ist weder vollständig noch erhebt es einen Anspruch auf Vollständigkeit. Zu Projektbeginn umfasst es die bekannten und am besten verstandenen Anforderungen. Alle Eintragungen werden nach den Gesichtspunkten wirtschaftlicher Nutzen, Risiken und Notwendigkeit priorisiert. Die am Höchsten priorisierten Eintragungen setzt das Entwicklungsteam im Sprint als erstes um. Das Risiko einer Anforderung wird durch die Analyse ihrer Abhängigkeiten zu anderen Anforderungen bestimmt.
D wie Definition of Done
Die Definition of Done (DoD) bezeichnet das gemeinsame Verständnis des Scrum Teams zu den Bedingungen, unter denen die Arbeit als fertig bezeichnet werden kann. Die DoD umfasst Qualitätskriterien, aber auch Einschränkungen und nicht-funktionale Anforderungen. Je erfahrener das Scrum-Team ist, desto weiter schreitet auch die Definition of Done voran. Sie erfüllt dann strengere Kriterien und garantiert eine höhere Qualität.
Zur Definition of Done gehören dann auch Kommentare, Unit Tests und Design-Dokumente. Das Scrum-Team legt die „Definition of Done” zu Projektbeginn fest und passt sie im Projektverlauf kontinuierlich an. Zu Beginn eines Sprints hilft sie dabei, Zahl und Umfang der Aufgaben festzulegen. Am Ende jedes Sprints entscheidet das Scrum-Team auf Basis von DoD und den Akzeptanzkriterien jedes Product-Backlog-Eintrags, ob der Eintrag als fertig akzeptiert wird. Das Team übernimmt hier die Verantwortung für die Einhaltung der DoD-Kriterien.
D wie Daily Scrum
Das Daily Scrum ist ein maximal 15-minütiges Treffen des Entwicklerteams zu Beginn des Arbeitstages. Scrum Master und Product Owner sind hier oft ebenfalls anwesend. Sie sind aber nicht aktiv beteiligt, es sei denn sie bearbeiten Backlogelemente. Beim Daily Scrum werden relevante Informationen ausgetaucht. Es dient nicht dazu, Probleme zu lösen. Vielmehr geht es vor allem für das Entwicklerteam darum, sich einen Überblick zum aktuellen Projektstand zu verschaffen. Jedes Teammitglied kann hierbei mithilfe eines Taskboards demonstrieren, was es seit dem letzten Daily Scrum erreicht hat. Zudem wird jedes Teammitglied darstellen, was es bis zum nächsten Daily Scrum erreichen will und mögliche Hindernisse verdeutlichen.
Stellt sich beim Daily Scrum heraus, dass eine Aufgabe länger als geplant dauert, so wird dieser Task in kleinere Aufgaben aufgeteilt. Diese können dann von anderen Mitgliedern des Entwicklungsteams übernommen werden. Falls beim Daily Scrum Fragen aufkommen, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so gibt es 2 Wege:
- Die Fragen werden entweder notiert und dem Scrum Master übergeben.
- Die Beantwortung wird auf ein späteres Meeting verschoben. Das findet dann oft direkt im Anschluss statt.
E wie Entwicklungsteam
Das Entwicklungsteam entwickelt und liefert die Produktfunktionalitäten in der Reihenfolge, die der Product Owner vorgibt. Er verantwortet die Einhaltung der vereinbarten Qualitätsstandards. Das Entwicklungsteam organisiert sich selbst, wird also nicht vom Product Owner geleitet oder geführt. Auch der Scrum Master darf dem Entwicklungsteam nicht vorschreiben, wie es die einzelnen Backlogs umsetzt.
Das Entwicklungsteam sollte die Ziele der einzelnen Sprints möglichst ohne externe Hilfe erreichen. Aus diesem Grund ist es interdisziplinär besetzt, z. B. mit je einem Ingenieur, Entwickler, Tester, Dokumentationsexperten und Datenbankexperten. Sowohl gute als auch schlechte (Sprint-)Ergebnisse werden immer auf das Entwicklungsteam als ganzes zurückgeführt – nie auf einzelne Teammitglieder. Das ideale Teammitglied ist Spezialist und Generalist zugleich. So kann es die eigenen Bereiche vorantreiben und Teamkollegen beim Erreichen der gemeinsamen Ziele unterstützen.
Ein Scrum-Entwicklungsteam setzt sich aus mindestens 3 und höchstens 9 Mitgliedern zusammen. Idealerweise ist es gerade groß genug, um alle benötigten Kompetenzen zu vereinigen. Denn je größer das Team, desto besser muss sich das Team organisieren. Und das bedeutet mehr Koordinierungsaufwand.
I wie Inkrement
Das Inkrement ist in Scrum definiert als die Summe aller Product-Backlog-Einträge, die in allen bisherigen Sprints fertiggestellt wurden, sprich alle Produktfunktionen, die bis dato fertig sind. Ist ein Sprint beendet, so muss das neue Inkrement in einem nutzbaren Zustand sein und der „Definition of Done“ (DoD) entsprechen.
M wie Master
Der Scrum Master achtet darauf, dass Scrum als Rahmen- und Regelwerk konsequent umgesetzt wird. Er gehört nicht zum Entwicklungsteam, arbeitet aber mit diesem zusammen. Der Scrum Master führt die Scrum-Regeln ein und kontrolliert die Einhaltung der Regeln. Zudem sorgt er dafür, dass Störungen und Hindernisse behoben beziehungsweise beseitig werden. Dies sind zum Beispiel mangelhafte Kommunikation und schlechte Zusammenarbeit oder Konflikte im Entwicklungsteam. Hierzu gehört auch eine gestörte Zusammenarbeit mit dem Product Owner. Der Scrum Master schirmt das Team auch vor Störungen von außen ab, wenn zum Beispiel eine Fachabteilung will, dass weitere Aufgaben außerhalb des Sprints erledigt werden.
Der Scrum Master dient dem Entwicklungsteam als Führungskraft. Das bedeutet, dass er den Teammitgliedern nicht weisungsbefugt ist. Er erteilt ihnen also keine Arbeitsanweisungen. Er beurteilt sie auch nicht oder agiert disziplinarisch im Sinne einer Führungskraft. Der Scrum Master agiert vielmehr als Prozess-Coach, der Hemmnisse jeglicher Art aus dem Weg räumt. Dennoch führt er das oder die Team(s) situativ.
P wie Product Owner:
Der Product Owner verantwortet die Eigenschaften und den wirtschaftlichen Erfolg des Produkts, wobei er versucht, den Nutzen des Produkts zu maximieren. Der Nutzen orientiert sich zum Beispiel am Unternehmensumsatz. Der Product Owner erstellt, priorisiert und erläutert die Produkteigenschaften, die das Team entwickeln soll. Er beurteilt, welche Eigenschaften am Ende eines Sprints fertig entwickelt wurden.
Er ist immer eine Person und kein Komitee oder Unternehmen. Im sogenannten Product Backlog legt der Product Owner die Produkteigenschaften fest. In Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern definiert er die Produktanforderungen. Im Verlauf des Projekts ordnet und aktualisiert er das Product Backlog regelmäßig.
Da er für das Projekt verantwortlich ist, spricht er sich regelmäßig mit den Stakeholdern ab. So versteht er deren Bedürfnisse und Wünsche. Schließlich muss er die Interessen und Anforderungen der unterschiedlichen Stakeholder abwägen und in die weitere Produktentwicklung einbeziehen.
S wie Scrum
Der Begriff „scrum“ kommt aus dem Englischen und bedeutet übersetzt so viel wie „das Gedränge“. Es ist ein Vorgehensmodell des agiles Projekt- und Produktmanagements, besonders für die Softwareentwicklung. Scrum wird inzwischen auch in vielen anderen Bereichen eingesetzt. Es ist eine Umsetzung des sogenannten Lean Developments, also der schlanken Entwicklung, im Bereich des Projektmanagements.
S wie Sprint
Ein Sprint bezeichnet in Scrum einen Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Der Sprint beginnt mit der Sprint-Planung, dem sogenannten Sprint Planning, und endet mit Sprint Review und Sprint Retrospektive. Auf jeden Sprint folgt der nächste Sprint. Während eines Sprints sind ausschließlich Änderungen erlaubt, die das Sprintziel nicht beeinflussen. Ein Sprint dauert zwischen 1 und 4 Wochen. Um dem Projekt einen homogenen Takt zu geben, sollten alle Sprints möglichst gleich lang sein. Ein Sprint wird niemals verlängert, egal ob das Ziel erreicht wurde. Ist die Zeit abgelaufen, so ist der Sprint immer zu Ende. Falls das Sprintziel nicht mehr zu erreichen ist, kann der Product Owner den Sprint abbrechen. Dieser Fall kann eintreten, wenn das Entwicklungsteam den Aufwand falsch eingeschätzt hat oder der Product Owner das Produktinkrement so nicht mehr will.
Das Sprint Review findet wie beschrieben am Sprintende statt. Das Scrum Team überprüft hier das Inkrement und passt das Product Backlog bei Bedarf an. Das Entwicklungsteam präsentiert seine Ergebnisse und kontrolliert, ob das zu Beginn gesteckte Ziel erreicht wurde. Scrum Team und Stakeholder besprechen die Ergebnisse und stimmen ab, was als Nächstes zu tun ist.
S wie Stakeholder
Als Stakeholder werden Akteure außerhalb von Scrum bezeichnet. Diese sind:
- Kunden: Der oder die Kunden bekommen das Produkt nach Fertigstellung. Kunden können interne Fachabteilungen aber auch externe Personen oder Gruppen sein. Der Product Owner soll seine Kunden begeistern, indem er ihnen das Wunschprodukt liefert. Kunden und Product Owner stehen deswegen während des Projektes im engen Austausch. Kunden und Product Owner sollten sich zudem zur Wunschvorstellung des späteren Produkts einig sein. Schon nach den ersten Sprints können sich die Kunden neue Funktionalitäten ansehen und Feedback geben.
- Anwender: Die Anwender sind die Personen, die das Produkt später nutzen werden. Sie können, müssen aber nicht deckungsgleich mit dem Kunden sein. Die Anwender sind für das Scrum Team besonders wichtig. Denn nur sie können das Produkt aus der Nutzerperspektive beurteilen.
- Management: Das Management sorgt dafür, dass die Rahmenbedingungen stimmen. Es stellt Räume und Arbeitsmittel zu Verfügung und unterstützt den eingeschlagenen Kurs des Scrum Teams. Zudem schützt das Management das Scrum Team vor externen Arbeitsanforderungen. Außerdem hilft es dabei, das Team adäquat zu besetzen. Und es unterstützt den Scrum Master dabei, Hindernisse aus dem Weg zu räumen.
T wie Timeboxing
Alle Scrum-Ereignisse spielen sich innerhalb fester Zeitfenster ab. Diese Timeboxes sollen nicht überschritten werden. Timeboxing bezeichnet grundsätzlich eine bestimmte Technik der Projektplanung. Eine Timebox ist immer ein fester Zeitrahmen für das Projekt oder einen Vorgang innerhalb des Projekts. Bei einem Gesamtprojekt spricht man von Timeboxing, wenn der Endtermin des Projekts vorgegeben ist. Vorgangsziele, Inhalt und Ressourcen orientieren sich an der Zeit. Oft ist auch die Rede von Timeboxing, wenn Inhalt und Umfang (scope) des Projekts reduziert werden, um noch zeitgerecht fertig zu werden. Funktionalitäten, die noch fehlen, werden dann oft erst in Folgeprojekten umgesetzt.
Methoden und Kulturen des Projektmanagements:
Ein Beitrag von:
