Wer prüft welche Kriterien für Epics?

Bemühe dich, unabhängige kleinere Geschichten zu schreiben

...zusätzliche Geschichten, die sie weder interessiert noch versteht.

Schreiben Sie keine Geschichten, die die PO nicht versteht. Wenn es der Bequemlichkeit der Entwickler dient, ist es keine Geschichte. Es ist nur eine technische Aufgabe. Geben Sie sich mehr Mühe, kleinere Geschichten zu schreiben, die der PO versteht. Siehe vorherige Diskussion in PMSE hier, wie man größere Geschichten aufteilt.

Übrigens ist es nicht so, dass sich der Product Owner alleine abmüht Geschichten und Akzeptanzkriterien zu schreiben. Bei Backlog-Refinement-Meetings sollte das Entwicklungsteam mit dem Product Owner zusammenarbeiten, um die Storys aufzuteilen und Akzeptanzkriterien zu schreiben.

...Unit-Test-Suiten für Dinge, die noch kein Frontend haben.

Komponententests dienen der Entwicklerproduktivität. Sie können den Umfang der vom QA-Team durchzuführenden Regressionstests reduzieren. Sie sind jedoch kein Ersatz für QA und PO, die Abnahmetests aus Sicht des Endbenutzers durchführen. Stories sollten vertikale Slices sein (mit einem Front-End und einem passenden Back-End).

Meine Frage ist also: Sehen Sie daran etwas grundsätzlich Falsches?

Ja. Ihr Team scheint vom Wasserfalldenken belastet zu sein. Dies ist nicht ungewöhnlich für Teams, die versuchen, von Wasserfall zu Agil zu wechseln. Versuchen Sie, beim vertikalen Aufteilen von Geschichten Hilfe zu erhalten (unter Verwendung von Online-Ressourcen oder eines Mentors). Ihr Engineering Manager scheint das richtige Gespür zu haben. Das ist ein großes Plus!

Wie gehst du an das Testen von Epic usw. heran?

Du nicht. Das Team sollte sich bemühen, unabhängige kleinere Geschichten zu schreiben, die der PO verstehen und testen kann.

TL;DR

Wer prüft welche Kriterien für Epics?

Epen und Themen sind im Allgemeinen nicht testbar, daher lautet die Antwort wirklich „niemand“. Stattdessen muss das gesamte Scrum-Team diese zu großen Elemente während der Backlog-Verfeinerung oder der Sprint-Planung zerlegen, bis sie Stories sind, die testbare Kriterien enthalten, die gemessen werden können.

Das gesamte Scrum-Team, zu dem ausdrücklich der Product Owner gehört, muss zusammenarbeiten, um umsetzbare User Stories zu definieren, die test- und nachweisbar sind . Ihr aktueller Prozess fördert keine ausreichende Zusammenarbeit, um dies zu erreichen.

Darüber hinaus führt Ihr aktueller Prozess dazu, dass das Team Gelegenheiten verpasst, mit dem Product Owner zusammenzuarbeiten, um Implementierungsdetails auszuhandeln, die einen Mehrwert schaffen, Projektkosten senken oder zu mehr Nachhaltigkeit führen. Während sich der Product Owner nicht um Details auf Codeebene kümmern sollte, kann das Verständnis der Kompromisse bei verschiedenen Implementierungen dem gesamten Team helfen, sicherzustellen, dass das Richtige erstellt wird und dass Möglichkeiten zum Erstellen eines potenziell auslieferbaren Inkrements vorhanden sind durch offene Diskussionen über Minimum Viable Features und YAGNI- Prinzipien gesteigert.

Epics und Themes sollten es niemals aus dem Product Backlog in das Sprint Backlog schaffen. Dabei entsteht ein sehr starker „Projektgeruch“, der auf ein grundlegendes Problem bei der Umsetzung des Scrum-Prozesses des Teams hinweist.

Aufgaben vs. abhängige Storys

Geschichten

