Effektives Sprint Planning mit JIRA [JIRA und agiles Arbeiten, Teil 2]

Dies ist der zweite von insgesamt vier Teilen unserer Blogserie „JIRA und agiles Arbeiten“.

Zielgruppe sind auch dieses Mal agil arbeitende Teams, Scrum Master, Product Owner, agile Coaches und JIRA-Administratoren. Im Laufe der Serie werden vier unterschiedliche Begrifflichkeiten aus den agilen Methoden beleuchtet, und es wird anhand von anschaulichen Beispielen gezeigt, wie der gezielte Einsatz von JIRA helfen kann, effizienter miteinander zusammenzuarbeiten.

Sind wir im ersten Teil verstärkt darauf eingegangen, wie man durch regelmäßiges Backlog Grooming zu einem sauberen Backlog gelangt, beschäftigt sich dieser Blogpost mit dem nächsten Schritt, dem Sprint Planning.

Was ist ein Sprint Planning?

Ziel des Sprint Planning ist es, das Sprintziel für das Scrum-Team zu definieren. Hierzu nimmt sich das Team das priorisierte, geschätzte und aktuelle Product Backlog, die Team-Kapazität, sowie die in der Vergangenheit erreichte Team Velocity (wie ermittelt man die Team Velocity in JIRA?) als Eingangsgrößen, und ermittelt gemeinsam aus diesem Input das Sprintziel und die Backlog-Einträge, die zur Erreichung des Sprintzieles notwendig sind – das Sprint Backlog.

Im report mode des agile boards in JIRA lässt sich das Commitment und die Velocity der vergangenen Sprints einfach ermitteln.

Es gibt unterschiedliche Vorstellungen über die Dauer eines Sprint Planning. So gibt es Meinungen, die von einer Dauer von einer Stunde Sprint Planning pro Sprintwoche – also bei einem zweiwöchigen Sprint von zwei Stunden – ausgehen. Häufig trifft man auch auf die Variante, einen Tag (also acht Stunden) für das Sprint Planning einzuplanen. Die Empfehlung des aktuellen Scrum Guide liegt bei acht Stunden für einen einmonatigen Sprint, ergo bei vier Stunden für einen zwei Wochen dauernden Sprint. Grundsätzlich sollte man dem Team ausreichend Zeit einräumen, aber – wie bei allen anderen Dingen – den Fokus bzw. das Ziel nicht aus den Augen verlieren. Fest steht in jedem Fall, dass ein Sprint Planning timeboxed und nicht ausufernd sein sollte.

Weitestgehend Einigkeit herrscht über eine thematische Aufteilung in zwei Teile (Sprint Planning I und Sprint Planning II), die aber nicht zwingend formal voneinander getrennt werden müssen und an einem Tag bzw. direkt hintereinander stattfinden sollten. Im ersten Teil wird hierbei das „Was (wollen wir erreichen?)“ betrachtet, und im zweiten Teil das „Wie (erreichen wir dieses Ziel?)“ geklärt.

Herausforderungen beim Sprint Planning

Es gibt häufige Gründe, warum ein Sprint Planning nicht, wie gewünscht, effektiv verläuft. Zu den häufigsten Gründen zählen:

1. ein nicht aktuelles bzw. schlecht priorisiertes Backlog als Input
2. Das Sprint Planning ist zu lang, nicht time-boxed und uninteressant.
3. ein fehlendes gemeinsames Verständnis von „Definition of Done“ (entweder auf Ebene des Backlog Items oder auf Sprint Ebene)
4. Das Team versteht die Ausrichtung des Produkts nicht ausreichend.
5. Der Product Owner gibt die zu erledigenden Backlog Items (ohne Verhandlungsspielraum) vor.

Schaut man sich diese Gründe genauer an und sieht vom zuletzt genannten ab – dieser deutet auf eine Dysfunktion im Team bzw. Scrum-Prozess hin – kann der richtige Einsatz von JIRA Software ggf. in Verbindung mit Confluence die anderen Pain Points vermeiden oder zumindest signifikant mindern.

Hier kann JIRA Software das Sprint Planning unterstützen

Gerade in verteilten Teams stellt die Abstimmung untereinander im Rahmen des Scrum-Zyklus die einzelnen Teammitglieder immer wieder vor Herausforderungen. Man sollte daher stets im Blick haben, dass es in einem Sprint Planning in erster Linie um Kommunikation innerhalb des Teams geht. Ein Tool – auch nicht JIRA – kann und sollte diese Kommunikation niemals ersetzen, nur unterstützen.

Ein nicht aktuelles, bzw. schlecht priorisiertes Backlog als Input

