Ist es möglich, Zeitpläne in SCRUM anzugeben?

Wie bei den meisten Dingen kommt es darauf an.

Theoretisch könnten Sie vorhersagen, wann die Arbeit voraussichtlich erledigt sein wird. Wenn Sie die durchschnittliche Geschwindigkeit Ihres Teams verstehen (ob in Story Points pro Sprint, idealen Stunden pro Sprint, Backlog-Elementen pro Sprint), können Sie prognostizieren, wann Sie zu einem bestimmten Element im Backlog gelangen. Es gibt jedoch viele Vorbehalte damit. Es hängt davon ab, ob die gesamte Arbeit bis zum betreffenden Artikel gut verfeinert und geschätzt ist. Es wird auch davon ausgegangen, dass die Reihenfolge der Arbeiten (einschließlich Hinzufügungen und Entfernungen) festgelegt ist. Die Geschwindigkeit des Teams kann sich aus verschiedenen Gründen im Laufe der Zeit (in beide Richtungen) ändern. Jede solche Prognose, insbesondere wenn sie mehr als ein paar Sprints entfernt ist, weist eine große Variabilität auf. Die Prognose ist eine Ist-Momentaufnahme, die sich täglich ändern kann, wenn sich der Rückstand ändert.

In der Praxis würde ich sehr zögern, auch nur zu versuchen, mehr als das vorherzusagen, was im aktuellen Sprint und vielleicht im nächsten Sprint getan wird. Wenn Sie Agilität wirklich annehmen, was die Reaktionsfähigkeit auf Änderungen und Feedback beinhaltet, müssen Sie anpassungsfähig sein. Es ist nicht ungewöhnlich, dass Menschen Schätzungen und Prognosen in Fristen umwandeln. Festgelegte Fristen machen es schwieriger, auf Veränderungen zu reagieren, insbesondere wenn Sie versuchen, ein nachhaltiges Arbeitstempo aufrechtzuerhalten.

Das Beste, was Sie tun können, ist, mit allen Beteiligten zusammenzuarbeiten, um Kompromisse zu verstehen. Anstatt Termine vorherzusagen, bringen Sie die Arbeit in die richtige Reihenfolge. Wenn es Arbeiten gibt, die Fristen haben, nach denen die Arbeit nicht mehr wertvoll ist, sollte dies bei der Bestellung des Rückstands berücksichtigt werden.

Das gewünschte Werkzeug ist ein Burnup-Diagramm. JIRA hat sie als Release Burnup Chart oder Release Forecast Chart eingebaut (sie ändern ständig den Namen), aber die Funktion in JIRA ist begrenzt, da es nur die gesamte Veröffentlichung prognostiziert. Sie können diese Diagramme jedoch von Hand erstellen – sie mögen auf den ersten Blick schwierig erscheinen, aber sie sind sehr schnell und sehr einfach, sobald Sie den Dreh raus haben. Von Hand gebaut, können Sie spezifische Merkmale einfacher vorhersagen.

Es gibt ein paar Dinge, die Sie und Ihr Vorgesetzter über dieses Tool wissen sollten:

1. es gibt Ihnen einen Blick auf die Dinge, wie Sie sie heute kennen. Ihr Lernen entwickelt sich und so ändert sich das Diagramm, wenn Sie mehr lernen und Fortschritte machen. In Wirklichkeit gibt es hier nichts Neues, aber GANTT-Diagramme gaben die Illusion von Gewissheit. Jeder Projektmanager weiß jedoch, dass sich GANTT-Diagramme im Laufe des Projekts ständig ändern.

2. Burnup-Charts geben eine Bandbreite an – normalerweise von pessimistischer Prognose über durchschnittlich bis optimistisch. Wenn Sie Ihre optimistischste Prognose nehmen und sie dem CEO versprechen, haben Sie sich Ihr eigenes Grab geschaufelt.

Zum Schluss noch ein kleiner Tipp: Bei einer großen Anzahl von Rückstandselementen ist das Zählen von Elementen oft genauso genau oder fast so genau wie das Verwenden der Schätzungen, es sei denn, Sie haben Elemente mit sehr unterschiedlichen Größen.

Sind Timelines Non-Agile/-SCRUM oder soll eine Timeline für Aufgaben, die Monate in der Zukunft liegen, immer möglich sein.

Sie können immer eine längerfristige Release-Planung durchführen, egal ob Sie Scrum oder etwas anderes verwenden. Sie sehen sich im Grunde die Funktionen an, die Sie erledigen möchten, schätzen jede einzelne davon, und wenn Sie dann die Geschwindigkeit des Teams und die Länge eines Sprints in Tagen/Wochen kennen, können Sie einen Zeitplan prognostizieren.

