Das Scrum Team hat Storys mit Story Points und dem Teammitglied, das diese Story realisieren soll, im Backlog stehen.
Wenn das Projekt beginnt, werden diese Storys nun in den aktuellen Sprint gezogen.
Dadurch bekommt die Story einen Anfangs- und Endtermin, nämlich den des Sprints.
Storys in Sprints und Backlog in Jira
Die Schnittstelle legt nun ein entsprechendes Arbeitspaket in Can Do an. In einem hybriden Projektplan können solche Arbeitspakete farblich unterschieden werden.
Hybride Planung in Can Do mit Storys aus Jira
Zusätzlich wird der Bearbeiter aus Jira in Can Do als Ressource zugewiesen. Die Story Points, erfasst in der Story in Jira, werden entsprechend der Metrik in Arbeitsstunden umgerechnet und für die Ressource zugewiesen.
Automatische Ressourcenzuweisung aufgrund einer Jira Story in Can Do
Die darüber liegende Phase im Netzplan kann diese Ressource oder deren Abteilung zur Grobplanung zugewiesen bekommen haben. Wurde die Funktion „Abziehbar“ dort aktiviert, erkennt Can Do, dass in dem Paket diese Ressource verwendet wurde und zieht die Zuweisung des Paktes von oben ab.
Es entsteht keine Doppelplanung auf der Phase und dem Paket. Aus der groben, phasenorientierten Kapazitätsplanung wird so schrittweise eine detaillierte Arbeitspaketorientierte Planung.
Weiterhin wird in Can Do die gesamte mathematische Logik, Funktionalität und Künstliche Intelligenz aktiviert. Diese beginnt unverzüglich mit allen Berechnungen, Prognosen und Risikoanalysen.
Dabei werden automatisch Kosten berechnet, Budgets angepasst und eine Kapazitätsanalyse für dieses Arbeitspaket und für die Phase durchgeführt. Findet die Künstliche Intelligenz potentielle Probleme oder Risiken, wird das dem Projektleiter sofort mitgeteilt.
Das so erzeugte Arbeitspaket kann in Can Do nicht verändert werden. Jira ist dafür das führende System. Alle Änderungen, beispielsweise eine zeitliche Verschiebung des Pakets, werden vom System abgelehnt und müssen in Jira durchgeführt werden.
Die Story wird nun vom Team abgearbeitet. Dabei wird auch der Status der Story in Jira verändert. Sobald das Teammitglied mit der Arbeit beginnt, wird diese Statusänderung sofort an Can Do weitergeleitet und auch dort der Status des Arbeitspakets auf „in Arbeit“ gesetzt.
Zwei Jira Storys als Arbeitspakete in Can Do, deren Arbeit begonnen wurde
Scrum kennt in diesem Sinne keinen Fertigstellungsgrad für Storys, d.h. der
Mitarbeiter, der an der Story arbeitet, erfasst keinen prozentualen Fortschritt. Er meldet nur, wenn er mit der Story fertig ist, indem er den Status in Jira auf „Fertig“ ändert.
In Jira wurde die Story beendet, der Status in Can Do wird auf "Abgeschlossen" gesetzt
Auch nachträgliche Änderungen der Story Points führen unverzüglich zu einer Anpassung der Zuweisungsmenge für die Ressource in Can Do, gefolgt von einer neuen Kapazitätsberechnung mit Risikoprognose.
Erreicht das Scrum Team das Ziel, alle Storys eines Sprints am Ende des Sprints abzuschließen, nicht, werden die betroffenen Storys häufig einfach in den nächsten Sprint gezogen. Passiert das, wird unverzüglich auch das Arbeitspaket in Can Do entsprechend den neuen Terminen verschoben.
Die Schnittstelle zwischen den beiden Systemen hält die Daten also immer auf dem gleichen Stand und arbeitet in Echtzeit. Meistens dauert es weniger als eine Sekunde, bis eine Änderung durchgeführt wird.
Standardmäßig wird in Can Do jede Aktion revisionssicher mitprotokolliert und in der sog. History dargestellt. Dies gilt auch für Änderungen, die das Jira-Interface durchführt.
History-Eintrag für ein Arbeitspaket in Can Do, das aus Jira gesteuert wird
Der Projektmanager hat zwar keinen Einfluss auf diese Planungsobjekte, diese werden vom Scrum Team in Jira verwaltet, ihm entgeht allerdings auch keine Änderung, die Auswirkung auf seinen Plan hat.
Der Projektmanager spart deutlich Arbeit, denn er muss die Feinplanung nicht selbst erstellen. Die Künstliche Intelligenz und andere Funktionen in Can Do machen die Projektüberwachung deutlich einfacher. Der Mehrwert ist erheblich: weniger Arbeit, mehr Transparenz und absolute Konsistenz.
Das Scrum Team muss seine Arbeitsmethode und den Umgang mit Jira nicht verändern.
Im Prinzip könnte das Team die Tatsache, dass die Planung nun voll automatisch in einem hybriden Plan in Can Do existiert, komplett ignorieren.
In der Praxis verwenden aber die agilen Teams Can Do bei Sprint-Planning-Meetings, um sicherzustellen, dass sie sich selbst nicht überlasten. Viele andere verfügbarkeitsmindernde Aktionen sind nur in Can Do geplant. Dazu zählen Urlaub, Grundlasten und nicht agile Arbeiten. Das Team hat den völligen Überblick über die kapazitativen Möglichkeiten für den kommenden Sprint, aber auch für spätere Sprints, wenn das Team langfristiger planen möchte.
Auch Themen wie Zeiterfassung werden in aller Regel in Can Do durchgeführt. Das kann auch für die Storys aus Jira direkt in Can Do durchgeführt werden.
Es gibt in Can Do eine ganze Reihe von sehr komfortablen Apps zur Zeiterfassung.
Besonders beliebt ist die App für Smartphones, die es für Apple und Android-Handys in den jeweiligen Stores gibt.
Die häufige Anforderung, Ist-Zeiten nach SAP zu übertragen, um die Projektkosten und -aufwände vollständig zu dokumentieren, wird hier gleich miterledigt, da die allermeisten Can Do-Systeme mit SAP über eine Standardschnittstelle verbunden sind.