Um zu vermeiden, dass innerhalb des Sprint Plannings der Fokus verloren geht, weil das Backlog nicht aktuell oder ausreichend priorisiert ist, müssen die Hausaufgaben vorab gemacht werden. Hausaufgaben im Sinne von gewissenhafter Pflege des Product Backlog („Backlog Grooming „). Da sich der erste Teil unserer Blogserie hiermit beschäftigt, gehen wir an dieser Stelle nicht noch einmal näher auf diesen Punkt ein, sondern beschränken uns auf die Feststellung, dass dies eine, wenn nicht die wichtigste Voraussetzung für ein effektives Sprint Planning darstellt.

Der zweite Grund – ein zu langer und zu wenig fokussierter Termin – ist in den meisten Fällen eine unmittelbare Folge aus dem ersten Punkt.

Ein fehlendes gemeinsames Verständnis von „Definition-of-Done“

Kriterien zu Definition-of-Done (DoD) können entweder auf Ebene eines Tasks, einer User Story oder auf Sprint-Ebene definiert sein. Wichtig ist in jedem Fall, dass sie definiert, vom Team verstanden und akzeptiert und irgendwo festgehalten sind. Anhand der DoD-Kriterien fragen wir uns: „Wann sind wir wirklich fertig?“

• Wenn alle Akzeptanzkriterien erfüllt sind?
• Wenn es ein Code-Review gab?
• Wenn alle Unit-Tests erfolgreich durchlaufen wurden?
• Wenn sich der Code im Staging-System befindet?
• Wenn sich der Code auf dem Live-System befindet (und keine kritischen Bugs vorhanden sind)?

Handelt es sich um DoD-Kriterien auf Sprint-Ebene, gibt es in JIRA Software zwei Möglichkeiten, diese transparent zu machen. Die eine Möglichkeit ist es, zu einem Sprint eine verlinkte Seite in Confluence zu erstellen  und dort das Sprintziel sowie die jeweiligen Kriterien festzuhalten.

Eines von vielen Beispielen, welche die gute Integration von JIRA und Confluence aufzeigen: Einem Sprint in JIRA Software kann eine korrespondierende Seite in Confluence zugeordnet werden.

Die andere Möglichkeit – derzeit noch ausschließlich für JIRA Cloud-Nutzer – ist das Feld „sprint goal “ bzw. „Sprintziel“. Je nach Umfang der Kriterien ist aber die erstgenannte Lösung die Bessere, da sie zwar einen Klick mehr benötigt, aber dafür deutlich mehr Platz – und ggf. die Nutzung von Seitenvorlagen in Confluence – bietet.

Sollen die Kriterien zu Definition-of-Done hingegen auf Ebene von User Stories oder auf Taskebene festgelegt werden, eignet sich hierzu entweder ein entsprechendes benutzerdefiniertes Feld „Definition of Done“ oder ein Template in dem JIRA Standard-Feld „Beschreibung“.

Das Vorbefüllen von Feldern in JIRA

In unseren Projekten begegnet uns sehr häufig die Anforderung, Vorgängen bereits beim Erstellen Standardwerte in Form von Templates mitzugeben, um dem User die Eingabe zu erleichtern. Dies ist z.B. sinnvoll bei Bugs („as is“, „to be“, „steps to reproduce“) oder eben bei User Stories („Akzeptanzkriterien“, „Persona“, „Definition of Done“).

Bietet JIRA den Administratoren bei benutzerdefinierten Feldern die relativ einfache Möglichkeit über den Kontext pro Vorgangstyp und Projekt Standardwerte beim Erstellen eines Vorgangs vorzugeben, gibt es diese Möglichkeit bei Systemfeldern wie z.B. der „Zusammenfassung“ oder der „Beschreibung“ leider nicht.

Über den jeweiligen Kontext, welcher pro Projekt und pro Vorgangstype definiert werden kann, kann einem benutzerdefiniertem Feld ein Standardwert zugewiesen werden…

… der dann automatisch in der „Vorgang Erstellen“-Maske als Template vorbefüllt wird. Mit Systemfeldern funktioniert dies leider nicht.

Eines der von JIRA-Nutzern am meisten gewünschten Features – mit mehr als 1000 Stimmen (siehe JRA-4812 ) – ist die Möglichkeit zur Vergabe von Standardwerten bei Systemfeldern. Dadurch haben sich in den vergangenen Jahren verschiedenste Lösungen am Markt etabliert, diese Limitierung in der Kernfunktionalität zu umgehen.