Aber natürlich kann, wie Sie selbst erwähnt haben, zwischen dem Zeitpunkt, an dem Sie diese Prognose abgeben, und dem Moment, an dem Ihr Release "tatsächlich abgeschlossen" sein wird, eine Menge passieren. Agile Praktiken wie Scrum erkennen dies als Realität an und versuchen nicht, alles im Voraus abzuschätzen und vorherzusagen, wann alles erledigt sein wird. Der Umfang ist in Scrum flexibel. Eine Release-Planung im Voraus legt den Umfang fest. Tatsächlich legt es den Umfang in der Vorstellungskraft der Menschen fest, denn während Sie an Ihrem Produkt arbeiten, entdecken Sie neue Erkenntnisse, es treten Dinge auf, Änderungen sind erforderlich usw. Der Umfang ändert sich also zwangsläufig, wenn Sie DAS RICHTIGE Produkt und nicht IRGENDEIN Produkt für Sie bauen möchten am Anfang eingebildet (wenn man am wenigsten davon weiß).

Sehen Sie sich zum Beispiel diese Erklärung an , wie eine längere Release-Planung mit Scrum durchgeführt werden kann. Sie können es tun, aber Sie haben keine Garantie dafür, dass Sie es tatsächlich schaffen, denn die Dinge entwickeln sich. Das ist einer der Gründe, warum in Scrum das Product Backlog priorisiert und detailliert und oben geschätzt wird, und die Dinge verschwommen werden, wenn Sie nach unten gehen, weil Sie nicht versuchen, eine Reihe von Funktionen zu erstellen, sondern die richtigen Funktionen erstellen möchten. Jetzt herauszufinden, was in Monaten verfügbar sein wird, ist also eine schlechte Idee und normalerweise eine Verschwendung, und das nicht nur bei Scrum, sondern im Allgemeinen. Wenn Sie sich entschieden haben, Feature F in zwei Monaten zu erstellen, wird das Feature nicht auf magische Weise zu einem Teil des Produkts, da dieses Feature in zwei Monaten aus verschiedenen Gründen möglicherweise völlig nutzlos oder sogar schädlich für das Produkt ist .

Agile und auch Scrum erfordern eine Zusammenarbeit zwischen dem Entwicklungsteam und denen, die nach dem Produkt fragen. Was Ihr Management versucht, ist, sich von dieser Zusammenarbeit "entschuldigen" zu lassen und einfach zu erwarten, dass Sie Dinge bauen, wenn sie es wollen. Und die Art und Weise zu ändern, wie sie die Entwicklung sehen und was ihre Rolle in allem ist , wird leider viel schwieriger sein, als Zeitpläne mit Scrum vorzugeben.

Schätzungen und Geschwindigkeit sind die Antwort auf Ihre Frage. Nichts an Scrum hindert das Team daran, die Arbeit zu schätzen (und es sollte das Team sein, das dies tut, nicht eine einzelne Person). Der Scrum-Ansatz hilft bei der Schätzung, und Scrum-Teams stützen ihre Prognosen normalerweise auf die Geschwindigkeit (Evidenz basierend auf früheren Ergebnissen) und nicht auf spekulativere Vorhersagen.

Es ist in Scrum nicht weniger möglich, Zeitpläne anzugeben als in anderen Methoden.

Der Hauptunterschied besteht darin, dass wir in Scrum nicht ermutigt werden, offen zu lügen, deshalb müssen wir das Team bitten , Product Backlog-Einträge zu schätzen, und deshalb betrachten wir jeden Burndown oder Burnup nur als Prognose .

Die Angabe von Zeitplänen ist in einem traditionellen PMI-Projekt nicht besser. Fristen werden selten eingehalten, vielleicht wenn großzügige Eventualitäten zu den Schätzungen hinzugefügt werden und Überstunden durchgesetzt werden.

Angenommen, Sie haben ein ziemlich ausgereiftes Scrum-Team, das an dem Projekt arbeitet – was bedeutet, dass es über eine gute Streuung angemessener technischer Fähigkeiten verfügt, gut zusammenarbeitet, die Scrum-Praktiken angemessen befolgt und einen Punkt sowohl in der Produktivität als auch in der Einschätzung erreicht hat regelmäßig in der Lage sind, das Sprintziel zu erreichen, ohne stark über- oder unterfordert zu sein, dann:

1. Jedes Produkt-Backlog-Element sollte an einer Position im Backlog platziert werden, die seine Priorität relativ zu den anderen PBIs gemäß dem Verständnis des Product Owners über den aktuellen Status des Produkts darstellt .

