Alexander Lemm am 23. November 2016 Wie Software AG Scrum mithilfe von Planio implementiert
Wir setzen seit 2010 eine maßgeschneiderte Planio Enterprise Instanz ein. Zuerst wurde diese von unserer Consulting-Abteilung genutzt, um mit unseren eigenen Kunden im Rahmen von Projekten zusammenzuarbeiten. Bald darauf wurde sie von anderen Abteilungen wie dem Vertrieb und F&E entdeckt und diese fingen an, die Plattform auch für eigene interne Projekte zu nutzen. Aktuell hat unsere Planio Instanz ca. 2.800 aktive Benutzer und 3.000 aktive Projekte.
Planio bietet mit Planio Agile hervorragende Unterstützung für das agile Projektmanagement wie bspw. das Sprint Planning Board, das Taskboard und verschiedene agile Charts.
In diesem Artikel werden wir einige der Best Practices näher betrachten, die wir bei der Software AG in unseren agilen Projekten mit Planio anwenden. Dabei werden wir uns mit dem generellen Aufbau agiler Projekte, User Stories, Tasks, Boards und Kommunikation im Allgemeinen befassen.
Sprints erstellen
Wir beginnen damit, dass wir unsere Sprints in den Projekteinstellungen hinzufügen. Hier können wir die gewünschte Anzahl von Sprints, das Anfangsdatum der Sprints und bei Bedarf einen Zeitraum oder das Sprint-Ziel in der Beschreibung hinzufügen.
Kategorien erstellen
In den Projekteinstellungen können wir auch Kategorien hinzufügen, die als Dropdown-Menü bei all unseren Aufgaben angezeigt werden. Man kann je nach Projektanforderung Kategorien definieren – diese sollten dem Sprint-Team jedoch eine Idee davon vermitteln, um was für eine Art von Arbeit es sich bei diesem Task handelt.
User Stories
User Stories beschreiben High-Level-Features in einer nicht-technischen Sprache, die den Kunden auf einfache Weise erklärt werden können. Jede User Story fasst verschiedene technische Sub-Tasks zusammen, die jedoch in der Kommunikation mit dem Kunden nicht verwendet werden. Sie sind nur für das Entwicklerteam von Interesse und werden der User Story während des Sprint-Planning-Meetings hinzugefügt, ein oder zwei Tage, bevor ein Sprint beginnt.
Typischerweise besteht eine User Story aus drei Teilen: dem Titel, der Beschreibung und den Abnahmekriterien:
Es versteht sich von selbst, dass zumindest der Titel und die Beschreibung einer User Story in einer Aufgabe zusammengefasst werden können. Wir nutzen einen dedizierten Tracker mit dem Namen Feature Request, um User Stories in unserer Planio Instanz zu repräsentieren. Diese wird nicht „User Story“ genannt, weil Planio Agile erst einige Jahre nach unserer ursprünglichen Planio Einführung hinzugefügt wurde und wir keinen zusätzlichen Tracker hinzufügen wollten.
Aber was ist mit den Abnahmekriterien? Hierfür benutzen wir Checklisten, die ein optionaler, aber doch integraler Bestandteil einer Aufgabe sind. Jedes Abnahmekriterium wird der Checkliste als separate Position hinzugefügt. Auf diese Weise werden alle drei Hauptelemente der User Story in einer einzigen Aufgabe vereint.
Aber wie werden Checklisten sogar noch besser?
Während des Sprint-Review-Meetings hakt der Kunde bzw. der Produktinhaber, der normalerweise ein Projektmitglied ist, die Abnahmekriterien auf der Checkliste ab.
Wir haben festgestellt, dass sich die direkte Einbindung des Kunden in diesen Prozess positiv auf die Motivation des Entwicklerteams auswirkt. Außerdem können Entwickler, die nicht am Sprint-Review-Meeting teilgenommen haben, am nächsten Tag die vom Kunden abgenommenen Testkriterien leicht in der Aufgabenhistorie nachverfolgen.
Tasks
Ein Task ist eine technische Arbeit, die für die Durchführung einer User Story notwendig ist. Deshalb ist es sinnvoll, Tasks in Planio als Unteraufgaben zu hinterlegen, die mit der entsprechenden (übergeordneten) User Story verknüpft sind. Wir benutzen dafür einen speziellen Tracker-Typ, der auch „Task“ heißt.
Tasks für User Stories zu definieren, die nicht Teil der nächsten Iteration werden, betrachten wir nicht als sinnvoll. Aus diesem Grund erarbeiten wir Tasks in Sprint-Planning-Sessions immer unmittelbar vor der nächsten Iteration. Die Tasks werden direkt vom Entwicklerteam festgelegt.
Der User-Story-Lifecycle
Alle unsere User Stories erscheinen zuerst mit dem Status „Neu“, ohne zugewiesenen Sprint; dies ist unser Product Backlog. Während der Sprint-Planung entscheiden wir, welche Backlog Items wir in den Sprint aufnehmen, und der entsprechende Sprint wird der User Story zugewiesen. Von hier aus starten wir mit den Sub-Tasks, die der User Story hinzugefügt wurden, bis wir der Meinung sind, dass alle Kriterien auf der Checkliste der User Story erfüllt worden sind. Daanch sind wir bereit für die Abnahme.
Bei Bedarf kann ein Feature Request von „Abgeschlossen“ auf „In Bearbeitung“ zurückgesetzt werden.
Der Task-Lifecycle
Der Fortschritt des Task-Status sollte im Sprint angezeigt werden. Eine Statusänderung bedeutet, dass es bei diesem Task einen Fortschritt gibt. In diesem Fall können wir auch sehen, dass sich die zugewiesene Person geändert hat (Entwickler > Tester).
Ist der Task abgeschlossen, ändert sich dementsprechend auch der Status des übergeordneten Tasks. In unserem Fall ist dies, wie zuvor erwähnt, die User Story.
Agile Boards
Ein anderes praktisches Feature in Planio ist das Agile Board, welches eine Nachbildung des klassischen Scrum Boards ist. Ein Projekt kann mehrere agile Boards haben, welche in der gleichen Weise wie Aufgabenberichte konfiguriert sind, welche die Filtereinstellungen nutzen.
Im Allgemeinen arbeiten wir mit drei verschiedenen Arten von agilen Boards:
- User Story Board: Dieses Board zeigt nur die User Stories und ihren aktuellen Status an. Es ist das wichtigste Board für Sprint-Review-Meetings oder Besprechungen mit dem Kunden.
- Sprint Board: Dieses Board zeigt alle technischen Sub-Tasks an, die das Entwicklerteam dem aktuellen Sprint zugewiesen hat. In den täglichen Scrum-Meetings ist es das Haupttool für das Team.
- General To-Dos: Natürlich beinhaltet jedes Projekt auch Tasks, die nicht direkt mit einem Sprint verbunden sind, z. B. Ideen, die nachträglich diskutiert und identifiziert wurden. Alle diese Sprint-unabhängigen To-Dos werden im General To-Dos Board nachverfolgt.
Kommunikation
Wir arbeiten häufig in virtuellen Teams mit Mitarbeitern aus unseren Offshore-Centern in Osteuropa und Asien zusammen. Deshalb ist Kommunikation für uns sehr wichtig.
Die Erfahrung hat gezeigt, dass E-Mails nicht als primäre Kommunikationsmethode für diese Setups geeignet sind, da sie ein viel zu hohes Risiko bergen, dass die Klärung wichtiger Anforderungen bzw. Designentscheidungen vergessen wird. Die gesamte Kommunikation muss auf einer zentralen Collaboration Site stattfinden, welche in diesem Falle das Planio Projekt selbst ist.
Es hat sich herausgestellt, dass ein bisher von unserem Unternehmen kaum beachtetes bzw. übersehenes Planio Feature große Auswirkungen auf die Kommunikation und somit auf den Projekterfolg hatte: Das Planio Blog.
Bei der Arbeit in virtuellen Teams, die aus verschiedenen Nationalitäten bestehen, dauern die täglichen Scrum-Meetings meistens länger als 10 - 15 Minuten. Durchschnittlich verbringen wir ca. 30 - 40 Minuten in diesen Meetings, für die wir Web-Konferenzsysteme nutzen, um ein Zusammengehörigkeitsgefühl im Team zu erzeugen. Es hat sich herausgestellt, dass es von großem Wert ist, wenn man das Protokoll über die wichtigsten Ergebnisse und Themen der täglichen Scrum-Meetings als Blog Post zusammenfasst und veröffentlicht. Wenn Fragen aufkommen, kann der Kunde, der ebenfalls eine E-Mail mit dem Blogeintrag erhält, direkt reagieren und offene Fragen des Entwicklerteams beantworten, indem er unter dem Artikel einen Kommentar hinterlässt.
Zusätzlich werden auch die Protokolle der Sprint-Review-Meetings und Retrospectives auf gleiche Weise verteilt und besprochen. Wie auch beim Checklisten-Effekt, der oben erläutert wurde, haben wir festgestellt, dass sich die direkte Einbindung des Kunden auch positiv auf das Team ausgewirkt hat: Alle waren bei der Arbeit am Projekt motivierter und zufriedener.
Mit dieser Kommunikationsart wird auch das Projekt-Onboarding einfacher. Ein neues Teammitglied braucht sich nur die letzten Blogeinträge durchzulesen, um sich schnell zu orientieren. Zusätzlich wird die wichtigste Projektkommunikation im Projekt selbst gespeichert und ist bei Bedarf leicht zu durchsuchen.
Damit haben wir den Überblick, wie wir Scrum mithilfe von Planio implementieren, abgeschlossen. Wir hoffen, dass Ihnen der Artikel gefallen hat und unsere agilen Best Practices auch für Ihre Projekte von Nutzen sein werden.
