Ich habe mich gefragt, ob es eine gute Idee ist, Sprints mit benutzerfreundlichen Namen zu benennen, anstatt Zahlen wie Sprint 1, Sprint 2 usw. zu verwenden. Gibt es Best Practices oder Standards für die Benennung des Sprints nach Themen oder wichtigen Meilensteinen für das Projekt?
Ich habe mich gefragt, ob es eine gute Idee ist, Sprints mit benutzerfreundlichen Namen zu benennen, anstatt Zahlen wie Sprint 1, Sprint 2 usw. zu verwenden.
Nein, das ist keine gute Idee.
Ein Sprint ist ein Behälter, in dem Product Backlog-Einträge vorübergehend für kurze Zeit gespeichert werden. Ein Sprint kann einige Projektartefakte hervorbringen, aber der Sprint selbst hat nur als Zeitfenster einen Wert. Selbst wenn Sie einen Anwendungsfall für die Nachverfolgung von Sprints anhand des Namens finden, verringert das Versehen von Sprints mit nicht-ordinalen Bezeichnungen die Einfachheit der Kommunikation und die Menge an Informationen, die durch den Namen vermittelt werden.
Ein Sprint ist der Name, den das Scrum-Framework einer zeitgesteuerten Iteration gibt. Während jeder Sprint ein definiertes Sprint-Ziel hat, ist der Sprint selbst kein Projektartefakt, das für historische Aufzeichnungen oder Prozessverbesserungen aufbewahrt werden muss.
Aus Sprints resultieren oft verschiedene projektrelevante Outputs wie Velocity-Messungen, fertige Features, neue User Stories für das Product Backlog oder Prozessverbesserungen, aber die Time-Box selbst hat nach Ablauf keinen bleibenden Wert. Unabhängig davon, ob das Sprintziel erreicht wurde oder nicht, die alte Timebox ist für immer weg und eine neue Timebox für den nächsten Sprint ersetzt sie.
Es macht daher wenig Sinn, einem Sprint Codenamen oder Handles zu geben, da ein gegebener Sprint keinen Nutzen als historische Referenz haben sollte. Der Versuch, flüchtige Zeitfenster auf benannte Ereignisse abzubilden, ist normalerweise ein Projektgeruch, dass das Entwicklungsmodell nicht wirklich iterativ ist.
Obwohl jeder Sprint ein Sprint-Ziel und eine Reihe von Elementen aus dem Product Backlog hat, ist keines dieser Dinge unbedingt ein Projektmeilenstein. Ziele sind nicht immer einzigartige Elemente, und Geschichten werden manchmal für zukünftige Sprints wieder in das Product Backlog (modifiziert oder unverändert) eingefügt. Daher gibt es keine Garantie dafür, dass ein Sprint tatsächlich einzigartig ist.
Wenn beispielsweise Ihr aktueller Sprint sein Sprint-Ziel nicht erreicht und der Product Owner beschließt, einen weiteren Sprint mit demselben Ziel zu haben, würden Sie die Sprints gleich benennen? Wenn nicht, würde "Sprint Fuschia" nach "Sprint Aquamarine" wirklich jemandem etwas Nützliches über den Sprint, das Projekt oder das Team erzählen?
In der Datenbankwelt wird das Problem von (möglicherweise) nicht eindeutigen Zeilen im Allgemeinen gelöst, indem jeder Zeile automatisch inkrementierende Primärschlüssel zugewiesen werden. Dies ist ein Grund dafür, dass Scrum im Allgemeinen inkrementierte Ganzzahlen anstelle von Codenamen oder Handles zur Kennzeichnung von Sprints verwendet.
In Scrum lautet das Leitprinzip „Inspect and Adapt“. Während ein Projekt einen Zeitplan mit definierten Lieferterminen haben kann, wird erwartet, dass sich die Inhalte eines bestimmten Sprints im Laufe des Projekts ändern. Angesichts der Tatsache, dass die Ergebnisse eines Sprints die Inhalte nachfolgender Sprints beeinflussen, wäre es nicht sinnvoll, jedem Sprint im Projektplan im Voraus aussagekräftige Codenamen zuzuweisen, da sich das Ziel oder die Geschichten für den 23. Sprint bis zum Zeitpunkt des Teams ändern können schafft die ersten 22 Sprints aus dem Weg.
Alternativ, wenn Sie farbenfrohe, aber bedeutungslose Namen verwenden, welchen Mehrwert haben Sie hinzugefügt? Zumindest fortlaufende Namen geben Ihnen Sequenzinformationen; Wenn Sie Ihre Sprints nach Bäumen, gefährdeten Säugetieren oder Exoplaneten benennen, welche nützlichen Informationen vermittelt das eigentlich jemandem?
Da wir bereits festgestellt haben, dass Sprints vergänglich sind und keine historische Bedeutung haben (außer vielleicht als Geschwindigkeitsdatenpunkte), was möchten Sie vielleicht jemand anderem während Sprint Wallaby über Sprint Koala (der vor drei Sprints war) mitteilen? ? Wie wird sein Name, außer als abstrakter Bezugspunkt, der Kommunikation einen Mehrwert verleihen?
Wenn Sie nicht sowieso Sprintnamen auf eine Sequenz abbilden und wissen, dass Sprint Koala der 23. Sprint war und dass Sprint Wallaby wirklich der 26. ist, können Sie ohne zusätzliche kognitive Belastung nicht einmal Ordinal- oder Zeitinformationen übermitteln. Das scheint mir das Gegenteil von "benutzerfreundlich" zu sein.
Während der Name des Sprints selten nützlich ist, bieten die Anzahl der Sprints im aktuellen Projektplan oder der aktuelle Fortschritt des Teams entlang der Ordinalachse des Plans einen gewissen Nutzen. Beispielsweise kann ein Plan mit 25 zweiwöchigen Sprints auf 50 Wochen geschätzt werden. Ebenso ist es sehr wahrscheinlich, dass ein Projekt, bei dem weniger als 30 % des verbleibenden Product Backlogs abgeschlossen sind, nachdem 50 % der geplanten Iterationen verbraucht wurden, außerhalb der Toleranz liegt.
Ich weiß nicht, wie man eine Schar Gänse durch zwei Koalas und einen Lemur teilt, also bin ich mir ziemlich sicher, dass diese Art von Namen keinen Wert bei der Verwaltung von Projektmetriken oder sogar einfachen Prozentsätzen bietet. Im Gegensatz dazu bietet die Zuweisung von Ordnungszahlen als Labels einige nützliche mathematische Funktionen zur Überwachung und Kommunikation Ihres Projekts, selbst wenn die Inhalte vergangener und zukünftiger Sprints weder bekannt noch nachverfolgt sind.
Wenn Sie einen Sprint benennen möchten, stimme ich der akzeptierten Antwort im Programmers.stackexchange.com-Thread zu, dass Sie ihn nach dem Sprint-Ziel benennen sollten. Als Scrum Master fordere ich die Product Owner immer wieder auf, ein gut formuliertes Sprint-Ziel zu entwickeln. Ich beginne meine Sprint-Planungssitzungen immer damit, dass ich den Product Owner einlade, das Sprint-Ziel zu nennen.
Ein Sprintziel zu finden ist jedoch der schwierigere Teil. Hier sind einige Tipps von Roman Pichler, wie man ein Sprint-Ziel identifiziert. Sobald Sie das Sprint-Ziel identifiziert haben, können Sie versuchen, eine kürzere Version davon für den Sprint-Namen zu extrahieren.
Es gibt verschiedene Konventionen, die ich gesehen habe. Meiner Meinung nach ist es sogar völlig irrelevant, einen zu haben, abgesehen davon, dass Sie sich in Diskussionen darauf beziehen können (was gut sein kann oder auch nicht!).
Verwenden Sie eine „Sprint N“- oder „Iteration N“-Konvention:
Pro : Einfach zu erstellen
Con : Wird sich irgendjemand daran erinnern, was Sie in Iteration 23 getan haben? Es ist fast so, als würde man sie nicht benennen, da jeder Sprint bereits eine Ordnungszahl hat.
Bemerkenswertes Beispiel : Klammern
Verwenden Sie eine «Sprint of dd of mmm»-Vorlage:
Pro : Leicht generiert, für einige Leute hilft die Datumsverankerung ihnen, sich daran zu erinnern, in welchem Sprint etwas erledigt wurde
Con : Es ist fast so, als würden sie sie nicht benennen, da jeder Sprint bereits ein Startdatum hat
Bemerkenswertes Beispiel : Nein das ich mir vorstellen kann, aber es scheint ziemlich gebraucht zu sein
Geben Sie Sprints einen Namen basierend auf dem Ziel:
Pro : Macht es trivial, sich daran zu erinnern, wann etwas erledigt wurde
Con : Schwer zu generieren, schwer zu merken ( benennen Sie die ersten 20 Sprints auswendig )
Bemerkenswertes Beispiel : Nicht, dass mir etwas einfällt
Jede Kombination der oben genannten
Alles in allem hier mein bester Rat:
Siehe auch: https://softwareengineering.stackexchange.com/questions/82732/how-do-you-name-sprints-in-your-projects
Ich bin mir nicht sicher, wie es dazu kam, aber in meinen letzten beiden Unternehmen haben wir das folgende Sprint-Namensformat verwendet: Year+StartWeekNumber+Teamname . Daraus ergibt sich so etwas wie „ 2016W10 Team Blue “ für unseren aktuellen Sprint.
Aber in den letzten 7 Jahren, in denen ich Scrum gemacht habe, hatte ich nie das Bedürfnis, die Sprint-Nummern zu verwenden, nachdem der Sprint beendet war. Obwohl es manchmal praktisch sein kann zu sehen, in welchem Zeitraum ein Feature in Jira entwickelt wurde.
Anstatt einen Sprint zu benennen, würde ich ein klares Sprintziel definieren und den Namen des Sprints sehr einfach halten: http://wall-skills.com/2015/sprint-goal-focus-for-the-scrum-team/
Ich habe da eine etwas andere Meinung. Unser Team hat einen Ansatz entwickelt (Verzweigungsmodell, Organisationsstruktur, Gesamtansatz), der es uns ermöglicht, mehrere Sprints parallel auszuführen – dies ist besonders nützlich, um eine hohe Auslastung sicherzustellen, sodass niemand untätig sitzt und darauf wartet, dass die QA ihre Aufgabe erledigt.
Der Nachteil ist, dass wir zu jedem Zeitpunkt nicht wissen, welcher Sprint zuerst ausgeführt wird, daher ist eine datumsbasierte oder ordinale Benennung nutzlos.
Also haben wir uns für den „bunten, aber nichtssagenden“ Ansatz entschieden und unsere Sprints nach Monden im Sonnensystem benannt (davon gibt es ziemlich viele!). Die Namen selbst sagen nichts aus, aber es ist eine sehr nützliche Möglichkeit, über eine Sammlung von Funktionen, Verbesserungen und Korrekturen auf eine Weise zu sprechen, mit der sich alle Beteiligten identifizieren können. Ich widerspreche der Behauptung, dass Ihr Sprintname etwas bedeuten MUSS – in unserem Fall ist es einfach eine logische Gruppierung.
Wir haben mit diesem System über zwei Jahre lang gearbeitet, über etwa fünfzig Punkt-Releases, und es funktioniert sehr, sehr gut.
Zum Beispiel haben wir derzeit die Sprints „Phoebe“ und „Ceres“ in der Entwicklung – der Projektplan sieht vor, dass Phoebe das nächste Point-Release (1.80.0) wird, aber es gibt keine Garantien, und wir bleiben agil genug, um die geplante Reihenfolge zu ändern von Releases, mit minimalen Auswirkungen auf die Lieferung. Daher können wir Probleme mit Phoebe im QA-Zyklus finden, der es verzögert, und Ceres wird als 1.80.0 herauskommen, und Phoebe wird (wahrscheinlich!) 1.81.0 werden.
Um CodeGnome ein wenig zu wiederholen, würde ich auch sagen, dass die Benennung von Sprints eine schlechte Idee ist. Sie sind vergänglich. Wenn ein Sprint abgeschlossen ist, möchten Sie vielleicht die abgeschlossenen Stories in einem Datensatz sammeln, um sie später bei der Vervollständigung der Benutzerdokumentation zu verwenden, aber abgesehen davon bringt es nichts, sich an einen bestimmten Sprint zu erinnern, und eine Benennung würde ihnen zu viel Bedeutung verleihen.
Was möglicherweise effektiver funktioniert und ein besserer Fokus für Ihr Team ist, besteht darin, sich die Ziele des Releases anzusehen, zu dem der Sprint gehört, und diese Ziele im Auge zu behalten. Einen Release-Namen zu haben, ist eine altehrwürdige Tradition seit der Zeit vor agilen Methoden. Es verzichtet darauf, die Geschichten eines Sprints mit irgendeiner Bedeutung zu verknüpfen, betont jedoch, dass alle Geschichten im Backlog für die Veröffentlichung notwendig sind, bevor der Sieg erklärt wird.
Der Name des Sprints hat keinen Einfluss oder Unterschied in Ihrem Prozess. Es werden jedoch Benutzernummern wie Sprint 1, Sprint 2 usw. empfohlen, da dies die Nachverfolgung erleichtert.
Bei einem großen Projekt haben Sie möglicherweise 30,40 Sprints. In diesem Fall wird es schwierig sein, das Projekt zu identifizieren, wenn Sie einige ausgefallene Namen angeben. Daher ist es besser, es mit Zahlen zu benennen (Sprint 1, Sprint 2 usw.).
Obwohl es auf diese Frage keine richtige oder falsche Antwort gibt, fand ich es nützlich, den letzten Tag des Sprints als eindeutigen Bezeichner für den Sprintnamen zu verwenden.
Wenn beispielsweise ein Sprint am 28.03.2016 endet, würde ich den Sprint folgendermaßen benennen: Sprint 20160328
Ich habe festgestellt, dass dies sehr gut funktioniert, um: (1) dem Sprint einen Namen zu geben, der nützliche Informationen über den Sprint liefert, und nicht irgendeine willkürliche Zahl (2) die Verwendung eines Datums stellt die Eindeutigkeit im Kontext eines einzelnen Projekts sicher
Hinweis: Ich trainiere niemals die Einbettung von Elementen des Programm- oder Projektnamens in den Sprint-Namen selbst. Topologisch gesehen ist es sauberer, das Projekt und/oder Programm auf einer Ebene weit über der Bezeichnung des Arbeitszeitfelds existieren zu lassen.
Wenn Ihr Projekt in Meilensteine unterteilt ist (1,2 ...5), können Sie die Sprints innerhalb jedes Meilensteins so benennen, dass sie dem Meilenstein entsprechen, an dem Sie arbeiten, und der Anzahl der Sprints in diesem Meilenstein.
Wenn Sie beispielsweise an Meilenstein 1 arbeiten, können Ihre Sprints Sprint 1.1 genannt werden; Sprint 1.2; für Meilenstein 2 – Sprint 2.1; Sprint 2.2
Auf diese Weise haben Sie einen Bezugspunkt zu einem Meilenstein und einer ausgeführten Funktionalität.
Ich rate, sich nicht über solche kleinen Details zu ärgern. Die Idee von SCRUM ist es , Verschwendung zu reduzieren und agil zu sein . Finden Sie einen einfacheren Weg und bleiben Sie dabei. Damit ich mir keine Gedanken über die Namensgebung machen muss, verwende ich folgendes Format.
Sprint X - Von bis Bis
wo
Ich verwende "Sprint N: Sprint Goal" und starte die Zählung nach jeder Veröffentlichung neu.
In der Praxis verwenden wir oft nur die Zahl, aber die Zahl + Ziel ist hilfreich, wenn Sie über einen längeren Zeitraum berichten oder auf die letzten Monate zurückblicken, um zu sehen, wo wir unsere Anstrengungen bei der Priorisierung für zukünftige Sprints gesteckt haben.
Wir haben gerade einen neuen Sprint-Benennungstyp gestartet, der wie „YYYY-QX-X/6“ aussieht.
2018-Q4-5/6.
Wir setzen uns vierteljährliche Teamziele. Diese Art der Benennung fühlt sich wie eine Frist an.
Ich arbeite mit verschiedenen Teams und wir haben parallele Sprints für verschiedene Apps. Es wurde wirklich schwierig, mehrere Sprints mit unterschiedlichen Nummern zu unterscheiden.
Also haben wir die folgende Struktur in unsere Sprint-Namen implementiert:
< Sprint > < Jahr > < Monat > < (Version) >
Die „(Version)“ ist optional, denn selbst wenn wir monatliche Sprints durchführen, machen wir alle 3 Monate ein Release. In diesem Fall könnten 3 Sprints zu einem Release gehören.
Wenn es hilfreich wäre, könnten Sie auch das Sprintziel oder den Produktnamen verwenden . Ich verwende weder das Ziel noch den Produktnamen, weil meine Sprints zu einem Produkt gehören und das bereits im System abgebildet ist.
Ich denke, ein "allgemeiner Name" in Klammern hinter dem nicht einprägsamen Zahlensystem, das Sie verwenden, ist in Ordnung und vorteilhaft, wenn nicht sogar lustig. Sie könnten sogar mit der Zahl korrelieren. vor: 2021W31 nach: 2021W31 (Reggie)
Benennen Sie die Sprints in Scrum nicht, es ist sinnlos!
Was ist der Wert dabei? NONE Wird es im Scrum-Leitfaden empfohlen oder eher vorgeschlagen? NEIN Ist es Teil eines Artefakts? NEIN
Sprints haben Namen, weil verdammtes Jira diese Funktionalität hinzugefügt hat, aber um Verwirrung zu vermeiden, muss der Sprintname automatisch generiert werden, 1, 2, 3 usw.
Die wichtigen Informationen über den Sprint sind bereits Teil davon und wenn er fertig ist, bleiben diese Informationen bestehen, wie das Ziel, die Länge, das Startdatum, das Enddatum usw.
Wenn ich einen Sprint finden möchte, würde ich es entweder nach Startdatum oder Ziel tun. Letztendlich können wir eine Aufgabe überprüfen, deren Sprint uns interessiert, und das Feld Sprints (in Jira) überprüfen, und Sie können es finden ...
Weder der Product Owner, der Scrum Master noch die Entwickler, irgendjemand kümmert sich um den Namen des Sprints ... NUR JIRA MACHT ES!
Bijay Rungta
Tiago Cardoso
Geoff Burns