Das Projektteam arbeitet agil und liefert routinemäßig Teile der Software, die in User Stories beschrieben werden. Bei jedem Sprint wird eine funktionierende Software mit einigen zusätzlichen Funktionen geliefert.
Der Vor- und Nachteil von User Stories besteht darin, dass sie abgeschlossene Funktionen beschreiben. Das Entwickeln von Code für User Story hat mehrere Unteraufgaben, und das Problem ist, dass einige Aufgaben nicht innerhalb von Sprint geliefert werden können, oft bis zum Ende des Projekts. Solche Aufgaben sind wie: Integration mit API von Drittanbietern, Abhängigkeit von einem externen System.
Zum Beispiel Webentwicklungsprojekt:
WEB-122: „Als Kunde sehe ich den Bestellbestätigungsbildschirm, auf dem ich die bestellten Artikel, den Gesamtbetrag und die Steuerinformationen überprüfen kann. Ich klicke auf die Schaltfläche Jetzt bezahlen, um zur Seite SomeExtravagantPaymentService weitergeleitet zu werden und die Zahlung abzuschließen.“
Problem: Der Kunde verhandelt nur mit SomeExtravagantPaymentService und kann keine Anmeldedaten bereitstellen. Außerdem bietet der Dienst keine Beta- oder Sandbox-Option für SMS (in Europa ist es ziemlich üblich) – Abhängigkeit von API eines Drittanbieters.
Zum Beispiel Hausbauprojekt:
DWELL-234: "Ich möchte Strom und Glühbirnen im Keller installiert haben, gesteuert durch einen Schalter".
Problem: Selbst wenn Schalter und Glühbirnen ordnungsgemäß installiert sind, kann diese Benutzergeschichte nicht fertiggestellt und getestet werden, bis das Elektrizitätsunternehmen das Haus an die Stromleitung anschließt, was in späteren Phasen der Entwicklung passieren kann. Abhängigkeit von externem System.
Das Problem mit beschriebenen User Stories ist, dass solche Stories nicht in mehreren Sprints fertiggestellt werden können und sich von Sprint zu Sprint hinziehen. Der Kunde erhält nach dem Sprint kein fertiges Produkt. Wie konnte diese Situation bewältigt werden?
Das Problem mit beschriebenen User Stories ist, dass solche Stories nicht in mehreren Sprints fertiggestellt werden können und sich von Sprint zu Sprint hinziehen.
Sie müssen Ihre Geschichten mithilfe des INVEST-Modells weiter aufschlüsseln . Schreiben Sie Ihre Geschichten so, dass jede in sich abgeschlossen ist und keine oder nur eine minimale Abhängigkeit von anderen Faktoren besteht.
Ihre Geschichte kann also wie folgt umgeschrieben werden:
WEB-122a: "Als Kunde möchte ich meine Bestellung aufgeben, damit ich meine gewünschten Artikel bekomme"
WEB-122b: "Als Kunde möchte ich meine Bestellung überprüfen, damit ich die bestellten Artikel, den Gesamtbetrag und die Steuerinformationen überprüfen kann."
WEB-122: „Als Kunde möchte ich meine Bestellung bezahlen, damit meine Bestellung bearbeitet (und an mich geliefert) werden kann.“
Im Idealfall sollte eine User Story komplett in einem Sprint geliefert werden, sie sollte sich nicht in die Länge ziehen.
Ich denke, das Problem ist, dass Sie die Geschichte nicht aufgeschlüsselt haben. Wenn Sie eine Geschichte schreiben, versuchen Sie, Ihre hohen Anforderungen auf die kleinstmögliche Ebene zu brechen.
Beispiel in dem von Ihnen genannten Fall:
Als Kunde sehe ich den Bestellbestätigungsbildschirm, auf dem ich die bestellten Artikel, den Gesamtbetrag und die Steuerinformationen überprüfen kann. Ich klicke auf die Schaltfläche Jetzt bezahlen, um zur Seite SomeExtravagantPaymentService weitergeleitet zu werden, und schließe die Zahlung ab
Die Geschichte kann weiter in kleinere Geschichten unterteilt werden wie:
In diesem Fall können Sie, sobald Sie mit dem Bestätigungsbildschirm fertig sind, diese an Ihren Kunden übermitteln. Sie können danach die SomeExtravagantPaymentService-Seite aufrufen, sobald Ihr Kunde dies bestätigt hat. Bis dahin befindet es sich im Product Backlog und wird nicht in den Sprint aufgenommen.
Auf diese Weise behalten Sie den Überblick über Ihre Story und können Ihrem Kunden am Ende des Sprints vollständige User Stories liefern und vermeiden, eine Aufgabe in den nächsten Sprint zu übertragen