Wie geht man mit User Stories um, die nicht aufgeteilt werden können und nicht einmal in einen 30-tägigen Sprint passen?

  1. Bei einem kleinen Team (ca. 3 Personen) und einem technisch anspruchsvollen Bereich (zB Middleware, Embedded Software etc.) und
  2. Unter der Annahme, dass eine User Story das kleinste Ding ist, das für den Endbenutzer einen Wert hat ,

Wie gehen Sie mit Stories um, die mehr als einen Monat brauchen, um den DONE-DONE-Zustand zu erreichen? Natürlich könnte man sie immer in mehrere sogenannte „technische Geschichten“ aufteilen, aber sie sind, mit Ausnahme von Refactoring-Spikes, ein großes No-Go in Agile, oder?

Ich denke, diese Antwort ist eine gute Antwort auf Ihre Frage, auch wenn es nicht genau dasselbe Szenario ist: pm.stackexchange.com/a/23372/29374

Antworten (7)

Tue zuerst Dinge, die Sinn machen. Wenn es sinnvoll ist, die große Geschichte in einige kleinere aufzuteilen, auch wenn Sie diese Teile nicht separat an Ihren Kunden liefern können, warum sollten Sie es nicht tun? Sie werden nicht dafür bezahlt, perfekt auf das eingestellt zu sein, was einige Vordenker sagen.

Zweitens, wenn die Situation eher eine Ausnahme ist, behandeln Sie sie wie eine. Wenn Sie die Geschichte nicht in kleinere Stücke aufteilen möchten, können Sie eine Geschichte auf ein paar Iterationen verschieben und vereinbaren, dass sie dieses Mal einfach so aussehen wird.

Drittens, wenn die Situation eher üblich ist, überlegen Sie, wie Sie den Prozess, dem Sie folgen, so anpassen können, dass solche Geschichten tatsächlich möglich sind . Eine Sache, die mir in den Sinn kommt, ist Kanban, wo man komplett auf Iterationen verzichtet und sich mit einer XXL-Story auseinandersetzen und gleichzeitig viele kleinere bauen kann, da man die Arbeit nicht zeitlich begrenzt, sondern eine Anzahl von gleichzeitigen Aufgaben. In diesem Fall würde eine große Geschichte nur einen Slot beanspruchen, aber sie würde ihn für eine längere Zeit verwenden.

Viertens: Seien Sie nicht orthodox, wenn es darum geht, einem Kunden einen Mehrwert zu bieten . Wenn Sie etwas Haushalt in der Architektur machen wollten und müssten, das Ihren Kunden genau 0 Wert bringt, aber Ihnen hilft, die Wartungskosten zu begrenzen, würden Sie eine solche Aufgabe ablehnen? Wahrscheinlich nein. Und doch würdest du es irgendwie in deinen Rückstand packen.

Schließlich geht es bei Agilität um Flexibilität, um auf Veränderungen zu reagieren und nicht darum, Regeln um jeden Preis einzuhalten, richtig?

Ich liebe den Kommentar „Du wirst nicht dafür bezahlt, perfekt auf das eingestellt zu sein, was einige Vordenker sagen“.
Eine Sache, die mich immer wieder zum Nachdenken bringt – bringt Refactoring nicht auch langfristig einen Mehrwert für den Kunden? Besonders wenn es die Wartung reduziert hat, muss es "etwas" geändert haben - entweder es Ihnen ermöglichen, in Zukunft mehr Artikel zu liefern (ein Kunde +) oder die Anzahl und / oder Kritikalität von Fehlern zu verringern (ebenfalls ein Kunde +) - also ist es vielleicht nicht so schlimm, wie wir manchmal denken? :)
Nun, das tut es wahrscheinlich. Zumindest solange es gut gemacht ist. Es ist jedoch schwierig, eine direkte Linie zwischen dem Refactoring eines Codestücks und dem Gewinn des Kunden zu ziehen. Außerdem bezweifle ich, dass viele Kunden für "Refaktorisierungsfunktion" bezahlen würden :)
"Wenn Sie etwas Haushalt in der Architektur machen wollten und müssten, das Ihren Kunden genau 0 Wert bringt, aber Ihnen hilft, die Wartungskosten zu begrenzen, würden Sie eine solche Aufgabe ablehnen? Wahrscheinlich nein" ==> Ich liebe das, aber wie vertreten Sie das als user story? Ich habe an vielen Stellen gelesen, dass nicht-funktionale Anforderungen/technische Geschichten ein großes Nono in Agile sind. Ich kämpfe damit und möchte nicht in die Falle "als Entwickler brauche ich ..." tappen

Das Festhalten an User Stories als kleinste Planungseinheit ist einer der abscheulichen Fehler der Agilisten.

Was ist die User Story für eine Brücke? Wo wird die Konstruktion von Pfeilern, Spannweiten, Unterzügen etc. berücksichtigt, die die Unterkonstruktion bilden? Der Bau des Decks (Fahrbahn) ist (relativ gesehen) von so geringer Bedeutung, dass er in dieser Erzählung nicht einmal detailliert beschrieben wird.