Geschichten und Aufgaben sind zwei verschiedene Dinge. Eine User Story hat ein Format , von dem erwartet wird, dass es als Platzhalter fungiert, der ein Feature, einen Standpunkt, der den Nutznießer des Features darstellt, und einen Kontext definiert. Variationen des Connextra-Formats sind das, woran die Leute am häufigsten denken:

Als [Rolle oder „Wertverbraucher“]
möchte ich [Merkmal oder Funktionalität]
, damit [in einem bestimmten Kontext davon profitiert].

Eine Story ist ein Platzhalter für Gespräche, um die Zusammenarbeit zu ermöglichen, und ist nicht als vollwertige Spezifikation gedacht. Geschichten werden im Allgemeinen in Story Points geschätzt (z. B. modifizierte Fibonacci-Folge, T-Shirt-Größen usw.).

Storys leben im Allgemeinen im Product Backlog, da sie zwar der INVEST -Mnemonik entsprechen, aber einen Wert für das Projekt und potenziell lieferbare Funktionen darstellen.

Aufgaben

Auf der anderen Seite ist eine Aufgabe ein Checklistenpunkt, der dem Team hilft, seinen Fortschritt beim Abschluss der Geschichte zu verfolgen. Eine Story sollte Aufgaben haben, aber eine Story sollte (als Faustregel) keine abhängigen Storys haben.

Aufgaben leben oft eher im Sprint Backlog als im Product Backlog, da es sich eher um Implementierungsdetails oder technische Meilensteine ​​handelt als um Geschichten, die sich strikt an die INVEST-Kriterien halten sollten. Trotzdem sollten sie klein und testbar sein, also gibt es sicherlich ein bisschen Überschneidung.

Aufgaben können handlungsorientiert sein, werden aber oft eher in idealen Stunden als in Aufwandsstufen geschätzt. Zum Beispiel eine Geschichte wie:

Als Bankkunde
möchte ich jeden Geldautomaten gebührenfrei nutzen können, um überall
auf mein Geld zugreifen zu können.

sollte während des Sprint Plannings in diskrete, messbare Aufgaben unterteilt werden. Die Aufgaben für diese Story, ob sie sich auf der Rückseite einer Story-Karte, Elementen im Sprint Backlog, Zeilen in einer Tabellenkalkulation oder auf ihren eigenen Karteikarten befinden, könnten so aussehen:

• ☑ Fügen Sie eine Datenbankspalte hinzu, um die Mitgliedschaft im ATM-Netzwerk zu verfolgen. (2 Stunden)
• ☑ Fügen Sie eine Datenbankspalte hinzu, um Gebühren im Zusammenhang mit Geldautomatenabhebungen in ausländischen Netzwerken zu verfolgen. (16 Stunden)
• ☐ Modellrückrufe hinzufügen, um Kunden Geldautomatengebühren zu erstatten, die auf Abhebungen an ausländischen Geldautomaten zurückzuführen sind. (8 Stunden)

Aufgaben können während des Sprints vom Team hinzugefügt, gelöscht oder geändert werden, wenn neue Erkenntnisse gewonnen oder Abhängigkeiten oder Implementierungsdetails entdeckt werden. Das Sprint Backlog gehört dem Entwicklungsteam, nicht dem Product Owner, daher spiegelt der Inhalt des Team-Backlogs die Arbeit wider, die das Entwicklungsteam leisten muss, um die User Story aus dem Product Backlog zu implementieren.

Zusammenarbeit

Während das Product Backlog dem Product Owner und das Sprint Backlog dem Team gehört, ist es dennoch sinnvoll sicherzustellen, dass beide Artefakte für alle in der Organisation sichtbar sind, um die Zusammenarbeit zu fördern.

Ein Product Owner, der den Aufwand oder die Stunden, die mit Story-bezogenen Aufgaben verbunden sind, nicht sehen kann, hat unzureichende Einblicke in die tatsächlichen Kosten einer bestimmten Story, und das Team verpasst wertvolle Gelegenheiten zur Zusammenarbeit an verhandelbaren Implementierungsdetails . Beispielsweise kann sich während eines Sprints herausstellen, dass der Product Owner nicht alle Gebühren für alle Banken abdeckt; Die 80/20-Regel bedeutet, dass sich das Team vielleicht auf die Festcodierung von Werten für drei lokale Banken konzentrieren kann, die die meisten Beschwerden hervorrufen, anstatt eine flexiblere Lösung entwickeln zu müssen, die für alle Banken überall gelten würde.

