TL; DR;
Was ist der Unterschied zwischen:
A) Die angesprochenen Details, Umfangsdefinitionen und Akzeptanzkriterien, die aus dem laufenden „User Story Conversation“ gewonnen wurden, das ein Team während eines Sprints mit dem PO, den BAs und den Stakeholdern führen sollte
UND
B) Unplanned Scope Creep (was dazu führt, dass eine Story-Schätzung verpasst wird, eine Story den Sprint nicht beendet usw.).
Genauer gesagt, wie belegen Sie Scope Creep & Estimate/Schedule Slip, verursacht durch A vs. B?
Ganze Geschichte
Ich habe ein agiles Team aus funktionsübergreifenden Front- und Backend-Ingenieuren, Designern und QA-Testern. Wir arbeiten in einem kontinuierlichen Kanban-Pull-basierten Fluss, der von einer Reihe von Scrum-Zeremonien wie Stand-Ups, Backlog-Grooming, Retros usw. entkoppelt ist.
Wir erhalten eine Projekt-/Merkmalsdokumentation vom Führungsteam, die einen hochgradigen Geschäftswert und hochgradig detaillierte Spezifikationen eines gewünschten Projekts/Merkmals definiert.
Ich fungiere als PO (neben anderen Hüten, die ich trage), was bedeutet, dass ich an diesem Scoping auf Führungsebene beteiligt bin und während dieses Prozesses die Funktionsvision, die Geschäftsanforderungen und die feinere Geschäftslogik lerne.
Als Nächstes beginnt das Team mit der Funktionsentwicklung und unterteilt diese anfängliche Dokumentation in User Stories, wobei jede Story eine MVP-artige Story definiert, die für sich genommen einen Mehrwert liefern kann. Das Team bereitet die Geschichte vor und kommt zu einer gemeinsamen Einigung. An diesem Punkt streben Team und PO eine zu 99,99 % definierte Geschäftslogik an, lassen aber das „Wie“ offen.
Wenn die Entwicklung beginnt, wird das Team ermutigt, das Gespräch über die User Story fortzusetzen, um immer feinere Details in Bezug auf UI, UX und kleineres Verhalten der Geschäftslogik hervorzurufen. Dies erfordert Gespräche mit mir, unserem Creative Director für Art/Design Direction und unserem CEO für die strategische Produktausrichtung. Zusammen mit diesem Gespräch wird eine Entwicklung und Exploration der Benutzeroberfläche durchgeführt, die Wissen generiert, das wiederum neues Verständnis und möglicherweise neue oder geänderte Geschäftsanforderungen generiert.
Das Problem, auf das ich stoße, ist eine nahezu unendliche „interne Iteration“ dieser User-Story-Konversation. Der Creative Director perfektioniert die UI/UX, der CEO perfektioniert das Geschäftsverhalten des Features und ich kämpfe darum, ein Gleichgewicht zwischen der Bereitstellung eines MVP und der Bereitstellung eines Features zu finden, mit dem alle Beteiligten zufrieden sind.
Meine aktuelle Lösung besteht darin, diesen schmalen Grat zu überwinden, indem ich größere Abweichungen von der anfänglichen User Story in eine separate User Story aufteile, während kleinere Änderungen aller Art als Teil der bestehenden User Story vorgenommen werden können. Dieser Ansatz fühlt sich in Ordnung an, aber meiner Meinung nach könnte er dem agilen/schlanken Denken widersprechen. Andererseits habe ich das Gefühl, dass A) MVP mit PO/Stakeholder-Abzeichnung und B) User Story Conversation auf ihre eigene Weise widersprüchlich sein könnten und dass sie nicht beide gleichzeitig angewendet werden können.
Es sieht so aus, als hättest du ein Problem damit, wie Geschichten geschrieben werden. Geschichten stellen ein Ziel dar, das für einen Akteur einen Wert hat .
Wenn Sie an die Mike-Cohn-Version von User Stories denken: „ [Der Schauspieler] will [das Ziel] tun , um [den Wert] zu bekommen “. Wenn Sie diese drei Elemente identifizieren können, folgt der Umfang logisch.
Die Konversation, die über die User Story stattfinden muss, dreht sich um den einfachsten oder billigsten Weg , um zu diesem Wert zu gelangen, der dem Akteur geliefert wird, indem das Ziel aktiviert wird .
Stellen Sie sich zum Beispiel diese Geschichte für Stack Exchange-Sites vor:
Als registrierter Benutzer möchte ich meinen Avatar ändern , damit mein Avatar derselbe ist wie auf anderen Seiten .
Wie geht das am einfachsten und günstigsten? Hier muss die Diskussion stattfinden. Das sollte schon bei der Planung beginnen und könnte so ablaufen:
Teammitglied A: „Wir könnten ein neues Formular mit einem Datei-Upload auf der Benutzerseite hinzufügen“
Teammitglied B: „Was ist mit dem Ziehen und Ablegen eines Bildes aus einer Datei auf den Avatar selbst?“
Teammitglied A: „Ja das ist einfacher, machen wir das“
Die Entscheidung wird dann auf der Karte vermerkt (oder was auch immer Sie verwenden, um Geschichten zu verfolgen). Es ist ein Implementierungsdetail.
Während der Entwicklung ergeben sich einige Probleme/Möglichkeiten.
Wie gehen wir mit diesen Fällen um?
Punkt 1 bedeutet, dass, um dem Benutzer den vereinbarten Wert bereitzustellen, ein zusätzlicher Aufwand erforderlich ist, insbesondere könnte es sich in diesem Fall um ein Etikett handeln, das dem Benutzer die Funktionalität erklärt. Dies ist eindeutig Teil der Geschichte . Es muss getan werden, damit die Geschichte vollständig und wertvoll ist. Die Entscheidung ist auf der Karte zu vermerken.
Punkt 2 ist eine Einsicht, die gewonnen wurde, als das Team mehr Wissen über das Thema erlangte. Es bietet einen Mehrwert, ist aber nicht notwendig, um das vereinbarte Ziel zu erreichen: Der Wert liegt über dem, was vereinbart wurde. Daher kommt in diesem Fall eine neue Story ins Backlog: "Als registrierter Benutzer möchte ich meinen Avatar per Kopieren/Einfügen ändern , damit ich ihn ändern kann, ohne eine lokale Datei auf meinem System zu speichern ."
Wie Sie sehen können, sollte es ziemlich einfach sein zu verstehen, was "Scope Creep" ist und was nicht. Denken Sie daran, dass es so etwas wie Scope Creep in Agile nicht gibt: Scope Creep ist ein wesentliches Nebenprodukt der Methodik, es ist etwas, das wir tatsächlich fördern, und es hat einen richtigen Platz als neue Geschichten.
Ihre Situation kommt mir ziemlich bekannt vor (wie auch vielen anderen in der realen Welt, vermute ich).
Der agile Ansatz begrüßt Änderungen, auch Änderungen in letzter Minute, daher ist es für die Beteiligten in Ordnung, User Stories kontinuierlich zu verfeinern / zu erweitern und weitere Details oder sogar neue Anforderungen hinzuzufügen. Wie Sie sagen, ist es jedoch nicht einfach, einzelne User Stories „unter Kontrolle“ zu halten. Ist eine Geschichte einmal im Gange, sollte sie nicht so sehr verändert oder erweitert werden, dass frühere Schätzungen und Planungen hinfällig werden. Es ist jedoch in Ordnung, kleinere Details basierend auf dem Feedback von Stakeholdern zu ändern oder zu verfeinern. Wie Sie bemerken, gibt es hier eine feine Balance zu finden. Aber es ist nichts von Natur aus unagil; Ich glaube, dass alle agilen Teams ständig vor diesem Dilemma stehen.
liegt, wie Sie ebenfalls anmerken, zwischen der frühzeitigen Erstellung einer abgesegneten Projekt-/Funktionsdokumentation und der fortlaufenden Pflege der Story. Ich habe das Gefühl, dass es auf Organisationsebene eine Lücke zwischen dem agilen Prozess Ihres Teams und dem traditionelleren Ansatz anderer Abteilungen, einschließlich des Führungsteams, geben könnte.
Ich denke, aus ihrer Sicht könnte ein Teil des Problems tatsächlich darin bestehen, dass sie nicht die einzelnen User Stories sehen, die Ihr Team erstellt hat, sondern nur das vollständige Originaldokument, das keine klaren Grenzen zwischen den verschiedenen Funktionen hat. Sie merken also nicht, wenn sie eine bestehende Geschichte „zu sehr“ erweitern, sodass sie eine komplett neue Geschichte hinzufügen.
Es kann hilfreich sein, ihnen im Detail zu erklären, wie Ihr Team arbeitet, was der agile Ansatz ist und warum, welche Vorteile er im Vergleich zum traditionellen Big Specification Up Front-Ansatz hat. Und auch, um ihnen das aktuelle Problem aus Sicht Ihres Teams zu erklären. Im Idealfall könnten Sie sie von Beginn des Prozesses an davon überzeugen, User Stories zu übernehmen. Das macht es möglicherweise einfacher, die relative Größe jeder Geschichte zu erkennen (unter Verwendung des Feedbacks des Entwicklerteams) und zu vermeiden, dass sie zu sehr aufgebläht werden.
(Dies kann schwierig oder - im schlimmsten Fall - sogar unmöglich sein, abhängig von vielen Faktoren, einschließlich der Denkweise des höheren Managements, Ihrer und der Situation Ihres Teams und des Abteilungsstatus, der Organisationskultur, der "Politik", dem Stand der Agilität Transformation innerhalb Ihrer Organisation usw. Bewerten Sie diese also und gehen Sie vorsichtig vor, oder gar nicht, wenn Sie es für zu riskant halten. Ohne weitere Details ist es unmöglich, konkretere Ratschläge dazu zu geben. Außer vielleicht zwei:
Ein weiterer wichtiger Faktor ist sicherzustellen, dass nur ausreichend kleine Stories in einen Sprint gelangen. Eine Story sollte zu diesem Zeitpunkt klein genug sein, um bequem in einem einzigen Sprint fertig gestellt zu werden; vorzugsweise sollte die Arbeit nicht mehr als ein paar Personentage erfordern. Wenn es zu groß ist, sollte es in kleinere Geschichten aufgeteilt werden. Das Arbeiten mit ausreichend kleinen Storys hilft auch dabei, „Scope Creep“ zu kontrollieren, da Sie einer kleinen Story nur so viel hinzufügen können, bevor Sie bemerken, dass sie zu groß wird, also ist es Zeit, sie aufzuteilen.
ist in Ordnung und voll agil, zumindest wenn es richtig gemacht wird. Das heißt, solange sich die Stakeholder und das Team auf eine Reihe aufeinanderfolgender Verfeinerungen einer Story oder eines Epos einigen können, damit das Team den Stakeholdern die neuen Funktionen als eine Reihe wertvoller Produktinkremente liefern kann. Zu lernen, Geschichten in angemessen kleine Abschnitte zu zerlegen, ist eine Kunst, die Geduld und langfristige Übung erfordert. Und das Feedback von Ihnen und Ihrem Team gegenüber den Stakeholdern kann hier sehr hilfreich sein, sowie ihnen regelmäßig fertige, funktionierende Produktinkremente zu demonstrieren - ich weiß nicht, wie oft Sie das tun?
Versuch meine eigene Frage zu beantworten
Mein erstes Gefühl ist folgendes:
Benötigen Sie mehr Unterstützung der Führungskräfte für Agile: Führungskräfte sind zu sehr mit den Details und „How tos“ der Implementierung beschäftigt; Dadurch entsteht ein eher vertragsbasierter Top-Down-Ansatz als ein iterativer, hypothesengesteuerter Ansatz.
Wenn das Team eine echte iterative Entwicklung durchführen würde, wäre dies kein Problem: Das Team würde sich iterativ und inkrementell zur richtigen Lösung entwickeln . Die Führungskraft und das Produkt-/BA-Team müssen weiterhin Strategien und Visionen auf hoher Ebene definieren und das Team die Geschäfts- und UX-Erkundung durchführen lassen, die erforderlich sind, um zur optimalen Lösung zu gelangen.
Wenn PO/BAs echte hypothesen- und datengesteuerte Produktspezifikationen erstellen würden, wäre dies kein Problem. Stattdessen beschäftigen sich PO/BAs und das Führungsteam mit historischem und „gutem Gefühl“-Funktionsdesign, basierend auf „was zuvor funktioniert hat“ und „was meiner Meinung nach funktionieren wird“; Dies bewirkt
Das Team muss das Geschäft auf einer viel tieferen Ebene kennenlernen, um bestimmte Entscheidungen im Namen des Kunden/Benutzers treffen zu können, ohne so viel PO oder Input der Geschäftsführung zu benötigen. Wenn das Team in der Lage wäre, sich auf der Grundlage seiner Kenntnisse über das Produkt, den Benutzer und den Markt zwischen zwei Optionen der Geschäftslogik zu entscheiden, würde es sich in Richtung echter Selbstorganisation und Produktbesitz bewegen.
Klare Verantwortung des Teams: Bringen Sie das Team dazu, zu wissen, warum es ein Feature auf eine bestimmte Weise entwickelt, und die Verantwortung für seinen Erfolg zu übernehmen. Dazu müssen Teams in die Lage versetzt werden, unabhängige Entscheidungen zu treffen und dann Erfolg/Misserfolg zu messen. Mehr Unabhängigkeit geht mit mehr Verantwortung und Rechenschaftspflicht einher.
Das Produkt benötigt einen engagierten Vollzeit-PO, der ein Fachexperte ist und dem ein Team von BAs und/oder Datenanalysten zur Verfügung steht, um sich an einer echten hypothesen- und iterationsgetriebenen Entwicklung zu beteiligen.
Insgesamt ist dies ein Prozess, der sehr komplex und zeitaufwändig in der Umsetzung ist, ganz zu schweigen von Risiken.
Bernhard