User Story(s) für die mehrstufige Benutzeranmeldung

Zunächst einmal möchte ich darauf hinweisen, dass Sie meiner Meinung nach mit dieser Geschichte in die falsche Richtung gehen.

Wolltest du dich schon immer für etwas anmelden ? Wäre es nicht besser, das Ding einfach nutzen zu können , ohne sich mühsam anmelden oder einloggen zu müssen? „Warum kann (Unternehmen X) den privaten Bereich nicht einfach öffentlich machen?“

Stellen Sie zuerst fest , wer der Anforderer dieser Geschichte wirklich ist. Oder ändern Sie alternativ die Anforderung. Zum Beispiel so etwas wie:

Als Systemadministrator muss ich sicherstellen, dass wir nicht anfällig sind für...

oder

Als Benutzer möchte ich nicht, dass andere Benutzer meine persönlichen Daten sehen können.

Beachten Sie, dass diese nicht einmal die Möglichkeit der Anmeldung und Anmeldung eingebaut haben. Dies könnte möglicherweise auf andere Weise erreicht werden . Das ist gut, denn das Wie von Aufgaben sollte nicht mit dem Was und Warum von Geschichten gekoppelt werden.

Sobald Sie einen echten Geschäftsbedarf richtig identifiziert haben, einschließlich der Frage, wer ihn haben will/braucht und warum , sollten Sie einen guten Ruf haben.

Danach können Sie damit beginnen, das Wie zu Aufgaben unter dieser Story hinzuzufügen, aber das hat nichts mit der Definition der Story selbst zu tun .

Eine gute Idee wäre, über die Akzeptanzkriterien für Ihre User Story nachzudenken. Wenn Sie diese aufschreiben, würden Sie wahrscheinlich eine große Anzahl von ihnen sehen, die Ihnen Hinweise geben, wie Sie Ihre User Story aufteilen können.

Zum Beispiel „als neuer Benutzer“, was sind die Akzeptanzkriterien dafür? Irgendein neuer Benutzer? Benutzer auf ihrem Handy? auf Tabletten? Können sie anrufen und jemand hilft ihnen am Telefon? ein neuer Benutzer auf der privaten Seite oder ein neuer Benutzer ohne Informationen über ihn/sie in Ihrem System.

Die anderen Antworten deckten so ziemlich alles ab, ich möchte nur ein paar Dinge hinzufügen:

• Erwägen Sie, am Ende eine „...damit...“-Klausel hinzuzufügen, da dies Ihren Umfang einschränken könnte, um spezifischer zu sein.
• Erwägen Sie die Überprüfung eines Spickzettels wie hier beschrieben . Wenden Sie sich bei Bedarf an die Entwickler in Ihrem Team, um Ihnen zu helfen, oder an BAs in Ihrer Nähe, je nach den geschäftlichen Anforderungen.

Binden Sie das gesamte Team in das Schreiben von User Stories ein

Im künftigen Webportal geht der Erstellung eines neuen Benutzerkontos systematisch ein Schritt-für-Schritt-Fragebogen mit 10-20 Fragen (meist Multiple-Choice) voraus. Sobald der Fragebogen ausgefüllt ist, gibt der neue Benutzer eine E-Mail-Adresse und ein Passwort ein und sofern diese gültig sind, wird das Benutzerkonto erstellt und der neue Benutzer auf eine Startseite / Dashboard-Ansicht umgeleitet.

Wiederholen Sie mir nach: „User Stories sind keine Spezifikationen!“ Sie haben Probleme, weil Sie versuchen, eine detaillierte Spezifikation mit dem Standardformat Connextra As a ... I want ... so that ... zu erstellen , aber so sollen User Stories nicht erstellt oder verwendet werden.

Während eine User Story den INVEST-Kriterien folgen sollte , besteht das Problem in diesem Fall nicht so sehr darin, sie granularer zu machen; Es geht darum, die richtige Granularität zu finden, um mit dem Team effektiv Chunks in Sprint-Größe zu erstellen. Dazu müssen Sie ein paar Dinge tun:

1. Beziehen Sie das Team in die Erstellung der Geschichten ein.

   Während Sie die Geschichten und die möglichen Implementierungsdetails mit dem Rest des Teams besprechen, werden Sie herausfinden, wie Sie Ihr Epic am besten erfassen und zerlegen können. Möglicherweise stellen Sie fest, dass Sie eine oder mehrere Geschichten haben, entdecken Sie Geschichten oder Abhängigkeiten, die Sie in Ihrer Rolle als Product Owner nicht berücksichtigt haben, und stellen Sie dem Team Kontext zur Verfügung.

2. Stellen Sie sicher, dass jede Story in einen einzelnen Sprint passt.

   Eine einzelne User Story muss in einen einzelnen Sprint passen. Wenn es größer als ein Sprint ist, ist es wahrscheinlich ein Thema oder Epic und sollte zerlegt werden. Es kann kleiner sein, aber ob es sich um eine große Geschichte oder eine Reihe kleiner Geschichten handelt, sollte außer Ihrem Risikograd kaum einen Unterschied machen.

   Kleinere Storys ermöglichen es Ihnen, Fortschritte zu erzielen, selbst wenn das Sprint-Ziel nicht erreicht wird, während eine große Story die Vorausplanung und Dekomposition gegen die Just-in-Time-Planung durch das Team innerhalb des Sprints eintauscht. Dies kann das Risiko nicht gelieferter Storys oder des Nichterreichens des Sprint-Ziels erhöhen, aber nicht jede Story muss weniger als 13 Komplexitätspunkte aufweisen.

3. Stellen Sie sicher, dass jede Geschichte testbar ist.

   Die Verwendung von Test-First-Design anstelle von überarbeiteten Spezifikationen ist im Allgemeinen der beste Weg, um Arbeit zu zerlegen und sicherzustellen, dass sie der Definition of Done des Teams entspricht. Dies gemeinsam zu tun ist der effektivste Weg, um die richtigen Tests zu definieren.

Möglicherweise müssen Sie einen Sprint der Entwicklung des Inhalts des Product Backlogs und der Verfeinerung von Stories für die nächsten ein oder zwei Sprint-Planungsmeetings widmen. Das sollte ausreichen, um die Pumpe vorzubereiten, und es ist in Ordnung, dies bei Bedarf dem Projekt zuzuweisen.

Erwägen Sie, die folgende User Story zu Ihrer Top-Story im Backlog zu machen:

Als Scrum-Team
wollen wir die User Storys für das Login-Epos gemeinsam definieren
, damit wir die richtige Granularität erreichen und ausreichend Kontext schaffen.

Diese Art von Geschichte ist gleichermaßen akzeptabel für die Projektinitiierung, „Sprint Zero“ oder Backlog Refinement. Sobald das gesamte Team das Epic oder Thema aktiv diskutiert, sollte die erforderliche Granularität selbstverständlich werden.