Mein Team und ich kämpfen damit, eine User Story aufzuschlüsseln, die wir auf 8 Punkte geschätzt haben.
Die Userstory ist:
"Ein Benutzer kann sich über ein Registrierungsformular bei der App anmelden, damit ihm der Zugriff gewährt wird"
Der Grund, warum wir 8 Punkte veranschlagt haben, ist, dass es viele Akzeptanztests gibt.
Ich versuche, dem INVEST-Modell zu folgen, das vorschlägt, dass Geschichten klein sein sollten, um in einen Sprint zu passen. Ich kann nicht herausfinden, wie ich diese "Anmelden"-Geschichte in kleinere Geschichten unterteilen soll, die für die Benutzer von Wert sind. Irgendwelche Vorschläge?
Ich würde das Team durch das Ablaufdiagramm der Story-Aufteilung führen . Oft hat jemand eine Idee, wie man es aufteilt, es ist oft besser, das gesamte Team zum Aufteilen zu nutzen, als nur zu versuchen, es selbst aufzuteilen. Split während der Planungs- oder Verfeinerungssitzungen.
Eine Aufteilung könnte hier etwa so aussehen:
Die Idee ist, Feedback von Benutzern zu erhalten, aber auch Machbarkeitslernen, z. B. kann das Team es gebaut haben. Ich denke, die vorgeschlagenen Aufteilungen hier werden sicherlich Benutzerfeedback und / oder Erkenntnisse erhalten.
Wenn eine 8 weniger als 33 % deines Sprints ausmacht, mach dir vielleicht nicht allzu viele Gedanken darüber. Sicher, 1/6 oder kleinere Geschichten sind ideal, aber ab und zu eine Geschichte in 1/3-Größe ist nicht so schlimm. Stellen Sie nur sicher, dass es Ihre erste Geschichte des Sprints ist, damit Sie am Ende des Sprints nicht mit einer halbfertigen Geschichte zurückbleiben.
Eine letzte Anmerkung, versuchen Sie nicht voreilig zu splitten, warten Sie so lange wie möglich. Geschichten aufzuteilen, die Sie vielleicht nie aufgreifen werden, ist eine große Verschwendung.
Generell versuchen wir Implementierungsdetails in einer User Story zu vermeiden, also statt
Ein Benutzer kann sich über ein Registrierungsformular bei der App anmelden, damit ihm der Zugang gewährt wird
Ich würde vorschlagen, Ihre ursprüngliche Geschichte ist:
Als Benutzer möchte ich mich bei der Anwendung anmelden, um Zugriff zu erhalten
Bei so etwas wie der Registrierung würde ich es oft auf das Nötigste und Nice-to-haves herunterbrechen.
Zum Beispiel:
Als Benutzer möchte ich mich bei der Anwendung anmelden, um Zugriff zu erhalten
Die grundlegende Geschichte, das ist das Nötigste, sich anzumelden, vielleicht nur ihren Namen zu erfassen.
Als Benutzer möchte ich, dass das System meine Daten speichert, damit ich sie nicht erneut eingeben muss
Eine Bausteingeschichte, die bedeutet, dass wir während der Registrierung mehr Details des Benutzers erfassen.
Als Benutzer möchte ich meine Dateneingabe validieren lassen, damit ich nicht versehentlich falsche Werte verwende
Verwenden Sie diese, um eine Validierung hinzuzufügen, z. B. das Überprüfen von Postleitzahlen usw.
Als Benutzer möchte ich sicher sein, dass mein Passwort schwer zu knacken ist, damit mein Konto sicher ist
Verwenden Sie diesen, um Prüfungen auf Kennwortschwierigkeiten hinzuzufügen.
...usw.
Sie werden oft feststellen, dass Akzeptanzkriterien in kleinere Geschichten umgewandelt werden können, wenn Sie an den Wert denken, den sie aus Sicht des Benutzers bieten.
Es gibt viele Möglichkeiten, User Stories aufzuschlüsseln, aber da Sie viele Akzeptanztests erwähnt haben, wäre meine erste Vermutung, die Akzeptanzkriterien in separat zu liefernde Segmente aufzuteilen. Haben Sie beispielsweise eine Adressvalidierung in Ihren Akzeptanzkriterien? Das kann seine eigene Geschichte sein:
Wie eine App zugibt, möchte ich, dass der Registrierungsprozess Adressen validiert, um die Anzahl betrügerischer Kontoanfragen zu reduzieren.
Ich würde auch nachsehen, was die Mindestinformationen aus dem Formular sind, die für die Registrierung erforderlich sind. Es wirft für mich immer ein bisschen eine rote Fahne auf, wenn ein Formular oder Bildschirm im Voraus bereitgestellt wird. Normalerweise bedeutet dies, dass wir viele verwandte Funktionen in einem Backlog-Element gruppieren, weil wir an diesem Artefakt verankert sind. Es ist möglich, dass Sie damit beginnen könnten:
„Als Neukunde kann ich mich registrieren, um die App zu nutzen, damit ich auf gesperrte Funktionen zugreifen kann.“
Und dies könnte nach einem Benutzernamen, Passwort und einer E-Mail-Adresse fragen. Dann:
„Als Neukunde kann ich meinen vollständigen Namen in den Registrierungsprozess eingeben, damit ich nicht zu einem anderen Bildschirm gehen und ihn später hinzufügen muss.“
Abgesehen davon, dass die Geschichte weiter aufgeschlüsselt wird, zwingt es den PO und das Team, wirklich zu verstehen, warum ein Benutzer diese Funktion haben möchte. Ich habe das so-das für das letzte Mal dreimal umgeschrieben, um herauszufinden, warum der Benutzer diese Informationen bei der Registrierung eigentlich angeben möchte.
Wie in einem Kommentar erwähnt, bräuchte ich mehr Details, was dies so schwierig macht - dies würde uns Ideen geben, wo wir uns aufteilen können. Aber abgesehen davon gibt es einen Weg: die Präsentation vom Backend-Betrieb zu trennen. Das heißt, wenn Sie diese Aufgabe nicht in einem Sprint erledigen können, dann implementieren Sie zuerst das Backend - so könnte sich ein Benutzer theoretisch mit einer einfachen POST-Anfrage anmelden; keine GUI implementieren, keine detaillierten Fehlermeldungen etc.
Konzentrieren Sie sich darauf, diesen API-Aufruf so sicher zu machen, wie er sein sollte, mit Funktionen wie dem Erzwingen von HTTPS, dem sicheren Speichern/Überprüfen von Passwörtern (dh mit einem guten Hash, nicht mit Klartext), dem Bereitstellen Ihrer Cookies auf gute Weise und so weiter. Entscheiden Sie, welche Art von Sitzungsverwaltung Sie durchführen möchten (serverseitig in einer DB oder nur clientseitig in einem ausreichend verschlüsselten Cookie). Wenn Sie die kompliziertere Version in Ihrem Sprint nicht bewältigen können, entscheiden Sie sich stattdessen für die einfachere und kommen Sie später darauf zurück.
Versenden Sie keine Version, die wesentliche Sicherheitsfunktionen vermisst. Wenn Sie das nicht einmal in einem Sprint schaffen, wird es schwierig, etwas zu verbessern, und Sie müssen Ihre Sprintlänge genau unter die Lupe nehmen ...
Fügen Sie im nächsten Sprint den GUI-Teil hinzu; Von diesem Zeitpunkt an können Sie leichter nur kleine Schritte liefern. Beispielsweise können Sie in der ersten Version der Login-GUI nur den "positiven" Pfad implementieren und alle Unklarheiten in Bezug auf Fehlerrückmeldungen überspringen. Bei Problemen können nur allgemeine Fehlermeldungen angezeigt werden (oder sogar keine Fehlermeldungen, sondern nur eine Weiterleitung zum leeren Formular, wenn Sie dies wünschen).
AnoE