Ich weiß, wir müssen diese Aufgabe in mehrere Unteraufgaben aufteilen. Doch was tun, wenn eine weitere Aufteilung dieser Aufgabe keinen Sinn macht? Was ist, wenn alle daraus resultierenden Unteraufgaben keinen geschäftlichen Wert haben, bis sie alle erledigt und integriert sind?
Vielleicht scheint es, dass dies eine etwas künstliche Situation ist, aber manchmal kann es passieren (besonders, wenn Sie kurze Sprints haben).
Beispiel aus meiner Praxis: Wir haben User Story, um Benutzern die Zahlung von unserem System zu ermöglichen. Als Teil dieser Geschichte haben wir die Aufgabe, einen Drittanbieter-Zahlungsdienst in unser Projekt zu integrieren. Alle Unteraufgaben dieser Aufgabe sind also absolut technisch und haben keinen geschäftlichen Wert.
Ich sehe also nur drei Möglichkeiten, dieses Problem zu lösen:
Trennen Sie geschäftlich wertvolle Aufgaben von mehreren technischen Aufgaben. Aber in diesem Fall werden wir im ersten Sprint nichts Nützliches machen und wir werden im Review nichts vorzuweisen haben.
Machen Sie alle Sprints größer. Vielleicht sind unsere Sprints zu kurz und es wird besser sein, sie größer zu machen. In diesem Fall werden wir die Rückkopplungsgeschwindigkeit reduzieren, aber eine Situation, wie ich sie unten beschrieben habe, kann nie wieder vorkommen.
Machen Sie den aktuellen Sprint größer. Wie ich weiß, ist dies keine Scrum-Lösung. Scrum wie Konstanz (machen Sie Daily Scrum am selben Ort und zur selben Zeit, feste begrenzte Zeitfenster und so weiter). Außerdem wird es schwierig sein, den neuen Überprüfungstag mit den Interessengruppen in Einklang zu bringen. Wenn Sie andere Teams haben, die am selben Projekt arbeiten, werden die Probleme mit dieser Lösung viel größer sein.
Welche Lösung ist besser? Oder kennt vielleicht jemand einen besseren Weg, um dieses Problem zu lösen?
...auch wenn es nichts ist, was man wirklich nutzen kann.
Wenn Sie beispielsweise Visa, MasterCard und PayPal akzeptieren, können Sie zuerst PayPal implementieren (oder was am einfachsten zu implementieren ist) und dann separate Storys haben, um Visa und Mastercard hinzuzufügen.
Wenn Sie wiederkehrende Zahlungen akzeptieren (z. B. ein monatliches Abonnement), können Sie zunächst einzelne Zahlungen implementieren und dann die wiederkehrenden Zahlungen in einem anderen Sprint hinzufügen.
Hier sind einige Tipps zum Aufteilen größerer User Stories:
Muster zum Aufteilen von User Storys
8 nützliche Strategien zum Aufteilen großer User Stories (und ein Cheatsheet)
"Aktuellen Sprint größer machen" ist keine gute Option. Zusätzlich zu den von Ihnen aufgeführten Problemen können Sie keine vernünftige Teamgeschwindigkeit aufbauen, wenn Sie die Sprintdauer ständig ändern.
"Alle Sprints größer machen" ist eine mögliche Option, wenn Sie immer wieder auf diese Art von Problem stoßen, nachdem Sie sich alle Mühe gegeben haben, größere Geschichten aufzuteilen.
Lassen Sie uns zunächst die praktische Angelegenheit ansprechen: Wenn Sie in einer Planung sind und eine Geschichte mit höchster Priorität haben, aber nicht sehen, wie Sie sie aufschlüsseln und den Geschäftswert erhalten können, ist es besser, sie technisch aufzubrechen und zu verschieben nach vorn, als a) in dieser Geschichte die Räder durchdrehen zu lassen oder b) störende Änderungen an der Struktur vorzunehmen, wie z. B. eine Änderung der Sprintlänge.
Allerdings gibt es in Scrum ein weit verbreitetes Missverständnis, dass eine Geschichte, um wertvoll und auslieferbar zu sein, ein vollständiges, produktionsreifes Feature sein muss. Um Ihr Zahlungsbeispiel zu verwenden, so wie die meisten Zahlungssysteme von Drittanbietern funktionieren, gibt es einige Arbeit, die es erfordert, es anzuschließen, und viel Arbeit, die in die Handhabung verschiedener möglicher Szenarien gesteckt wird, die auftreten könnten. Die Zahlungsfunktion ist definitiv erst fertig, wenn sie vollständig integriert ist, aber die Teile haben immer noch einen Wert. Wenn Sie es bis zu dem Punkt bringen, dass eine korrekt eingegebene Kreditkarte mit ausreichend verfügbarem Guthaben funktioniert und alles andere als allgemeiner Fehler behandelt wird, gibt es definitiv einen Geschäftswert und sie ist lieferbar. Zugegeben, die Umstände, unter denen Sie dies zur Produktion freigeben würden, sind selten, aber Sie könnten es, wenn es gerechtfertigt wäre.
Das Schwierige an diesen Geschichten ist, dass sie einige Zeit und Zusammenarbeit erfordern, um sie durchzuarbeiten. Wenn Sie eine Technik ausprobieren möchten, können Sie sich meinen Blogbeitrag zu diesem Thema ansehen. Worauf es jedoch wirklich hinausläuft, ist, dass Sie mit dem Team zusammenarbeiten müssen, um die Teile des Prozesses der Umsetzung der Geschichte zu zeigen, und dann den PO abwägen, wo sie Wert sehen.
Manchmal kommt es vor, dass Sie Funktionen haben, die nicht vollständig in einem Sprint bereitgestellt werden können. Sie sollten erwägen, es in Unteraufgaben aufzuteilen, die selbst keinen Geschäftswert liefern, aber nach jedem Sprint demonstriert und verifiziert werden können.
In Anbetracht Ihres Zahlungssystembeispiels können wir drei Sprints haben, um Endergebnisse zu liefern:
Die Reihenfolge der Sprints kann geändert werden, um den riskantesten Teil vorzuziehen, aber die gesamte Funktionalität bringt nur dann einen geschäftlichen Nutzen, wenn diese Szenarien bis zu einem gewissen Grad abgedeckt sind. aber nach jedem Sprint haben Sie etwas zu demonstrieren.