Geschichten, die nach der Zusage hinzugefügt wurden

Ich versuche, das folgende Problem zu verstehen: Innerhalb eines SAFe-Frameworks fügt ein Entwicklungsteam User Stories nach einer Zusage hinzu, obwohl diese Zusage nicht erfüllt wurde. Die Begründung lautet, dass die größeren Epics/Features gefährdet sind, wenn diese neuen User Stories nicht fertiggestellt werden.

Als Nebenbemerkung verbringt dieses Team übermäßig viel Zeit mit der Planung während der Iterationsplanung.

Meine Frage ist: Sollten diese neuen User Stories als Aufgaben gezählt werden?

Meine Verwirrung dreht sich um das Prinzip "gerade genug, um zu beginnen" während der Iterationsplanung. Wie in jeder Geschichte sollten gerade genug Informationen vorhanden sein, damit die Teammitglieder mit der Arbeit beginnen können. Wenn im Laufe der Zusammenarbeit neue Abhängigkeiten oder Arbeiten aufgedeckt werden, stellt das eine neue User Story dar?

Mein Gedanke ist , dass diese als Aufgaben aufgelistet werden sollten, und wenn es Unklarheiten gibt, sollte dies bei der Schätzung berücksichtigt werden.

Alle Gedanken, Erkenntnisse oder Rückmeldungen sind willkommen.

„Wenn diese neuen User Stories nicht fertiggestellt werden, werden die größeren Epics/Features gefährdet“ – Können Sie das näher erläutern? Ich bin mit SAFe nicht genau vertraut, aber ist eine Iterationsverpflichtung nicht normalerweise darauf ausgerichtet, eine Reihe von Geschichten zu liefern, kein Epic oder Feature, was bedeutet, dass ein Epic von Features über mehrere Iterationen hinweg geliefert wird? Wenn nicht festgestellt wird, dass diese vor einer geplanten Geschichte erledigt werden müssen, verstehe ich das Problem nicht.
Und wenn Sie Arbeiten auf User-Story-Ebene entdecken, scheint es, als wäre nicht genügend Zeit für die Verfeinerung des Backlogs aufgewendet worden.
@ThomasOwens Vielen Dank für die Antwort! In Bezug auf Ihren ersten Kommentar: Für jede Iteration / jeden Sprint soll eine Reihe von Geschichten geliefert werden, zu denen sich das Team verpflichtet hat. Wir haben jedoch sechs Iterationen pro Inkrement, und jedes Inkrement hat Funktionen, die bereitgestellt werden müssen. (Agilität auf Programmebene) Wenn also die neuen User Stories nicht fertiggestellt werden, ist die größere Inkrementfunktion (die voraussichtlich in einer zukünftigen Iteration fertiggestellt wird) gefährdet. Hilft das?
@ThomasOwens Zu Ihrem zweiten Punkt: Können Sie das näher erläutern? Da das Team viel Zeit mit dem Unkraut jeder Geschichte verbringt, besteht das Coaching darin, jede Geschichte ausreichend zu diskutieren, um mit der Arbeit daran zu beginnen.
Ich finde deine Terminologie verwirrend. Jede Iteration sollte ein potenziell lieferbares Inkrement produzieren. Möglicherweise müssen Sie das Inkrement tatsächlich nur alle 6 Iterationen bereitstellen (und es gibt eine Reihe guter Gründe, Ihre Software nicht am Ende jeder Iteration tatsächlich bereitzustellen oder freizugeben). Die Tatsache, dass Sie User Stories entdecken und nicht nur Aufgaben, ist beunruhigend.
@ThomasOwens Ich stimme zu, dass es beunruhigend ist, und deshalb suche ich Hilfe von dieser Community. Was wir liefern, nennen wir nicht Inkremente, wir nennen diese Verpflichtungen, Produkte oder Ziele für jede Iteration.
Wer fügt die Geschichten hinzu? So wie es sich anhört, hat jemand entschieden, dass die Geschwindigkeit nicht schnell genug ist und dass das Entwicklungsteam nicht genügend Arbeit geleistet hat, um die festgelegte Arbeit in der festgelegten Zeit abzuschließen, die jemand berücksichtigt hat. Darin sehen Sie sicherlich das Problem.
S_Fe (weil es nicht agil ist)

Antworten (1)

Ihre Frage ist eigentlich ziemlich weit gefasst und berührt eine Reihe von Problemen, aber das Gute ist, dass alles auf die eine oder andere Weise mit Rückstandselementen zusammenhängt.

Ich versuche, das folgende Problem zu verstehen: Innerhalb eines SAFe-Frameworks fügt ein Entwicklungsteam User Stories nach einer Zusage hinzu, obwohl diese Zusage nicht erfüllt wurde. Die Begründung lautet, dass die größeren Epics/Features gefährdet sind, wenn diese neuen User Stories nicht fertiggestellt werden.

