Es gibt etwas, das mich bei Scrum immer gestört hat. Hoffentlich bekomme ich hier einen kleinen Einblick.
Mit Scrum versuchen wir, den Rückstand in vertikale Scheiben zu zerlegen. Sagen wir Geschichten A und B. Diese Geschichten sollen kundenorientiert sein und Wert liefern. Gehen Sie hier davon aus, dass sie einen ähnlichen Kundenwert haben.
Nehmen wir nun an, dass A und B zur Implementierung eine gemeinsame Infrastruktur benötigen. Nehmen wir also an, wir befinden uns bei der Verfeinerung des Rückstands. Wenn ich das Entwicklerteam bitte, in Story Points zu schätzen, schätzen sie sie möglicherweise auf 8 Punkte, wenn sie separat geschätzt werden: A8, B8. Das ist gut für mich als PO, weil ich die Stories im Backlog verschieben kann, ohne etwas kaputt zu machen.
Bei der Prognose wird mein Rückstand jedoch schwerer erscheinen, da sie kombiniert möglicherweise mit weniger Aufwand geliefert werden als die Summe der Teile. Wenn mein Team eine hypothetische Geschwindigkeit von 13 hat, sieht es so aus, als könnten sie nicht in einem Sprint liefern. Wenn es viele solcher Elemente gibt, ist es unmöglich, eine Zeitachse über den geplanten Sprint hinaus sichtbar zu machen.
Wenn wir mehrere Storys mit derselben gemeinsam genutzten Infrastruktur haben, erscheint der Rückstand sehr hoch und eine Prognose ist unmöglich.
Ich habe 2 Varianten gesehen:
Teilen Sie die Infrastrukturarbeit in ein separates "technisches" Geschoss auf: A3, B3, T5 Dies löst den Schätzprozess, aber es ist ein horizontaler Schnitt. Die Infra selbst hat keinen Kundenwert. Außerdem enthält das Backlog jetzt Abhängigkeiten, da die Stories nicht mehr atomar sind, was bedeutet, dass ich sie nicht neu anordnen kann, ohne mir der Abhängigkeiten bewusst zu sein. Ohne auf die Besonderheiten zu schauen, hätte ich A und B als erstes gewählt, weil sie wenig Aufwand und hohen Wert haben. Es geht also zurück zur klassischen Projektplanung.
Schätzen Sie den Infrastrukturaufwand nur in einer der Geschichten und schätzen Sie die zweite, als ob die erste bereits fertig wäre: A8, B3. Der Nachteil hierbei ist, dass eine Geschichte komplexer erscheint als die andere. Wenn ich mir also nicht die Details anschaue, werde ich dazu neigen, Geschichte B zu priorisieren, da sie mit weniger Aufwand den gleichen Kundenwert wie A hat.
Die Fragen lauten also:
Ich habe diese ein wenig ad hoc behandelt, indem ich eine der beiden oben genannten Optionen verwendet und Abhängigkeiten markiert habe, damit ich keine vorausgesetzten Aufgaben vor nachfolgende Aufgaben stelle. Wenn ich das tue, verteile ich die Story Points neu. Aber es sieht schlecht aus für alle anderen, die sich den Rückstand ansehen, und ich bevorzuge, dass der Rückstand ein nützliches und transparentes Artefakt ist.
(Zu groß für einen Kommentar)
Ich stimme zwei Ihrer Bemerkungen unter Punkt 1 nicht zu:
Es hört sich so an, als würden Sie "Lasst uns ein System entwerfen, das funktioniert" (*) mit theoretischen "Sollte sein" blockieren. Warum willst du an deinen vertikalen Scheiben festhalten?
Also ja, in A3, B3, T5 aufteilen und sehen, wie das funktioniert.
Wenn Sie dies ein paar Mal getan haben, bewerten Sie es. Ihr größtes „Risiko“ besteht darin, T5 zu machen und dann später zu entscheiden, dass A3 und B3 nicht notwendig sind.
(*) Stimmt nicht, da Sie sich die Mühe machen, hier zu fragen
Dieses Problem ist kein Scrum-spezifisches Problem. Es ist bei den agilen Methoden weit verbreitet, die eine häufige Lieferung wertvoller, funktionierender Software an Kunden und Benutzer erfordern. Ich bin auf zwei Möglichkeiten gestoßen, mit dieser Situation umzugehen, die beide gut funktioniert haben.
Der erste Weg wäre, die Infrastruktur zu definieren, die als Teil von A und B benötigt wird. Schätzen Sie dann sowohl A als auch B so, als ob die Infrastruktur als Teil von beiden erstellt und getestet würde. Der zweite Ansatz besteht darin, die Infrastruktur in ein abhängiges Element aufzuteilen, das abgeschlossen werden muss, bevor entweder A oder B abgeschlossen ist, um sicherzustellen, dass die Dimensionierung für A und B auf der Annahme basiert, dass die Infrastruktur vorhanden ist.
Ich würde die vorgeschlagene Lösung vermeiden, A und B so zu schätzen, dass das eine vor dem anderen durchgeführt werden muss. Dies fügt der Art und Weise, wie das Team arbeiten muss, eine unnötige und potenziell unklare Einschränkung hinzu. Wird zuerst mit dem Falschen begonnen, wird dieser deutlich unterschätzt.
Ich muss Jan Doggens Argument zustimmen , dass es nicht immer der beste Weg ist, jedes Product Backlog Item in Bezug auf den direkten Kundenwert zu definieren. Einige Arbeiten – wie die Arbeit zum Entwerfen, Erstellen und Validieren einer gemeinsamen Infrastruktur – haben keinen direkten Wert für einen Stakeholder, aber das Entfernen dieser gemeinsamen Abhängigkeit eröffnet dem Entwicklungsteam Möglichkeiten, eine beliebige Anzahl von Arbeiten zu leisten, die für Stakeholder direkt wertvoll sind unter Beibehaltung der Integrität des Systems.
Ich stelle mir jedes Product Backlog Item gerne als eine unabhängig gestaltbare, implementierbare, testbare und lieferbare Einheit vor. Sie können die Infrastruktur entwerfen, einrichten, testen und in Betrieb nehmen. Dies gibt Ihnen die Möglichkeit, Infrastrukturkonfiguration, Leistungstests und Konfigurationsoptimierung sowie Sicherheitstests zu berücksichtigen. Wenn die Infrastruktur bereits vorhanden ist, bevor die Software bereitgestellt wird, die sie verwendet, wird häufig der Bereitstellungsdruck verringert. In Anbetracht all dessen ist es sinnvoll sicherzustellen, dass Ihre Infrastrukturentscheidungen korrekt sind, um nicht funktionale Anforderungen zu erfüllen, bevor Sie Software bereitstellen, die sie verwendet.
Die Wahl zwischen einer technischen Abhängigkeit in Ihrem Product Backlog und der Aufnahme der Arbeit in beide Product Backlog Items hängt mehr von Ihrem Kontext als von allem anderen ab. Dinge wie die Anzahl der Teams, die das Produkt unterstützen, das technische Know-how des Produktmanagers, die Tools, die zum Verfolgen Ihres Produkt-Backlogs verwendet werden, die Zeitverzögerung zwischen der Identifizierung dieser Arbeit und dem Beginn dieser Arbeit und der Druck auf das gesamte Team würden meine Entscheidung beeinflussen so oder so.
Ich denke nicht, dass Bedenken hinsichtlich der Schwere des Product Backlogs überhaupt in die Entscheidung einfließen sollten. Schließlich macht man keinen festen Zeitplan und legt sich darauf fest. Sie prognostizieren den Arbeitsaufwand. Wenn Sie schätzen, haben alle Ihre Schätzungen Rauschen. Wenn Sie den Arbeitsaufwand überschätzt haben, können Sie diese Zeit immer effektiv nutzen, indem Sie sich entweder etwas zusätzliche Zeit für die Verfeinerung des Product Backlogs, den Aufbau von Fähigkeiten, die Tilgung technischer Schulden nehmen oder früh mit anderen Arbeiten beginnen.
Dies ist ein häufiges Dilemma. Das Team sollte entscheiden, wie es in jedem Fall schätzen möchte, aber es kann völlig in Ordnung sein, die Differenz aufzuteilen und jeder Geschichte dieselbe Schätzung zu geben, obwohl Sie wissen, dass eine von ihnen länger dauern wird. Wenn Sie sie als gleich behandeln, müssen Sie keine harten Abhängigkeiten verfolgen, und obwohl Sie in einem Sprint möglicherweise eine etwas niedrigere Geschwindigkeit haben, sehen Sie in nachfolgenden Sprints einen Anstieg, wenn Sie die anderen Elemente abschließen. Dies ist angemessen, insbesondere da solche Situationen am Anfang eines neuen Stücks auftreten, in dem Sie möglicherweise eine niedrigere Geschwindigkeit erwarten.
Geschwindigkeit und Punkte sind nicht die einzigen Dinge – oder sogar die wichtigsten Dinge – die Teams verwenden, um zu entscheiden, was in einen Sprint einfließen kann. Während der Sprintplanung muss das Team ein anständiges Verständnis davon erlangen, was zu tun ist. Beim Planungstreffen sollten sie sich darüber im Klaren sein, dass eine Geschichte eine Infrastruktur braucht, die noch nicht vorhanden ist; Sie können diese Tatsache berücksichtigen, wenn sie entscheiden, welche Elemente in den Sprint passen.
Dies ist einer der Gründe, warum es wertvoll ist, Ihre Kostenvoranschläge und Planungen kurz vor Arbeitsbeginn durchzuführen.
Das Gespräch kann etwa so verlaufen:
„Wir wissen, dass wir dieses bisschen Infrastrukturarbeit haben, sollen wir es zu Story X hinzufügen, da dies die erste ist, an der wir im nächsten Sprint arbeiten? Wenn wir unsere Meinung über die Reihenfolge der Storys ändern, können wir jederzeit wechseln es in eine andere Geschichte umwandeln und während der Planung neu schätzen."
Um Ihre Frage zu beantworten: Der beste Ansatz besteht darin, sich des potenziellen Problems bewusst zu sein und es in Ihre Planungs- und Verfeinerungssitzungen einzubeziehen.
Verwechseln Sie „Endnutzerwert“ nicht mit „Produktwert“. Sie sind weder fungibel noch orthogonal. Der Endbenutzerwert ist einfach eine viel kleinere Teilmenge des Gesamtwerts , den ein Produkt liefern muss, und eine übermäßige Beschränkung Ihres Produkt-Backlogs auf der Grundlage des Endbenutzerwerts ist eine sehr fadenscheinige Ansammlung von Projekt- und Produktmanagement-Gerüchen.
Sie leiden unter einem weit verbreiteten Missverständnis über Scrum. Der aktuelle Scrum-Leitfaden enthält einige allgemeine Ratschläge (aber wenig, um zu sagen, dass es sich um Vorschriften handelt), wie das Product Backlog geordnet ist, außer dass es nach produktspezifischen Kriterien geordnet werden sollte.
Nirgendwo im Scrum Guide wird vorgeschrieben, dass „Wert“ ein kundenorientierter Wert sein muss. Sogar der Abschnitt über das Produkt-Backlog-Artefakt sagt einfach:
Product Backlog Refinement ... ist eine fortlaufende Aktivität, um Details hinzuzufügen, wie z. B. eine Beschreibung, Reihenfolge und Größe. Attribute variieren oft mit der Domäne der Arbeit.
Während es auch sagt, dass ein Produkt ein Vehikel ist, um Wert zu liefern, und andere Abschnitte des Leitfadens davon sprechen, dass das Inkrement (z. B. das zusammenhängende Sprint-Ziel) Wert liefert , schreibt es nirgendwo vor, dass der Wert ausschließlich für den Kunden bestimmt ist, oder definiert was SAFe nennt „ Architectural Runway “ als wertlos.
Anstatt zu versuchen, alle Ihre Product-Backlog-Elemente in eine künstliche Definition von Wert zu stecken, sollten Sie den Wert als Gesamtkennzahl oder zumindest als Ergebnis einer Reihe von Schiebereglern behandeln, um festzustellen, ob Elemente im Backlog einen Mehrwert bieten das Produkt, das Sie bauen.
Infrastrukturarbeit, die eine Voraussetzung für die Erstellung eines Produktinkrements ist, erhöht den Wert des Produkts eindeutig, da Sie das Inkrement ohne sie nicht erstellen können. Ebenso haben Funktionen, die einen Mehrwert für Stakeholder und nicht für Kunden schaffen, ebenfalls einen Wert. Ein zufälliges Beispiel: Das Erstellen einer Funktion, die Ihre Rechtsabteilung patentieren kann, hat für Endbenutzer keinen Nutzen, kann aber für das Unternehmen von Wert sein. Diese Art von wertorientiertem Denken aus Ihrem Product Backlog auszuschließen, ist definitiv ein Anti-Pattern.
Stellen Sie sich „Wert“ als ganzheitliche Metrik vor, aber auch als Möglichkeit, Ressourcenprioritäten zu identifizieren. Alle Projekte haben Einschränkungen, einschließlich Zeit, Budget, Umfang, Qualität und Personal. Durch die Priorisierung von wertschöpfenden Aktivitäten, wie auch immer Sie dies definieren, werden die begrenzten Ressourcen eines Projekts zwangsläufig auf bestimmte Produktziele ausgerichtet.
Kurz gesagt, vielleicht würde ein Unternehmen langfristig mehr Geld verdienen, wenn es ein Widget ausbaut. Andererseits kann das Unternehmen mit seinen begrenzten Ressourcen vielleicht kurzfristig mehr Wert realisieren, indem es ein Therblig verkleinert. Was ist eine bessere Nutzung der begrenzten Ressourcen des Projekts? Die aggregierte Wertmetrik, die durch das Product Backlog verkörpert wird, beantwortet diese Frage für das Scrum-Team, dieses bestimmte Produkt und die Geschäftsziele der Stakeholder.
Auf diese Art von Fragen gibt es keine Einzelantworten, weshalb Scrum diesbezüglich keine Vorschriften macht. Stattdessen bietet das Framework einige Leitlinien, impliziert streng, dass Stakeholder konsultiert werden sollten, und sagt dann ausdrücklich, dass die endgültige Entscheidung ausschließlich in der Zuständigkeit des Product Owners liegt. Kurz gesagt, es liegt am Product Owner, zu definieren, wie der „Wert“ innerhalb eines bestimmten Projekts angewendet werden soll, mit der Absicht, den Produktwert zu maximieren und indirekt die Ressourcenzuweisungen des Projekts zu steuern.
„Was nützen all diese Betonblöcke am Fuß der Wände meines Hauses? Sie sitzen direkt auf dem Dreck, sie sind nicht schön, und ich schaue sie nie an … von welchem ‚Wert‘ sind sie Mich?"
Sie denken nicht über diese Dinge nach, bis Risse in der Wandtafel auftauchen ... dann haben Sie ein ziemlich teures Problem, mit dem Sie sich befassen müssen.
Ich empfehle, diese gemeinsamen „Infrastruktur“-Aufgaben als separate Geschichte herauszuarbeiten. Dann, auf irgendeine Weise, die jedem klar sein wird, der sich die Metriken ansieht, verknüpfen Sie diese Geschichten mit allen anderen Geschichten, die von ihnen abhängen, und machen Sie auch deutlich, wie sie von ihnen abhängen. Ist dies eine Voraussetzung? Eine Voraussetzung? Handelt es sich um eine gemeinsam genutzte, aber für den Benutzer sichtbare Funktionalität?
Die Dokumentation dieser Abhängigkeiten ist äußerst wichtig: Sie müssen sicher sein, dass Sie jede solche Abhängigkeit identifizieren. Listen Sie im Text der „geteilten Geschichte“ alle Geschichten auf, die sie teilen, und erklären Sie kurz, warum. Listen Sie ebenso im Text der „Geschichten teilen“ alles auf, was geteilt wird. Dabei muss man sehr vorsichtig sein, damit der Leser jeder Geschichte das Gesamtbild vollständig versteht – insbesondere dann, wenn es darum geht, die „gemeinsame Geschichte“ zu einem Umsetzungsplan zu entwickeln.
Schließlich könnte es der Fall sein, dass das gemeinsam genutzte Material zukünftige Bedürfnisse antizipieren sollte. Sie sollten dies in der Beschreibung der gemeinsamen Geschichte(n) sehr sorgfältig und bewusst untersuchen. Überlegen Sie, ob diese erwartete Funktionalität jetzt eingebaut oder nur "abgestumpft" werden sollte.
Meiner Ansicht nach sollte eine gute "Geschichte" eine bevorstehende Arbeitseinheit aus einem sinnvollen Blickwinkel genau beschreiben, so dass ein objektiver Leser eine vernünftige Chance hat, sie einzugrenzen und nur auf der Grundlage dessen zu planen, was die Geschichte enthält. Und, wie bereits erwähnt, sollte jede Abhängigkeit oder potenzielle Auswirkung auf die Seitenkette ausdrücklich erwähnt werden.
Daniel
Thomas Owens