2. Jeder Product-Backlog-Eintrag sollte schätzbar sein, was bedeutet, dass das Team eine ungefähre Vorstellung davon hat, wie einfach oder kompliziert er im Vergleich zu anderen Aufgaben ist, und daher von seiner Fähigkeit, ihn zu erledigen, wenn er in einem Sprint enthalten wäre. (Dies könnte in Form von Story Points oder auf andere Weise erfolgen, wie T-Shirt-Größen oder Weltdenkmäler oder was auch immer, solange das Team versteht, wie die Werte miteinander zusammenhängen.)

3. Die Product-Backlog-Elemente ganz oben im Backlog sind im Durchschnitt besser verständlich, klarer definiert, kleiner und haben weniger unerfüllte Voraussetzungen als die weiter unten im Backlog – dh sie sollten fertiger sein, mit den Elementen ganz oben Top ist möglicherweise sofort bearbeitungsbereit.

Wenn dies der Fall ist, sollte der Product Owner in der Lage sein, im Wesentlichen einfach irgendwo im Product Backlog eine Linie zu ziehen und zu sagen: „Das ist es, was wir im nächsten Sprint liefern“, und das Scrum-Team sollte nahe genug daran sein, dem zuzustimmen, dass sie kann verhandeln und den Punkt ein paar Punkte nach oben oder unten anpassen.

Das bedeutet auch, dass der Product Owner in der Lage sein sollte, mehrere Zeilen im Product Backlog zu zeichnen, die jeweils den Arbeitswert eines Sprints darstellen. Wenn Sie das tun, haben Sie eine Schätzung, wie lange es dauern wird, bis ein bestimmtes Element abgeschlossen ist, da es nur eine Funktion davon ist, wie viele Sprints noch entfernt sind und wie lange Ihre Sprints dauern.

Allerdings müssen Sie die Punkte 1 und 3 oben im Auge behalten. Jedes Sprint Review ist eine Diskussion zwischen dem Scrum-Team und dem Kunden und stellt einen Punkt dar, an dem der Product Owner entscheiden kann, die Reihenfolge der Elemente im Backlog zu ändern oder sogar zu ändern, welche Elemente überhaupt im Backlog enthalten sind. Darüber hinaus ist alles, was sich weiter unten im Backlog befindet, von Natur aus von Unsicherheit getrübt - etwas, das derzeit 1 Sprint im Backlog zurückliegt, wird wahrscheinlich im nächsten Sprint landen, aber etwas, das 4 Sprints zurückliegt, könnte von jetzt an in 3 Sprints bearbeitet werden. oder 5. Es könnte in 3 verschiedene Elemente aufgeteilt werden, weil es tatsächlich mehrere große Entwicklungen beinhaltet, oder das Team muss möglicherweise in eine Forschungsspitze investieren, um überhaupt zu verstehen, was die Entwicklung dieses Features überhaupt mit sich bringt.

Viele Projekte im Wasserfallstil gehen davon aus, dass die zu Beginn des Projekts geplanten Meilensteine ​​perfekt geschätzt und vorhersehbar sind, aber wenn Sie in einem Scrum-Team arbeiten, besteht eine gute Chance, dass Ihr Produkt nicht gut hineinpasst dieses Paradigma an erster Stelle, und die Stakeholder, die Ihnen im Nacken sitzen und nach perfekt verantwortungsvollen Zeitrahmen fragen, werden Schwierigkeiten haben, sich daran zu gewöhnen, aber hoffentlich, wenn sie an den Schlüsselteilen des Scrum-Prozesses beteiligt sind (insbesondere Sprint Review, wo sie sowohl die inkrementelle Entwicklung des Produkts als auch die Anpassung des Product Backlogs sehen können), dann werden sie anfangen zu lernen, wie wertvoll es ist, diese Unsicherheit anzunehmen – die immer da sein wird, aber in Scrum viel offenkundiger wird als in Waterfall .

Wenn Sie Scrum durchführen, ist es nicht möglich, den Zeitplan für das gesamte Projekt abzuschätzen. Es kann nur funktionieren, wenn Sie den agilen Ansatz verfolgen, der erfordert, dass die Zeitpläne davon abhängen, was der Product Owner im Product Backlog priorisiert hat. Darüber hinaus kann das Entwicklungsteam, wenn es sich für die Anzahl der Features entschieden hat, die in einem Sprint erstellt werden sollen, den Aufwand abschätzen, der erforderlich ist, um ein Feature in Form von Story Points zu erstellen. Die Gesamtzahl der Story Points in einem Sprint Backlog ist der Aufwand und die Zeit, die zum Erstellen der Features erforderlich sind.