Wie viele User Stories für ein Haus betreffen das Fundament und das Dach? Dabei sind sie die teuersten Teile eines Gebäudes.

User Stories sind ein grundlegendes Werkzeug für die Definition des Umfangs und die Zielsetzung des Projekts, aber sie sind nicht das einzige Werkzeug, das verwendet werden kann. Sie helfen, den Zweck eines Projekts zu definieren und wann es abgeschlossen ist. Sie liefern nicht den gesamten Umfang des Aufwands. Sie helfen, den Planungsprozess zu beginnen. Sie sind nicht der endgültige Plan.

Ich hasse die Bridge-Analogie wirklich. Sie können nicht wirklich eine Teilmenge einer Brücke auf die gleiche Weise veröffentlichen, wie wir es in der Software können.
Ich glaube nicht, dass Stories als kleinste Planungseinheit etwas auszusetzen haben. Wir haben nur größere Geschichten in der Ferne und immer kleinere Geschichten, je näher wir dem aktuellen Datum kommen.
Nein, Sie können keine Teilmenge einer User Story freigeben. Das ist mein Punkt. Wenn die Infrastruktur zur Aktivierung einiger Funktionen nicht vorhanden ist, muss sie entwickelt werden. Eine User Story kapselt den Wert, der dem Benutzer/PO bereitgestellt wird. Wenn die User Story auf eine Karte passt, aber die Entwicklung, die zu ihrer Implementierung erforderlich ist, mehr als eine Karte erfordert (z. B. der 30-Tage-Sprint, wie er vom OP vorgegeben wird), dann sind User Storys für die Planung/Zeitplanung unzureichend.
Aber Sie können Benutzergeschichten über den kleinsten Wert für den Kunden hinaus aufschlüsseln. Tatsächlich habe ich in den letzten 6 Monaten an einem Projekt gearbeitet, bei dem es darum geht, dass Kunden keinen Unterschied bemerken (Plattformmigration). Ich könnte eine User Story dürftig mit dem Wert formulieren, zukünftige Änderungen schneller vorzunehmen, aber das würde nicht erreicht werden, bis das gesamte Projekt abgeschlossen ist (tatsächlich erschweren wir während der Migration die Arbeit an unserer Plattform).
Unsere Geschichten konzentrieren sich dann nicht auf den Wert für den Kunden oder gar für das Unternehmen, sondern sind testbare Schritte, die uns unserem Ziel näher bringen. Das ist es, worüber Pawel in seiner Antwort spricht (seien Sie nicht orthodox, wenn es darum geht, einem Kunden einen Mehrwert zu bieten).
Alles, was für den Kunden kleiner als der Wert ist, ist keine User Story , und das ist der Punkt. Nennen Sie es eine Entwicklergeschichte. Aber das OP hat, wie viele Agilisten, versucht, alles in die User Story zu stecken, denn das ist es, was Agilisten gerne verwenden, um die Entwicklung agil zu halten . Wenn Sie es weiter zerlegen, besteht die Gefahr, dass ein BDUF entsteht. Aber ziemlich oft ist es eine Notwendigkeit, es zu brechen. Beschränken Sie daher weder die Entwicklungsplanung noch agile Schlagworte auf User Stories .
Entschuldigung, wenn ich das falsch verstehe, aber es hört sich so an, als ob Sie in Bezug auf die Nomclemature ziemlich pedantisch sind. Daran arbeiten wir; Ob wir das dann User Stories, Work Items oder Fish Cakes nennen, ist mir eigentlich egal. Im Idealfall möchte ich, dass meine Geschichten einen direkten Kundennutzen haben; Diese Richtlinie zu brechen, hört nicht auf, eine Geschichte zu sein.
Wenn Sie denken, dass ich bei der Nomenklatur pedantisch bin, was könnten Sie dann über Agilisten denken, die darauf bestehen, dass User Stories in Sprints passen müssen? Und warum debattieren Sie weiter über die Nomenklatur, wenn es keine Rolle spielt? Es ist zwar schön, dass Sie pragmatischer in Bezug auf Prozesse und nicht so streng in Bezug auf Terminologie sind, aber nicht alle sind auf derselben Seite. Viele agile Promotoren sind auf „Kundenwert“-Dogmen fixiert, ohne die architektonischen Grundlagen zu berücksichtigen, was Konvertiten verwirrt. Daher die Frage des OP.

Wenn Sie die Geschichte wirklich nicht in wertvolle Stücke aufteilen können, würde ich mit "kleinster testbarer Komponente" gehen, um sie aufzuteilen.

Können Sie ein Beispiel für eine Geschichte nennen?

