Scrum-Tutorial
In diesem Tutorial erfährst du Schritt für Schritt, wie du in Jira ein Scrum-Projekt umsetzt, dein Backlog priorisierst und in Sprints aufteilst, Scrum-Zeremonien durchführst und vieles mehr.
Zeit:
Lesedauer: 10 Minuten Dauer der Umsetzung: 2 Wochen
Zielpublikum:
Einsteiger in Scrum, der agilen Entwicklung oder in Jira
Voraussetzungen:
Du hast ein Jira-Konto erstellt
Scrum ist eins der beliebtesten Frameworks für die Implementierung agiler Methoden. Mit Scrum wird ein Produkt in einer Reihe von Iterationen mit fester Länge entwickelt, die als Sprints bezeichnet werden und die agilen Teams für die Auslieferung von Software ein Framework mit regelmäßigem Rhythmus bieten.
Schritt 1: Erstellen eines Scrum-Projekts
Nachdem du ein Jira-Konto erstellt und dich darin eingeloggt hast, kannst du eine Vorlage aus der Bibliothek auswählen. Wähle "Scrum" aus (hier kannst du die kostenlose Scrum-Vorlage als Vorschau öffnen oder lernen, wie man ein Kanban-Projekt erstellt).
Als Nächstes wirst du dazu aufgefordert, einen Projekttyp auszuwählen. Wenn dein Team eigenständig arbeitet und die Kontrolle über die eigenen Arbeitsprozesse und Praktiken in einem in sich geschlossenen Bereich haben möchte, solltest du die vom Team verwaltete Scrum-Vorlage ausprobieren. Weitere Informationen dazu findest du in der Atlassian Community unter Getting started with team-managed projects (Erste Schritte mit vom Team verwalteten Projekten).
Sobald du dein Projekt erstellt hast, wird das leere Backlog angezeigt. Das Backlog wird auch Produkt-Backlog genannt und enthält eine Liste der potenziellen Projekt-Aufgabenelemente deines Teams.
Schritt 2: Erstellen von User Storys oder Aufgaben im Backlog
In Jira bezeichnen wir Aufgabenelemente wie User Storys, Tasks und Bugs als Vorgänge. Erstelle mit der Option zum schnellen Erstellen im Backlog ein paar User Storys. Wenn du gerade keine User Story griffbereit hast, kannst du auch ein paar beispielhafte Storys erstellen, um loszulegen und den Ablauf kennenzulernen.
Mithilfe von User Storys werden Aufgabenelemente ohne Fachsprache aus der Perspektive des Benutzers beschrieben. Als {Benutzertyp}, möchte ich {Ziel}, damit ich {gewünschter Vorteil}.
Verwenden wir eine Website als einfaches Beispiel für die Erstellung einer User Story.
Als Kunde möchte ich ein Konto erstellen können, damit ich meine Käufe des letzten Jahres sehen kann.
User Storys werden in der Regel vom Produktinhaber grob skizziert und priorisiert. Die ausführlicheren Tasks, die zum Abschluss der Story in einem nächsten Sprint erforderlich sind, werden dann vom Entwicklerteam bestimmt. Dieses Team muss auch den relativen Aufwand zum Abschließen der Arbeit an der User Story schätzen.
Sobald du ein paar User Storys erstellt hast, kannst du mit der Priorisierung der Storys im Backlog beginnen. In Jira ordnest oder priorisierst du Storys per Drag-and-Drop und bringst sie so in die Reihenfolge, in der dein Team sie bearbeiten soll.
Das sind nur die ersten Storys deines Projekts. Solange die Arbeit an dem Projekt fortgesetzt wird, wirst du weitere Storys erstellen – denn Agilität umfasst kontinuierliches Lernen und Anpassen.
Schritt 3: Erstellen eines Sprints
Erstelle deinen ersten Sprint im Backlog, damit du mit dem Planen des Sprints beginnen kannst.
In Scrum prognostizieren Teams, einen Satz von User Storys oder andere Aufgabenelemente innerhalb eines festen Zeitraums abzuschließen, der als Sprint bezeichnet wird. Im Allgemeinen sind Sprints ein, zwei oder vier Wochen lang. Die Länge eines Sprints wird vom Team festgelegt – wir empfehlen, mit zwei Wochen zu beginnen. Das ist lange genug, um etwas zu erreichen, aber auch so überschaubar, dass das Team regelmäßiges Feedback erhalten kann. Nachdem ein Sprint-Rhythmus festgelegt ist, hält das Team diesen Rhythmus beständig ein. Sprints mit fester Länge ermöglichen eine bessere Schätzungskompetenz und Prognose der zukünftigen Velocity des Teams beim Durcharbeiten des Backlogs.
Schritt 4: Abhalten des Sprint-Planungsmeetings
Zu Beginn eines Sprints solltest du mit deinem Team ein Sprint-Planungsmeeting abhalten. Dieses Meeting ist eine Zeremonie, in der sich das gesamte Team auf erfolgreiches Arbeiten während des Sprints ausrichtet. In einem Sprint-Planungsmeeting bespricht das ganze Team das Sprint-Ziel und die Storys im priorisierten Produkt-Backlog. Das Entwicklerteam erstellt zunächst detaillierte Tasks sowie Schätzungen für die Storys mit höchster Priorität und legt dann fest, wie viele Storys im Sprint abzuschließen sind. Diese Storys und der Plan zum Abschluss der entsprechenden Aufgaben ergeben letztlich den Sprint-Backlog.
Füge deinen Storys Schätzungen zu Story Points hinzu, indem du im Feld Story Point-Schätzung eine Zahl eingibst. Du kannst außerdem Details zu den Storys ergänzen oder die Arbeit an der Story durch Klicken auf das Symbol zum Erstellen einer Sub-Task weiter unterteilen.
Wenn du fertig bist, ziehe die Storys, die ihr im Sprint-Planungsmeeting abgesprochen habe, in den gerade erstellten Sprint. Das ist dein Sprint-Backlog.
Teilnehmer: Erforderlich: Entwicklerteam, Scrum Master, Produktinhaber
Wann: Zu Beginn eines Sprints
Dauer: In der Regel zwei Stunden je Woche der Iteration, d. h. ein zweiwöchiger Sprint wird beispielsweise mit einem vierstündigen Planungsmeeting begonnen. Das Meeting endet, wenn sein Zweck erfüllt wurde.
Zweck: Die Arbeit des Sprints planen. Das Team legt ein Sprint-Ziel und den Sprint-Backlog fest.
Beim Erstellen eines Sprints legt der Produktinhaber für gewöhnlich ein Sprint-Ziel fest. Dadurch wird den zu erledigenden Aufgaben des Sprints ein Theme gegeben. Die Anzahl der Storys, die in einem Sprint abzuschließen sind, kann für jedes Sprint-Ziel flexibel bestimmt werden. Ein Sprint war erfolgreich, wenn das Sprint-Ziel erreicht wurde.
Herkömmliche Softwareteams erstellen Schätzungen in einem zeitbasierten Format, also in Tagen, Wochen und Monaten.
Viele agile Teams sind jedoch zu Story Points übergegangen. Mithilfe von Story Points wird der relative Aufwand einer Aufgabe in einem fibonacciartigen Format bewertet: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Schätzungen helfen dir bei der Beurteilung, wie viele Aufgaben du dem nächsten Sprint je nach Anzahl deiner Teammitglieder hinzufügen solltest. Nach den ersten paar Sprints wird dein Team besser beurteilen können, wie viele Aufgaben in einem Sprint erledigt werden können, sodass es sich nicht zu viel vornimmt.
Schritt 5: Starten des Sprints in Jira
Gib dem Sprint einen Namen. Einige Teams benennen den Sprint nach ihren Zielen. Wenn zwischen den Vorgängen im Sprint Gemeinsamkeiten bestehen, solltest du den Sprint entsprechend diesem Theme benennen. Andernfalls kannst du einen beliebigen Namen für den Sprint wählen.
Füge die Dauer des Sprints und ein Start- sowie Enddatum hinzu. Das Start- und Enddatum sollte zum Teamzeitplan passen. Manche Teams beginnen einen Sprint z. B. an einem Montag und beenden ihn in der darauffolgenden Woche freitagmorgens. Andere Teams beginnen und beenden ihre Sprints in der Mitte der Woche. Das ist ganz dir überlassen! Wenn du dir unsicher über die Länge deiner Sprints bist, empfehlen wir dir, mit einer Dauer von zwei Wochen zu beginnen.
Füge das Sprint-Ziel hinzu, wie ihr es im Sprint-Planungsmeeting besprochen habt.
Sobald du deinen Sprint begonnen hast, wird im Projekt die Registerkarte "Aktive Sprints" angezeigt.
Hier wählt das Team Elemente aus der Spalte "Zu erledigen" und zieht sie in die Spalte "In Bearbeitung" und schließlich in "Erledigt".
Wenn du die vom Team verwaltete Scrum-Vorlage verwendest, spricht man von einem Board.
Schritt 6: Abhalten der täglichen Standup-Meetings
Versammle dein Team nach Beginn deines Sprints jeden Tag, normalerweise morgens, um durchzugehen, woran die einzelnen Teammitglieder gerade arbeiten. So erkennst du rechtzeitig, ob ein Teammitglied auf Schwierigkeiten stößt, die die Fertigstellung des Sprints gefährden.
Teilnehmer (primär): Entwicklerteam
Wann: Einmal täglich, normalerweise am Morgen
Duration: No more than 15 minutes. Don't book a conference room and conduct the standup sitting down. Standing up helps keep the meeting short!
Zweck: Das tägliche Stand-up-Meeting ist dafür vorgesehen, alle Beteiligten schnell darüber zu informieren, was im gesamten Team abläuft, und den Arbeitstag zu planen. Es handelt sich nicht um ein ausführliches Statusmeeting. Der Ton sollte locker und ungezwungen, aber dennoch informativ sein. Jedes Teammitglied sollte die folgenden Fragen beantworten:
- Was habe ich gestern erledigt?
- Woran werde ich heute arbeiten?
- Bin ich durch irgendetwas blockiert?
Es besteht die stillschweigende Übereinkunft, dass du vor deinen Kollegen berichtest, welche Arbeiten du gestern erledigt hast. Niemand möchte das Teammitglied sein, das ständig an derselben Sache arbeitet und keinen Fortschritt macht.
Profitipp: Einige Teams nutzen Timer, um alle auf Kurs zu halten. Andere werfen einen Ball im Team hin und her, um sicherzustellen, dass alle aufmerksam sind. Viele verteilte Teams nutzen Videokonferenzen oder Gruppenchats, um die Distanz zu überbrücken. Dein Team ist einzigartig – dein Standup-Meeting sollte dies ebenfalls sein!
Du kannst die aktiven Sprints deines Scrum Boards während der täglichen Standups verwenden, damit alle Teammitglieder die Aufgaben sehen können, an denen gerade gearbeitet wird.
Schritt 7: Anzeige des Burndown-Charts
Es ist eine gute Idee, während eines Sprints ab und zu einen Blick in das Burndown-Chart zu werfen. In Jira zeigen Burndown-Charts das Verhältnis zwischen dem geschätzten und dem tatsächlichen Arbeitsumfang in einem Sprint. Das Burndown-Chart wird beim Abschließen von Aufgabenelementen automatisch von Jira aktualisiert. Klicke zur Anzeige des Charts in der Seitenleiste auf "Berichte" und wähle im Drop-down-Menü das Burndown-Chart aus.
Burndown-Charts zeigen das Verhältnis zwischen dem geschätzten und dem tatsächlichen Arbeitsumfang in einem Sprint. Die waagrechte X-Achse in einem Burndown-Chart gibt die Zeit wieder und die senkrechte Y-Achse üblicherweise die Story Points.
Nutze das Burndown-Chart, um alle im Sprint ausstehenden Aufgaben zu verfolgen und einzuschätzen, wie wahrscheinlich das Erreichen des Sprintziels ist. Durch das Verfolgen der ausstehenden Aufgaben während der Iteration kann ein Team seinen Fortschritt verwalten und entsprechend reagieren.
- Das Team erledigt nahezu alle Sprints vorzeitig, da es nicht genug Aufgaben übernommen hat.
- Das Team hält die Prognose über mehrere Sprints nicht ein, da es zu viele Aufgaben auf sich genommen hat.
- Die Burndown-Linie sinkt an einigen Stellen stark ab statt graduell, weil die Aufgaben nicht granular aufgeteilt wurden.
- Der Product Owner erweitert oder ändert den Umfang mitten im Sprint.
Schritt 8: Anzeige des Sprint-Berichts
Du kannst den Sprint anhand des Sprint-Berichts überwachen, der jederzeit während oder nach dem Sprint abrufbar ist.
Der Sprint-Bericht umfasst das Burndown-Chart und listet die fertiggestellten, nicht fertiggestellten und nach Sprint-Beginn hinzugefügten Aufgaben auf.
Schritt 9: Abhalten des Sprint-Review-Meetings
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
In diesem Meeting wird eine Menge Feedback zum Projekt gegeben und per Brainstorming entschieden, wie die nächsten Schritte aussehen sollen.
Teilnehmer (primär): Entwicklerteam, Scrum Master, Produktinhaber
Optional: Stakeholder
Wann: Üblicherweise am letzten Tag des Sprints.
Dauer: In der Regel zwei Stunden für einen zweiwöchigen Sprint.
Zweck: Zwischenergebnisse besprechen und gemeinsam das Produkt-Backlog aktualisieren.
Diese Fragen solltest du dir stellen:
- Hat das Team die Sprintprognose eingehalten?
- Wurden während des Sprints Aufgaben hinzugefügt oder entfernt?
- Blieben Aufgaben des Sprints unerledigt?
- Wenn ja, warum?
Schritt 10: Abhalten des Sprintretrospektivmeetings
Führe nach Abschluss des Sprints mit deinem Team eine Retrospektive durch. Dokumentiere diese Retrospektive irgendwo. Wie wäre es mit Confluence?
Teilnehmer: Entwicklerteam, Scrum Master, Produktinhaber
Wann: Am Ende einer Iteration
Dauer: Üblicherweise 90 Minuten bei einem zweiwöchigen Sprint.
Zweck: Das Team nimmt sich selbst unter die Lupe, einschließlich seiner Prozesse, Tools und Teaminteraktionen. Häufig werden Vorgänge zur Verbesserung zum Backlog des nächsten Sprints hinzugefügt.
Retrospektiven sind nicht die Zeit für Beschwerden, die keine Aktion nach sich ziehen. Nutze Retrospektiven, um herauszufinden, was funktioniert, damit das Team sich weiterhin auf diese Bereiche konzentrieren kann. Finde außerdem heraus, was nicht funktioniert, und nutze die Zeit, um kreative Lösungen zu finden und einen Aktionsplan zu entwickeln. Eine kontinuierliche Verbesserung unterstützt und fördert die Entwicklung in einem agilen Team und Retrospektiven leisten einen wichtigen Beitrag dazu.
Diese Fragen solltest du dir stellen:
- Was ist im Sprint gut gelaufen?
- Was hätten wir besser machen können?
- Was werden wir nächstes Mal besser machen?
Profitipp: Auch wenn die Dinge im Team gut laufen, sollten Retrospektiven fortgesetzt werden. Retrospektiven sind eine fortlaufende Orientierungshilfe für das Team, damit die Dinge weiterhin gut laufen.
Schritt 11: Abschluss des Sprints in Jira
Am Ende des Sprints muss dieser abgeschlossen werden.
Wenn es im Sprint noch offene Vorgänge gibt, kannst du:
- die Vorgänge in das Backlog verschieben
- die Vorgänge auf einen späteren Sprint verschieben
- die Vorgänge auf einen neuen Sprint verschieben, den Jira für dich erstellt
Schritt 12: Wiederholung von Schritt 2
Nun verfügst du über die Grundlagen zur Erstellung deines Backlogs mit User Storys, zur Einordnung deiner User Storys in Sprints, für den Beginn deines Sprints und zum Abhalten von Scrum-Zeremonien. Mit diesen Kenntnissen kannst du entscheiden, ob all dies für dein Team funktioniert oder ob du in ein paar Themen noch tiefer eintauchen möchtest.
Nachdem du und dein Team die obigen Schritte abgeschlossen haben, kannst du dir die Schritte in diesem weiterführenden Artikel vornehmen: Scrum-Verfahren mit Jira für Fortgeschrittene.