Unabhängig vom Framework sollten User Stories immer priorisiert und von der Produktperson/dem Team basierend auf der Geschäftspriorität ausgewählt werden. User Stories sind breit gefächert und haben idealerweise INVEST- Eigenschaften. Allerdings kann das Entwicklungsteam während des Planungsmeetings durchaus Einfluss auf die Produkt-/Geschäftsperson(en) nehmen, um aus technischen Gründen einige Anforderungen mit niedriger Priorität auszuwählen. Die Frage ist also, warum hat das Entwicklungsteam diese „größere Epic“-bezogene Argumentation während des Planungsmeetings nicht angesprochen?

Beachten Sie jedoch, dass es dem Entwicklungsteam freisteht, eigene technische Aufgaben hinzuzufügen, zu entfernen und zu bearbeiten, um das Ziel der Iteration zu erreichen. Außerdem ist es normal, dass das Team während der Iteration mit den Produktmitarbeitern verhandelt, um Änderungen an den Stories vorzunehmen. Meiner Meinung nach stimmt jedoch etwas mit Ihren Planungstreffen nicht, wenn dies häufig vorkommt und mehr als eine Handvoll Geschichten betrifft.

Als Nebenbemerkung verbringt dieses Team übermäßig viel Zeit mit der Planung während der Iterationsplanung.

Sie sollten sicherstellen , dass die Produktverfeinerung abgeschlossen ist, und mit einem bul****-Summer oder einfach einem Timer wie dem folgenden experimentieren, indem Sie ihn auf die große Leinwand stellen: http://oss.jahed.io/agility/timer.html

Meine Frage ist: Sollten diese neuen User Stories als Aufgaben gezählt werden?

User Storys unterscheiden sich von Aufgaben. Wie oben erwähnt, werden User Stories von oder mit den Produktleuten geschrieben. Aufgaben sind detaillierte Aktivitäten, die abgeschlossen werden müssen, um eine bestimmte User Story abzuschließen. Aufgaben werden im Allgemeinen von oder mit den Entwicklern geschrieben. Sie sind sogar in verschiedenen Formaten und Stilen geschrieben. Sie können User Stories und Tasks nennen, wie Sie wollen, solange Sie den Unterschied verstehen (aber im Ernst, lassen Sie sich keine neuen Namen für Backlog-Elemente einfallen).

Meine Verwirrung dreht sich um das Prinzip "gerade genug, um zu beginnen" während der Iterationsplanung. Wie in jeder Geschichte sollten gerade genug Informationen vorhanden sein, damit die Teammitglieder mit der Arbeit beginnen können. Wenn im Laufe der Zusammenarbeit neue Abhängigkeiten oder Arbeiten aufgedeckt werden, stellt das eine neue User Story dar?

Gerade genug oder entstehende Arbeit sind wichtige agile Konzepte, die Verschwendung minimieren und die Konzentration eines Teams darauf erhöhen, die wertvollsten Elemente zuerst zu liefern. Das heißt aber nicht, dass die Entwickler ohne detaillierten Plan loslegen. Lesen Sie neben der Backlog-Verfeinerung auch etwas über die Definition of Ready (DoR). Die Grundidee ist, dass die Backlog-Elemente, die die Produktperson(en) während der nächsten Iteration erledigen möchten, detailliert genug sind und die vom Team vereinbarte DoR erfüllen. Bedenken Sie jedoch, dass das Team während des Planungsmeetings nicht jede einzelne User Story zerlegen kann. Sie sollten genug Geschichten für die ersten paar Tage zerlegen. Der Rest der User Storys wird im Verlauf des Sprints regelmäßig zerlegt. Stellen Sie sicher, dass die zweitwichtigsten User Stories bereits zerlegt und zur Implementierung bereit sind, bevor die aktuellen User Stories abgeschlossen sind. Stellen Sie sich Mini-Planungsmeetings vor, die je nach Iterationslänge fast täglich stattfinden.

vielen Dank für Ihr Feedback und Ihren Einblick. Du hast mir viel zu denken gegeben. Ich stimme zu, dass wir unsere DOR überprüfen müssen, und ein Timer wird helfen (erst gestern implementiert). Außerdem ist unsere Iterationsplanung definitiv verbesserungswürdig. Haben Sie Vorschläge zu Bereichen, die Sie mit dem Team untersuchen sollten, oder zu Tools, die Ihnen in der Vergangenheit geholfen haben (ich kenne A3 RCPS-Tools)?
Vielen Dank. Freut mich, dass es hilfreich war. Für neue Teams verwende ich im Allgemeinen die 12 agilen Prinzipien als Selbsteinschätzung/Metriken, und wir als Team würden sehen, wie wir in Retrospektiven zu 100 % gegen diese zwölf Prinzipien vorgehen. Bei erfahreneren Teams erfolgt eine ähnliche Selbstreflexion mit benutzerdefinierten Metriken. Abgesehen davon verwende ich zahlreiche Spiele oder Coaching-Techniken, um Problembereiche zu verbessern. Leider ist Agilität keine harte Wissenschaft und man lernt viel durch Erfahrung. Gute Mentoren zu haben und ständig zu lesen hilft.
Geschichten, die nach der Zusage hinzugefügt wurden
AntwortenHierDatenschutz-Bestimmungen1y, 0v