Podio liefert von Haus aus kein agiles) Projektmanagement wie z. B. SCRUM oder weniger prätentiös ausgedrückt etwa eine Wochenplanung. Mit einer App für Sprints (oder Kalenderwochen oder Monate…) und einigen geschickten Ansichten kann man Podio jedoch leicht zu einem agilen System machen, das dezidierten Anwendungen in nichts nachsteht.
Was ist ein Sprint?
Im Unterschied zu einem Release, einer Version oder einer Projektphase, in der Aufgaben bzw. Features nach sachlichen Kriterien zusammengefaßt werden, ist ein Sprint ein festgelegter Zeitabschnitt, etwa eine oder drei Wochen. Das dahinter stehende Konzept wird als Timeboxing bezeichnet, wie man es auch etwa aus der Pomodoro-Technik kennt. Wer von einer Sprintplanung profitieren würde und wer nicht, ist nicht einfach zu beantworten — ein Thema für einen eigenen Artikel. Einen guten Überblick bietet die SCRUM Reference Card von Michael James und Luke Walter.
Aus dem Produkt-Backlog oder kurz Backlog, also der Liste aller unerledigten Aufgaben, werden in einem Sprintplanungs-Treffen Aufgaben in den anstehenden Sprint-Backlog “gezogen”. Während des Sprints arbeitet das Team die Aufgaben aus dem Sprint-Backlog auf einem Kanban-Board ab, und zwar ohne Ablenkung durch für den Moment irrelevante Aufgaben aus dem Produkt-Backlog, die es nicht in den Sprint geschafft haben.
Die Sprints-App
Die Sprints sind Einträge in der Sprints-App. Das Backlog ist auch einfach ein Eintrag, in diesem Beispiel abweichend von der reinen SCRUM-Lehre unterteilt in zwei Prioritätstufen. Die Liste sortiert nach Datum, daher bekommen die Backlogs ein Datum in ferner Zukunft. Jeder Sprint hat einen Status, auf dem dann Ansichten und Filter basieren.
Es gibt auch im Podio-App-Markt eine Sprints-App, aber dort wir aus meiner Sicht verkehrherum vorgegangen: Man sucht am Sprint die dazugehörigen Aufgaben aus. Das geht vielleicht, wenn im Backlog nur wenige Aufgaben/Tickets/Features liegen und man deren Namen auswendig weiß. Für eine ernsthafte Nutzung ist das jedoch nicht zu gebrauchen. Hier wird stattdessen am Ticket der Sprint ausgewählt, was man in einer Karten-Ansicht dann per drag & drop übersichtlich tun kann.
In vielen Unternehmen bekommen die Sprints Namen, dafür ist ein Feld vorgesehen. In diesem Beispiel aber hat sich das Team für Wochen-Sprints und eine Bezeichnung mit der Nummer der Kalenderwoche entschieden. Die Kalenderwoche wird aus dem Datum errechnet und zusammen mit dem Datum und dem Status von einem kleinen JavaScript als Sprint-Name ausgegeben.
Alle Tickets, an denen man diesen Sprint auswählt, erscheinen automatisch unten am Sprint unter “Verbundene Einträge” und können von dort angeklickt werden.
Die Sprintplanung
In jedem Projektmanagement gibt es eine Liste mit Aufgaben, Features, Issues, Tickets, Product Backlog Items (PBI) oder wie auch immer zu erledigende Dinge genannt werden, ich nenne sie hier Tickets. Wichtig: Dafür sollte man auf gar keinen Fall die Podio-Aufgaben verwenden, sondern unbedingt eine eigene App anlegen, in dem die Tickets dann Einträge sind. Podio-Aufgaben sind OK als Erinnerung (man kann an ihnen eine Benachrichtigung einstellen) oder als Checkliste an einem Ticket, aber das, was Podio besonders macht — die Verbindung von Einträgen einer App mit den Einträgen einer anderen App — funktioniert mit Aufgaben nicht.
Unten sieht man das Feld zur Auswahl des Sprints (der hier aus Gründen KW heißt), darüber u. a. ein Feld für den Kanban-Status. Wenn man dieses als Pflichtfeld anlegt, ist automatisch der Status “Eingang” zugewiesen, wenn man ein Ticket anlegt. Ganz unten gibt es ein Feld für einen Wiedervorlage-Termin, das gleich auch noch eine Rolle spielen wird.
Für die Sprintplanung läßt man sich die Tickets in Kartenansicht mit dem Sprint-Spalten darstellen:
Tickets können mit der Maus aus dem Backlog in den Sprint KW30 oder auch gleich in einen späteren gezogen werden; ein Sprint wird hier als Spalte angezeigt, wenn mindestens ein Ticket darin liegt.
Jetzt muß man nur noch eine Kartenansicht mit dem Kanban-Status als Spalten anlegen, bei der man nach dem aktuellen Sprint KW30 filtert, so daß nur die beiden Tickets in dem Sprint angezeigt werden:
Das Wiedervorlage-Datum erzeugt per GlobiFlow eine Benachrichtigung; damit kann man Tickets im Backlog zwecks Berücksichtigung in der Sprintplanung in Erinnerung rufen, was sich besonders bei Aufgaben empfiehlt, die eine Deadline haben. Mit GlobiFlow kann auch etwa die Aktualsierung des Sprint-Status automatisiert werden.
Auswertungen
Daten, die zum Beispiel am Sprint gesammelt werden können:
Anzahl der Tickets insgesamt, Anzahl der Tickets pro Status — offene, in Arbeit, erledigte o.ä. Summe der geschätzten und/oder tatsächlich geleisteten Aufwände — für die Sprintplanung eigentlich unerläßlich (Voraussetzung: am Ticket wird eine Aufwandsschätzung bzw. Aufwandserfassung eingetragen). Summe des Aufwands erledigter Tickets pro Tag — auf der Grundlage kann dann ein Burndown- oder Burnup-Chart erstellt werden, ebenfalls automatisch und direkt in Podio am Sprint Gleiche Zielsetzung aber einfacher: Prozentsatz erledigter zu geplantem Aufwand Hier eine Liste mit dreiwöchigen Sprints mit Namens-Systematik (die unterwegs geändert wurde) mit geschätzten und getrackten Stunden:
Schlagwörter: agil, Burnup-Chart, JavaScript, Kanban, Podio, Projektmanagement, Release, SCRUM, Sprintplanung, Wiedervorlage, Wochenplanung