Ich muss aus NDA-Gründen ziemlich allgemein sein, also wäre ein Beispiel: „Kalibrieren eines Sensors eines medizinischen Geräts durch Einstellen einer Reihe von Parametern. Parameter sind voneinander abhängig, sodass die Implementierung einer Unterstützung für nur einen Parameter am Ende keinen Wert liefert Benutzer." Implementierungsbeschränkungen: C++ als Sprache, eingebettete Umgebung und die Notwendigkeit, mit einem bereits entwickelten Framework umzugehen, das aufgrund der Kosten für erneute Tests, die durch die Einhaltung geltender Vorschriften entstehen, praktisch nicht geändert werden kann. Was wiederum zu zusätzlichem Aufwand bei der Suche nach Problemumgehungen führt.
Ich mag jedoch die Idee der "kleinsten testbaren Komponente".
Ich verwende „etwas, das klein genug ist, um schnell Feedback zu erhalten“, da wir hauptsächlich deshalb überhaupt agil arbeiten. Wenn ein Team produktiv genug ist, um ein ganzes Feature in einem Sprint zu produzieren – oder zwischen den Verfügbarkeiten relevanter Stakeholder, um Feedback zu geben, mit welcher Kadenz das auch immer ist – dann empfehle ich nicht, die Geschichte aufzuteilen.

Tolle Antwort von Pawel. Einige andere Dinge zu beachten:

Fertig sollte aus der Perspektive sein, an wen die Geschichte geliefert wird. Dies ist nicht immer der Endverbraucher.

Es gibt einen Unterschied zwischen potenziell lieferbar und lieferbar. Die Arbeit, die wir tun, versuchen wir, die Funktionen vollständig zu sein, obwohl sie möglicherweise nicht vollständig sind.

Alle Geschichten können aufgeschlüsselt werden. Bei der Planung ist dies theoretisch schwierig.

Versuchen Sie, Geschichten nicht über die Prozessdimension aufzuschlüsseln. Bauen Sie beispielsweise nicht eine Iteration ein und testen Sie in der nächsten. Dies wirkt sich auf den Durchsatz aus und kann zu technischen Schulden führen.

Danke, dies ist eigentlich der von Ben vorgeschlagene Ansatz der "kleinsten testbaren Komponente".
„Erledigt sollte aus der Perspektive sein, an wen die Geschichte geliefert wird. Dies ist nicht immer der Endbenutzer.“ ==> Sagt Agile/Scrum.org nicht etwas anderes? Bei User Stories geht es darum, dem Endbenutzer einen Mehrwert zu liefern, nicht wahr? Sonst verfällt man in eine „Als Entwickler brauche ich …“-artige technische Geschichte und verliert den wahren Wert der Arbeit.

Ken hatte einige gute Ratschläge. Wir haben festgestellt, dass die wichtigsten Dinge zu beachten sind, dass ...

  1. Der Code sollte immer potentiell auslieferbar sein. Wenn heute ein riesiger Fehler gefunden würde, der die gesamte Anwendung zum Erliegen brachte, könnten Sie anhalten, den Fehler beheben und zur Produktion übergehen? Es mag bedeuten, dass es einige teilweise fertiggestellte Feature-Sets gibt, aber alles, was es gibt, ist von hoher Qualität, getestet und vollständig.
  2. Am Ende des Sprints müssen Sie nachweisbare Fortschritte gemacht haben. Dies ist wichtig, wenn Sie darüber nachdenken, wie Sie den Artikel aufschlüsseln können. Vielleicht bietet dieses Stück an sich dem Kunden keinen "Wert", aber wir können dieses Stück dem Kunden demonstrieren und damit den Fortschritt in Richtung des Endziels zeigen. Wie Ken vorschlägt, vermeiden Sie auf jeden Fall das Aufteilen an Prozesslinien (entwickeln, dann testen) um jeden Preis. Es hilft also zu denken, dass eine Geschichte entweder einen Wert bieten oder Fortschritte in Richtung Wert schaffen muss.

Genauso, wie Sie jedes Epos angehen: Zerlegen Sie es in kleinere Stücke.

Es gibt viele verschiedene Möglichkeiten, dies zu tun. Wenn Ihr Projekt beispielsweise viele andere (Legacy-)Systeme hat, mit denen Sie interagieren können, versuchen Sie, eine User Story auf niedrigerer Ebene zu finden, die sich mit EINEM Legacy-System befasst. Und sehen Sie, wie sich die Umsetzung auf die gesamte epische Geschichte auswirkt.

Ein anderer Ansatz besteht darin, die Dinge aus der Sicht der Interessengruppen anzugehen.

Sehen Sie sich diesen Beitrag für eine weitere Möglichkeit an, damit umzugehen .

Das Aufteilen in technische Storys oder das Ausführen als Mini-Wasserfall sind gut zu versuchen, solange es für das Team und relevante Stakeholder sinnvoll ist

Wie geht man mit User Stories um, die nicht aufgeteilt werden können und nicht einmal in einen 30-tägigen Sprint passen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v