Auch im agilen Umfeld ist die Planung was kommt ein wichtiger Aspekt in der Produktentwicklung. Wer mit Iterationen arbeitet kann die Roadmap einfach als zeitlichen Rahmen ansehen für das was entstehen soll und damit seine Sprints planen. Die Roadmap in der agilen Produktentwicklung vermittelt den Beteiligten in welche Richtung ein Produkt geht. Und gibt agilen Teams die Möglichkeit flexibler zu reagieren, wenn sie sehen was noch kommt.
Definition: In Scrum wird eine Iteration als Sprint bezeichnet. Es handelt sich hierbei um einen festgelegten Zeitrahmen von ein, zwei bis vier Wochen in denen agile Teams ein auslieferbares Produkt entwickeln.
Einen Kuchen isst man Stück für Stück
Wer ein großes Projekt umsetzen will kann dies durch den Einsatz agiler Methoden einfach in kleine Stücke aufteilen. So wie einen Kuchen den man in kleine Stücke schneidet. Der Product Owner verwendet die Roadmap bei langfristiger Planung beispielsweise um die geplanten Funktionalitäten eines Produkts zu skizzieren oder wann neue Funktionen veröffentlicht werden.
Bei agiler Entwicklung liefern Teams in der Regel am Ende eines jeden Sprints eine Arbeitssoftware als Release (oder Version). Agile Teams nehmen also die Aufgaben aus dem Produkt-Backlog die vom Umfang her abgearbeitet werden können. Sie schätzen die Umsetzung und weisen sie anschließend dem jeweiligen Sprint zu. So stellt die Roadmap für sie einen wesentlichen Bereich ihrer täglichen Arbeit dar.
Roadmapeinsatz in Redmine
Nachfolgend zeigen wir auf, wie die Roadmap in Redmine mit Hilfe einiger Zusatzplugins in der agilen Produktentwicklung genutzt wird.
Was Du brauchst
- eine aktuelle Redmine Installation
- eine aktuelle Version des Plugin Bundles Redmine HRM und Redmine Reporting
- ein Projekt in dem Du Versionen anlegen kannst
- ein Produkt Backlog welches die zu geplanten Aufgaben enthält
Was zu tun ist
Existiert ein gefülltes Produkt-Backlog an Aufgaben für das Team, dann ist es an der Zeit mit Hilfe der Redmine Funktion Versionen die geplanten Sprints anzulegen. Dies wird innerhalb der Projektkonfiguration im Bereich Versionen erledigt. Nachfolender Screenshot zeigt die Eingabemaske. Alle für den Sprint relevanten Informationen (Name, Start- / Enddatum, Sprintziel) werden hier eingetragen.
Das Reporting Plugin liefert hierbei die Möglichkeit ein Startdatum einzugeben welches für die Ressourcenberechnung und in den Tickets sowie diversen Auswertungen verwendet wird.
Vor dem Sprint
Wurden die anstehenden Iterationen festgelegt und die Sprints in Form von Versionen in Redmine angelegt geht es ans Sprint Planning Meeting. In diesem wird der anstehende Sprint geplant.
Der Product Owner entscheidet was in dem Sprint für Anforderungen umgesetzt werden. Im Sprint Backlog findet man die gewünschten Anforderungen in Form von Aufgaben. Ziel ist es eine Aufgabe innerhalb eines Arbeitstages erledigen zu können. Ist dies nicht der Fall müssen die Aufgaben in kleinere Teile herunter gebrochen werden. Das Scrum Team bestimmt welche Aufgaben aus den Anforderungen im Sprint wie von Ihnen bearbeitet werden.
Dafür werden die Aufgaben gemeinsam besprochen, sowie Fragen und die Umsetzungsmöglichkeiten geklärt. Dies ist für die anschließende Zeitschätzung wichtig. Dann nimmt sich ein Teammitglied der Aufgabe an (Commitment). Für die Aufgabe existiert in Redmine ein Ticket welches noch entsprechend vervollständigt werden muss.
Wichtige Informationen sind die Zeitschätzung, die Zuweisung des Sprints, die Zuweisung des Bearbeiters und gegebenenfalls eine Priorität. Auf diese Art und Weise werden alle zeitlich möglichen Aufgaben für den Sprint bearbeitet bis das berechnete Zeitkontingent gefüllt ist.
Wurden die Tickets entsprechend zugewiesen hilft zwischendurch (oder abschließend) ein kontrollierender Blick auf die Ressourcenverwaltung des HRM Plugins. Hier lässt Du dir über die Filteroptionen den geplanten Sprint und die teilnehmenden Teammitglieder anzeigen. Dadurch erhälst Du nicht nur eine Übersicht zu den verfügbaren Ressourcen und der Velocity, sondern auch alle relevanten Planungsinformationen wie Geplante Stunden, Verfügbare Stunden, Gesamtkapazität.
Wichtig für die Sprintplanung ist, dass vorher mögliche Feiertage und geplante Abwesenheiten des Teams (z.B. Urlaub, Fortbildung etc.) eingetragen / genehmigt wurden.
Stehen alle Aufgaben für den anstehenden Sprint kann’s auch schon los gehen.
Während dem Sprint
Während des Sprints ist nicht nur das tägliche Scrum Meeting (Daily Scrum) eine wichtige Aktivität für das Team, sondern auch der regelmäßige Blick auf die Ressourcenverwaltung. Hier lassen sich frühzeitig Probleme erkennen. Eine wichtige Voraussetzung hierfür ist jedoch, dass die Teammitglieder ihre tägliche Aufwandsbuchung spätestens am Ende des Arbeitstages durchführen. Immer dann, wenn sie an einem zugewiesenen Ticket gearbeitet haben. Nur so werden Änderungen in der Ressourcenverwaltung sichtbar.
- Innerhalb der Ressourcenansicht zeigt ein rotes Symbol bei den gefährdeten Teilnehmern an, dass etwas nicht stimmt.
- Die unterhalb der Ressourcenansicht befindliche Box Hinweise und Probleme in der Ressourcenzuweisung liefert nützliche Informationen bei wem welches Problem auftritt.
- Ist beispielsweise ein Team-Mitglied erkrankt kann dieser seine zugewiesenen Aufgaben für den Sprint eventuell nicht mehr schaffen. Hier solltest Du überprüfen ob ein anderes Mitglied noch Kapazitäten frei hat und die Aufgabe übernehmen will.
Nach dem Sprint
Nach einem abgeschlossenen Sprint setzen sich alle Team-Mitglieder im sogenannten Sprint Review Meeting zusammen und stellen das zwischenzeitlich entstandene Produkt dem Produkt Owner und Stakeholdern vor.
Hierbei werden vom Product Owner die umgesetzten Anforderungen gecheckt. Wurde das erwartete Ergebnis erreicht? Aufgaben die - aus welchen Gründen auch immer - nicht erledigt werden konnten, kommen wieder in den Produkt-Backlog für eine spätere Umsetzung.
Sind Stakeholder am Meeting beteiligt können sie ihr Feedback zum (vom Team gemeinsam) vorgestellten Produkt abgeben. Hieraus ergeben sich eventuell Änderungswünsche oder weitere Featurewünsche.
Wie ihr daraus lernt
Nach dem Sprint ist vor dem Sprint. Du solltest mit Deinem Team nach dem Review Meeting in einem Retrospective Meeting besprechen was im vorausgehenden Sprint gut oder auch weniger gut gelaufen ist. Vor allem in der Anfangszeit ergibt sich hieraus viel Verbesserungspotenzial für den nächsten Sprint. Hilfreich ist hier auch der Einsatz diverser Auswertungen die das Reporting Plugin für Redmine bereit stellt.
Der Ticketfilter “Geschätzter Aufwand überschritten” hilft beispielsweise dabei heraus zu finden, welche Aufgaben während eines Sprints aufgrund unerwarteter Probleme länger dauerten als geplant.
Je nachdem was für Probleme aufgedeckt werden können kannst Du entsprechend handeln. Vielleicht muss die Velocity für ein Teammitglied angepasst werden. Oder es traten während der Umsetzung andere Probleme auf die bei der Schätzung zum Ticket nicht berücksichtigt wurden. Vielleicht weil das nötige Wissen hierfür fehlt. Oder es gab Verständnisprobleme bezüglich der Ticketbeschreibung weil sich ein Mitglied nicht nachfragen traute. Was auch immer die Ursache ist. Mit den entsprechenden Werkzeugen kann man hier für den nächsten Sprint besser gegensteuern.
Wer Redmine noch nicht kennt kann sich den Funktionsumfang der neusten Version, sowie unsere hier erwähnten Add-Ons in der Online-Demo auf dieser Webseite ansehen. Bei Interesse oder weiteren Fragen steht unser Support gerne zur Verfügung. Hinterlass uns einfach eine Nachricht. Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.
