Berechnung von Projektprognosen in Jira

Insgesamt scheinen Sie auf dem richtigen Weg zu sein. Denken Sie an den Scrum-Leitfaden :

Das Entwicklungsteam ist für alle Schätzungen verantwortlich.

Lassen Sie das Entwicklungsteam die groben Schätzungen erstellen. Daher kann das Feld wie vorgesehen verwendet werden.

Laut McConnell ("Software Estimation") ist die T-Shirt-Größenbestimmung hilfreich, um dem Produktteam zu helfen, Dinge im Rückstand zu priorisieren, da die Größenbestimmung es ihnen ermöglicht, die Priorität eines Features basierend auf seiner Größe und seinem Wertverhältnis zu verstehen. Sie können es also für diesen Zweck verwenden. Und Sie können ein benutzerdefiniertes Feld dafür erstellen und es sogar vor Entwicklern verbergen, nachdem es über den Workflow verschoben wurde, wenn Sie möchten (obwohl es meiner Meinung nach Entwickler nicht so sehr "verankern" wird, wie Sie befürchten).

Aber um numerische Schätzungen zu erstellen, um Fertigstellungstermine vorherzusagen, müssen Sie tatsächlich numerische Schätzungen von Entwicklern erhalten, wie die Leute raten.

Der Versionsbericht gilt pro Board. Wenn Sie also mehrere Boards haben, wird für jedes Board eine andere Schätzung erstellt. Daher würde ich diesen Ansatz nur in Betracht ziehen, wenn das Projekt ein einzelnes Board verwendet. Gleiches gilt für den Release Burn-down Report . Ich glaube nicht, dass beide Berichte ein konsistentes Ergebnis liefern, wenn mehr als ein Board vorhanden ist. Das Release (Feld) ist nicht Board-spezifisch, aber solche Berichte hängen vom Board ab.

Die Art und Weise, wie Sie die Prognose bereitstellen möchten, ist von unten nach oben, basierend auf der Schätzung der Epics und Stories. Ich denke, der genannte Bericht funktioniert möglicherweise nur, wenn es ein Board pro Projekt gibt, was ein einfacher Fall ist. Jira sollte einen besseren Satz von Berichten mit einem höheren Maß an Anpassung bereitstellen, um über einige nützliche Tools zur Vorhersage der Zukunft (Prognose) zu verfügen. Die vorhandenen Berichte sind ohne Anpassung schwer verständlich und gelten nicht für ein Projekt, das mit mehr als einem Board arbeitet.

Eine andere Problemumgehung wäre, den gesamten Rückstand mit einer beliebigen Schätztechnik zu schätzen, es könnte Story Points zuweisen und dann, anstatt die Vorgänge im Rückstand zu behalten, das Team fragen, wann sie voraussichtlich geliefert werden, und sie dann zukünftigen Sprints zuweisen. Jetzt haben wir die Arbeit geplant. Exportieren Sie die Informationen aus Jira in eine Excel-Datei, und dann haben wir einen Plan, der auf der geplanten Sprintarbeit basiert. Dies ist eine mögliche Problemumgehung, um die Zukunft vorherzusagen und eine Kapazitätsanalyse basierend auf der Ressourcenplanung durchzuführen und mögliche Lücken zu identifizieren.

Ich sehe keinen Sinn darin, am Ende ein anderes Feld für die Schätzung zu verwenden, da die Schätzungen im Rahmen der Pflegeaktivitäten präziser werden, wenn wir mehr über die zu implementierende Geschichte / das Epos wissen. Die Schätzung ist ein iterativer Prozess, bei dem der Sortierterm genauer ist als die Zukunft.

Für Nex-Gen Jira Project gibt es ein neues Feature: Roadmap , aber es ist nicht für klassische Projekte verfügbar. Die Auswahl eines Next-Gen- oder Classic-Projekts hat Vor- und Nachteile. Zum Beispiel haben Sie eine Roadmap für die nächste Generation, aber dann haben Sie zum Beispiel keine Unteraufgaben und auch andere Einschränkungen.

Die Verwendung einer Roadmap bietet eine Top-Down-Planung, wie sie sein sollte. Für ein klassisches Projekt ist die einzige gleichwertige Lösung der Kauf eines Plugins von Jira Marketplace, z. B. Easy Agile User Story Map für Jira oder andere Plugins wie Jira Portfolio oder Big Project, die ähnliche Lösungen bieten.

Die Basisversion von Jira bietet eingeschränkte Möglichkeiten, eine Prognose zu erstellen. Jira folgt den Agile/Scrum-Prinzipien, bei denen die einzige Möglichkeit, die Zukunft vorherzusagen, darin besteht, ein Stück Software bereitzustellen und den Beteiligten die geleistete Arbeit in einer Demo-Sitzung zu zeigen. Berichte sind nur für den internen Gebrauch des Teams bestimmt, aber nicht für andere Zielgruppen wie externe Stakeholder.

Ich würde Ihnen gerne eine optimistischere Antwort geben, aber ich glaube nicht, dass die aktuelle Jira-Version (zumindest für Jira Cloud, die ich kenne) keinen einfachen Weg zu dieser Prognoseabschätzung bietet.

Ich würde argumentieren, dass Sie nicht „… meinem Product Owner helfen wollen, eine fundierte Vermutung darüber anzustellen, wann Features in einem Projekt implementiert werden, um mit Stakeholdern zu kommunizieren, damit sie den Umfang verwalten können.“

Projektionen sind nur nützlich, wenn sie Vertrauensschätzungen enthalten, die eng genug sind, um für die Planung verwendet zu werden.

Meiner Erfahrung nach muss Ihr Product Owner Folgendes wissen:

• Welche Funktionen sind in der aktuellen Version enthalten? (Fertig, geliefert, voraussichtlich zuverlässig; wenn sie es nicht sind, ist das technische Schuld und wir müssen uns unterhalten.)
• Welche Funktionen befinden sich in der Entwicklung (nächste Version)? Hohes Vertrauen, dass sie pünktlich geliefert werden. (Denn das gesamte Team hat sich darauf geeinigt, und wenn sich das ändert, werden Sie den Product Owner umgehend benachrichtigen)
• Welche Funktionen sind in Planung? Welche Funktionen haben es für diesen Sprint nicht geschafft, werden aber wahrscheinlich im nächsten sein. Dies ist eine niedrige Vertrauensschätzung und sollte nicht verwendet werden, um Ressourcen zu programmieren oder Produkte zu verkaufen. Dies ist nur eine fundierte Vermutung.
• Welche Funktionen befinden sich im Rückstand und werden wahrscheinlich nicht Teil dieses oder des nächsten Sprints sein? Dies ist kein Versprechen, kann aber bei der Planung helfen. Wenn ich weiß, dass Feature X nicht Teil der Entwicklung oder Planung ist, kann ich Problemumgehungen entwickeln oder meine Arbeit so planen, dass ich mich nicht auf dieses Feature verlassen muss.