Eine Möglichkeit – zumindest für JIRA-Administratoren – ist das Vorbefüllen der Felder mittels Javascript/jQuery (z.B. über den Wartungsbanner) oder die serverseitige Anpassung der Templates , welche in diversen Foren (z.B. hier und hier ) immer wieder diskutiert wird. All diese Lösungen haben mehrere Dinge gemeinsam: Sie sind ein Hack, werden nach und nach abgeschafft  und haben zudem den Nachteil, dass sie – sollten sie nach einem JIRA-Update noch möglich sein – erneut auf die Instanz ausgerollt werden müssen.

Eine andere, elegantere Lösung stellt das unterstützte, update-konforme, Addon „Workflow Essentials for JIRA “ dar: Hier kann man bequem über die grafische Benutzeroberfläche im Administrations-Menü pro Projekt und Vorgangstp festlegen, welches Feld beim Erstellen eines Vorgangs welche vorbefüllten Werte bekommen soll.

Über die Konfiguration des „Workflow Essentials for JIRA“ Addons im Admin-Bereich von JIRA können sowohl benutzerdefinierte als auch Systemfelder vorbefüllt werden.

In diesem Beispiel werden die Definition-of-Done-Kriterien als Checkliste in die Beschreibung aufgenommen.

Das Team versteht die Ausrichtung des Produkts nicht ausreichend

Eine wichtige Aufgabe des Product Owners ist es, dem Entwicklungsteam seine Vision von und seine Ideen zum Produkt zu vermitteln. Erfahrungsgemäß gehört Kommunikation teilweise mit zu den schwierigeren Dingen im Leben. Ein priorisiertes Backlog ist der erste Weg, Ordnung in die Vielzahl von Produktideen des Product Owners zu bringen. Es ändert aber nichts daran, dass ein Backlog immer noch zweidimensional ist, also – trotz Epics – immer nur eine Momentaufnahme ohne die zeitliche Komponente ist.

Daher hat sich seit einigen Jahren eine Alternative zum Arbeiten mit flachem Backlogs etabliert: das User Story Mapping. Hierbei wird der Nutzer auf seiner Reise durch das Produkt in den Mittelpunkt gestellt („customer journey“). In diesem kurzen Blogpost ist anhand vom Aussuchen, Kaufen, Ansehen und Bewerten eines Filmes auf Apple TV sehr plastisch erklärt, wie das Prinzip des User Story Mappings funktioniert.

Im Gegensatz zum flachen Backlog bietet User Story Mapping die Möglichkeit, das Nutzererlebnis über die einzelnen Stationen einer Nutzerrolle abzubilden.

Durch diesen Ansatz ist sichergestellt, dass jedes auslieferbare Produktinkrement jeweils einen möglichst hohen Wert für den Nutzer hat. Mit diesem Ansatz im Auge wurde das Addon „Easy Agile User Story Maps for JIRA “ entwickelt, welches es Teams ermöglicht, User Story Mapping in JIRA zu betreiben.

Hierbei wird im Agile Board von JIRA Software ein weiterer Navigationspunkt „User story map“ angelegt. Klickt man diesen an, bekommt man eine Ansicht, die, ähnlich der obigen Ansicht, die Reise des Kunden bei seiner Produktnutzung abbildet. Dabei stellt jeder einzelne Oberpunkt ein Epic dar, der in User Stories heruntergebrochen wird.

In der Ansicht „User story map“ finden sich relevante Epics nach zeitlicher Sortierung in User Stories herunter gebrochen.

Dies sollte es insbesondere verteilten Teams bei komplexeren Produkten und größeren Backlogs einfacher machen, den Userflow zu verstehen und ein gemeinsames Bild von der Idee des Product Owners zu festigen, weil das Team aufgrund der Transparenz darauf vertrauen kann, an den jeweils wertvollsten Dingen zu arbeiten.

Fazit

Beim Sprint Planning sind Priorisierung, Transparenz, ein gemeinsames Verständnis (Definition-of-Done, Nutzerwert) sowie Kommunikation kritische Faktoren, von denen es abhängen kann, ob ein Sprint erfolgreich abgeschlossen werden kann. Bei all diesen Punkten kann JIRA Software gerade verteilten Teams entscheidende Vorteile bringen.

Wie sind eure Erfahrungen? Wo hakte es in der Vergangenheit beim Sprint Planning? Was waren die Gründe hierfür? Setzt ihr JIRA in der Softwareentwicklung ein und habt Fragen bzw. benötigt Tipps? Nutzt gerne die Kommentarfunktion oder schreibt direkt an kai.gottschalk@codecentric.de .

Weiter geht es übrigens im nächsten Teil mit dem Sprint Review, in welchem das Team präsentieren darf, was es in dem zurückliegenden Sprint fertiggestellt hat.