Einheiten-/Funktionstests und Sprint-Review-Demonstrationen

Epics sind nicht testbar oder (allgemein) nachweisbar. Themen sind es auch nicht. Das macht sie für Sprints ungeeignet; Sie sollten nur für die langfristige Planung verwendet und bei Bedarf während der Backlog-Verfeinerung oder der Sprint-Planung zerlegt werden.

Alle Geschichten, die den INVEST-Kriterien entsprechen, sind von Natur aus testbar. Meiner persönlichen Erfahrung nach sollten Storys im Allgemeinen von Feature- oder Integrationstests und Aufgaben von Unit-Tests angetrieben werden. Es gibt sicherlich alle möglichen Vorbehalte und Ausnahmen von dieser Faustregel, aber die Befolgung dieser Ratschläge hilft in vielerlei Hinsicht, einschließlich:

1. Funktionstests (z. B. automatisierte Browsertests) zeigen die Funktion aus einer für den Benutzer sichtbaren Sicht und können in vielen Situationen sogar als Ersatz für Benutzerakzeptanztests dienen.
2. Funktionstests bauen Vertrauen bei den Beteiligten auf und zeigen oft, dass das Richtige™ gebaut wurde.
3. Komponententests sind für das Entwicklungsteam und helfen, das Design voranzutreiben und Regressionen zu verhindern. Sie sind als Sprint-Review-Demonstrationen im Allgemeinen uninteressant, aber aus Sicht der nachhaltigen Entwicklung die wichtigsten Punkte.

4. Dieser Stil, der TDD und ATDD entlang der Linie von Features vs. Tasks aufteilt, trägt dazu bei, die Testpyramide aufrechtzuerhalten , mit einigen langsamen High-Level-Tests, die von einer Basisschicht aus blitzschnellen Unit-Tests unterstützt werden. Zum Beispiel:

   

Wie immer wird es Ausnahmen und Vorbehalte geben, aber als Faustregeln habe ich festgestellt, dass das Vorstehende einigermaßen solide Praktiken ist. YMMV.

Eine kürzere Antwort als die anderen Epen:

Ja, es gibt Probleme mit diesem Ansatz. Während es funktioniert, solange alle zufrieden sind, geht das Risiko in den Anforderungen im Detail verloren.

Wenn Ihre Gesamtlösung so kompliziert geworden ist, dass „einfache“ (wie vom PO betrachtete) Änderungen von den Ingenieuren als „episch“ angesehen werden, wird der PO die Auswirkungen von Änderungen und/oder Verzögerungen nicht verstehen und die Ingenieure werden möglicherweise nicht mit dem PO implementieren 'wirklich will'

Ich denke, es ist eine legitime Herausforderung für agile Methoden, zu fragen, wie mit diesen größeren mehrschichtigen Systemen umgegangen werden soll, bei denen aus welchen Gründen auch immer kleine Änderungen an dem, was der Benutzer sieht, große Änderungen „hinter den Kulissen“ in Serviceschichten/Datenbanken usw. nach sich ziehen können Der Slice-Ansatz zur Bereitstellung diskreter Funktionalität kann Sie tatsächlich in diese Position bringen, in der Sie anstelle einer Anforderung an eine generische flexible Schnittstelle für eine niedrigere Ebene mit einer Vielzahl unflexibler Mini-Schnittstellen enden können.

Ich würde Sie diesem Problem entgegenwirken, indem Sie eine Meta-Anforderung/Story für Ihre unteren Ebenen schreiben, um diese Flexibilität wieder herzustellen und „einfache“ Änderungen an der Benutzerfunktionalität zu unterstützen, ohne dass eine Änderung der Basisfunktionalität erforderlich ist.

Ihre unteren Ebenen müssen möglicherweise sogar in ein eigenes Produkt mit einer eigenen Bestellung aufgeteilt werden