Wir arbeiten in einem agilen Scrum-Team. Sie erwähnen, dass es sich bewährt hat, PBI-Aufgaben zuerst nach Sprint Backlog Priority in der Codeentwicklung zu bearbeiten.
Manchmal,
Welche Regeln gelten für die Arbeit an Sprint Story PBIs in der Reihenfolge? Ist es eine feste Regel oder kann sie angepasst werden? Offensichtlich haben vorrangige PBI-Elemente die größte Bedeutung, aber können die Dinge während des Zeitplans berücksichtigt werden?
Im Gegensatz zum Product Backlog, das eine „geordnete Liste dessen ist, was zur Verbesserung des Produkts benötigt wird“, gibt der Scrum Guide nicht an, ob das Sprint Backlog geordnet ist oder, wenn ja, wie es geordnet ist. Stattdessen beschreibt es das Sprint Backlog als einen „Plan von und für die Entwickler“ und ein „gut sichtbares Echtzeitbild der Arbeit, die die Entwickler während des Sprints zu erledigen planen, um das Sprintziel zu erreichen“.
Da das Sprint Backlog von und für die Entwickler erstellt und gepflegt wird, können die Entwickler wählen, ob und wie sie es bestellen möchten.
Bei der Auswahl der Arbeit müssen die Entwickler viele Dinge berücksichtigen. Vielleicht ist es besser, früh im Sprint etwas schnelle Arbeit zu erledigen. Ein anderer Ansatz besteht darin, zuerst die riskanteste Arbeit zu übernehmen, damit potenzielle Probleme frühzeitig auftreten können. Ein weiterer Ansatz besteht darin, die wichtigste Arbeit zu übernehmen. Unabhängig von der Reihenfolge sollten die Entwickler das Sprint-Ziel berücksichtigen, wenn sie auswählen, woran sie arbeiten möchten. Die höchste Priorität des Teams für den Sprint ist das Erreichen des Sprintziels.
Welche Regeln gelten für die Arbeit an Sprint Story PBIs in der Reihenfolge?
Da sind keine.
All die Dinge, die Sie erwähnen, sind vernünftige Gründe, warum Sie möglicherweise nicht in der strengen Prioritätsreihenfolge vorgehen.
Vielleicht möchten Sie jedoch einige dieser Gründe in Ihren Rückblicken besprechen. Ist es möglich, dass Sie diese Ausnahmen seltener machen können, indem Sie den Ansatz des Teams ändern?
Sie erwähnen, dass es sich bewährt hat, PBI-Aufgaben zuerst nach Sprint Backlog Priority in der Codeentwicklung zu bearbeiten.
Es gibt keine Sprint-Backlog-Priorität. Also nein, das ist keine Best Practice.
Allerdings gibt es ein Sprintziel . Dies ist der Fokus des Sprints. Und als solche sollten Sie wahrscheinlich an einer PBI arbeiten, die notwendig ist, um dieses Ziel zu erreichen. Wenn Sie dies nicht tun, konzentrieren Sie sich nicht auf das Richtige.
Die Reihenfolge, in der PBIs bearbeitet werden, liegt jedoch beim Entwicklungsteam, sodass Sie dies in der Retrospektive für eine abstraktere Richtlinie vorbringen oder es schnell im täglichen Stand-up besprechen können, wenn Sie eine neue Aufgabe ziehen des Tages, in dieser speziellen Situation.
Das Team sollte nur die Dinge in einen Sprint aufnehmen, von denen es glaubt, dass sie bis zum Ende des Sprints erledigt werden können. Dies sind im Allgemeinen Elemente mit hoher Priorität im Product Backlog. Da erwartet wird, dass am Ende des Sprints alles fertig ist, sollte es keine Notwendigkeit geben, innerhalb eines Sprints Prioritäten zu setzen, außer vielleicht, wenn es Risiken oder Abhängigkeiten gibt, die es ratsam machen, Dinge eher früher als später zu erledigen. Das Team kann selbst entscheiden, ob etwas priorisiert werden muss.
Wenn Teams ein Pull-System einführen, kann es eine Konvention darüber geben, welche Gegenstände als nächstes abgeholt werden sollen. Solche Konventionen sind oft informell und subjektiv, da einige Teammitglieder sich vielleicht besser in der Lage fühlen, an einigen Punkten zu arbeiten als andere.
Sie erwähnen, dass es sich bewährt hat, PBI-Aufgaben zuerst nach Sprint Backlog Priority in der Codeentwicklung zu bearbeiten.
Das Sprint-Backlog ist eine Teilmenge des Produkt-Backlogs, die vom Team während der Sprint-Planungssitzung auf der Grundlage der vom Product Owner festgelegten Prioritäten erfasst wird – dessen Aufgabe es ist, sicherzustellen, dass das Team an den PBIs arbeitet, die als den größten Mehrwert erachtet werden.
Wenn einige der ersten Prioritätsgeschichten schwierig sind und ich Zeit zum Nachdenken/Pause brauche (geistig wechsle ich gerne zwischen schwierigen und einfachen Geschichtenaufgaben, wenn ich feststecke), macht es meinem Kopf leichter, ich kann zurückkommen und mit frischen Gedanken an der Geschichte arbeiten
Hier scheinen Sie Multitasking zu planen, und im Allgemeinen ist Multitasking, das speziell für mehr als 2 Aufgaben ausgeführt wird, wissenschaftlich erwiesenermaßen weniger effizient. Wenn Sie wirklich mehrere Aufgaben bewältigen können und mit "frischem" Geist - viel Glück und gehen Sie weiter und versuchen Sie es! Ich glaube nicht, dass Scrum hier strenge Empfehlungen hat
Welche Regeln gelten für die Arbeit an Sprint Story PBIs in der Reihenfolge?
Wie bereits von anderen erwähnt, erlegt Scrum selbst keine eigenen Regeln auf. Das Sprint-Backlog „gehört“ dem Team – es ist seine Verpflichtung und daher können Sie und andere Leute in einem Team die Reihenfolge bestimmen, in der diese PBIs sequenziert und entwickelt werden – was am besten zu Ihrem Arbeitsstil als Team passt. Da das selbstorganisierte Team die "Verpflichtung" zur Lieferung des Sprint-Backlogs gemacht hat, werden die restlichen Leute im Team (SM und PO und andere wichtige Stakeholder) "vertrauen", dass die Dinge erledigt werden
Offensichtlich haben vorrangige PBI-Elemente die größte Bedeutung, aber können die Dinge während des Zeitplans berücksichtigt werden?
„Zeitplan“ ist Ihre Sprint-Dauer (die in der Regel 1–4 Wochen beträgt) und während der Sprint-Planung haben sich das PO- und Entwicklungsteam darauf „geeinigt“, welche Priorität PBIs für diesen Sprint haben. Solange also die „engagierte“ Arbeit vom Team geliefert wird, ist das Sprintziel erreicht.
Was meinst du mit "Hard User Stories"? Größer oder komplexer als üblich?
Wir haben hier zwei Backlogs: Das erste sind PBIs, während das zweite Sprint Backlog Items ist. Zunächst sollten PBIs nach Geschäftspriorität angeordnet und geordnet werden. Ich denke, hier müssen Sie sich zu den Endbenutzerprioritäten verpflichten, wie in PBIs beschrieben, wo jede PBI eine Benutzerfunktion sein sollte; Diese Funktion kann User Story oder Epic sein.
Bevor Sie einige Elemente von PBIs in Sprint Backlog Items verschieben, müssen Sie jede PBI analysieren und verstehen. Hier können Sie genau abschätzen, wie schwer dieser Gegenstand ist und wie viel Zeit er benötigt, um ihn zu erledigen.
Es kann eine schwierige Aufgabe sein, jede Benutzerfunktion einem Element in PBIs zuzuordnen, aber wenn Sie diese Funktionen verstehen, werden Sie in der Lage sein, die Elemente zu bestimmen, die von PBIs in Sprint-Backlog-Elemente verschoben werden müssen, und dies hängt auch von der Sprintlänge ab.
Es gibt keine Regel, wie Sie mit der Implementierung der Sprint Backlog Items beginnen. Auf jeden Fall müssen Sie Ihren Sprint mit DONE-Elementen beenden. Sie und Ihr Team wählen die Reihenfolge nach mehr Dingen wie der Implementierungslogik aus.
Betrachten Sie den Sprint als einen einzelnen Meilenstein und teilen Sie ihn mit Ihrem Team in verwandte Aufgaben auf. Der Endbenutzer kümmert sich nicht um die Härte der Geschichte, noch können Sie mit Ihren Bemühungen auf andere Weise an die Dinge denken.
Versuchen Sie, den Gegenstand nicht durch schwer oder leicht zu messen. Sie müssen den Sprint als Ganzes betrachten, da der Sprint Elemente enthält, die leicht oder schwierig sein können, aber dennoch in einen Sprint passen müssen, und dies hängt von einer genauen Planung und Schätzung ab.
Ich bin ein wenig ratlos über diese Situation.
In meiner Organisation kommt eine Story erst in das Sprint Backlog, wenn sie bereits geschrieben ist und alle Akzeptanzkriterien überprüft und freigegeben wurden. Also arbeite ich immer an den PBI-Elementen und bereite sie für den nächsten Sprint vor. Normalerweise bin ich mindestens einen Sprint voraus; So haben wir dieses Problem nie.
Hoffentlich hilft das!
MCW