User Stories beim Neuanfang

Eine User Story wird Ihnen kein veröffentlichbares Produkt liefern

das einen gewissen Wert für einen Endbenutzer darstellt

Diese Klausel wird hinzugefügt, um die Denkweise früherer Wasserfallpraktiken zu überwinden. Allein die Analyse oder das Design allein durchzuführen, ist keine gültige User Story. Die Geschichte muss zu einem lieferfähigen Code führen, der für den Benutzer einen Wert darstellt.

kann während eines Sprints geliefert werden

Diese Klausel wird hinzugefügt, um Stories klein zu halten, damit sie innerhalb eines Sprints vollständig abgeschlossen werden können.

Was Sie suchen, ist das, was im Volksmund als Minimum Viable Product (MVP) bekannt ist. MVP ist ein Produkt mit gerade genug Funktionen, um Early-Adopter-Kunden anzuziehen und eine Produktidee früh im Produktentwicklungszyklus zu validieren. Es gibt viele Beispiele für MVPs wie dieses über Zappos.

Formulieren Sie also Ihr MVP und schreiben Sie so viele User Stories, wie Sie dafür benötigen. Hier können Sie mehr über das Aufteilen von User Stories in kleinere, das Schreiben von Zufriedenheitsbedingungen usw. lesen.

Halten Sie sich nicht damit auf, die perfekte User Story zu schreiben. Wenn es sich um ein neues Produkt handelt, das Sie von Grund auf neu entwickeln, konzentrieren Sie sich stattdessen auf:

• Definition eines großen Bildes dessen, was das Produkt tun sollte;
• Teilen Sie diese Vision in Teile, Aktionen und Akteure auf (Sie können dafür eine Technik namens User Story Mapping verwenden und Epics und User Stories erstellen);
• Platzieren Sie diese Epics und Stories in einem Backlog und priorisieren und ordnen Sie sie basierend darauf, was zuerst den größten Wert bringen würde;
• Führen Sie ein Verfeinerungsmeeting durch, um den oberen Teil des Rückstands in feinere Stücke aufzuteilen.
• Finden Sie heraus, wie viele dieser Teile von der Spitze des Rückstands Sie in einen Sprint (wenn Sie Iterationen durchführen) oder in einer angemessenen Zeitspanne unterbringen könnten. Dies ist der eigentliche Grund, warum Sie User Stories in die „kleinste Menge an Arbeit“ aufteilen möchten oder dass sie die INVEST- Eigenschaft haben sollten, damit Sie schnell und konstant funktionierende Dinge liefern.
• Zunächst müssen die von Ihnen identifizierten User Stories möglicherweise etwas sein, das mit Scheindaten oder Wireframes anstelle einer voll funktionsfähigen Benutzeroberfläche oder nur einem minimal funktionierenden Benutzerfluss usw. erstellt wurde. Die Idee ist, etwas zu haben, das funktioniert und gezeigt werden kann Stakeholder, um Feedback zu sammeln, damit Sie lernen und das Gelernte nutzen, um herauszufinden, was als Nächstes aufgebaut werden soll. Wie in der akzeptierten Antwort erwähnt, besteht der Zweck nicht unbedingt darin, von Anfang an ein veröffentlichungsfähiges Produkt zu erstellen. Wenn Sie ein komplexes Produkt haben, für dessen Verwendung einige Funktionen vorhanden sein müssen, erhalten Sie möglicherweise in den ersten paar Sprints nicht etwas voll funktionsfähiges, aber Sie können trotzdem etwas bauen.
• spülen und wiederholen, um darüber hinaus schrittweise Funktionalität hinzuzufügen und einige Versionen zu erhalten, die Sie für Benutzer freigeben können.

Einige Beispiele für „Sprint 1“-Geschichten für eine E-Commerce-Website:

• Als Neukunde möchte ich die Möglichkeit haben, mich für ein Konto anzumelden, damit ich einkaufen kann
• Als potenzieller Kunde möchte ich in einem Produktkatalog stöbern

Einige Beispiele für eine HR-Anwendung:

• Als HR-Benutzer möchte ich mich anmelden können
• Als HR-Benutzer möchte ich die Daten eines Mitarbeiters nach Mitarbeiternummer abrufen

Um einige grundlegende Tabellen zu erstellen, die diese Geschichten unterstützen, dauert es nur ein oder zwei Stunden. Die Erstellung einer Benutzeroberfläche dauert etwas länger, aber in einem 2-wöchigen Sprint kann sicherlich etwas perfekt Benutzbares erreicht werden. Dies sind sehr kleine Wertzuwächse, die jedoch für das Produkt unerlässlich sind.

Ein weiterer relevanter Punkt ist, dass es ziemlich ungewöhnlich ist, komplett bei Null anzufangen. In der Regel verfügen Sie über vorhandene Daten, Dienste, Codebibliotheken und andere technische Assets, auf denen Sie aufbauen können.

Ein Teil des Problems besteht darin, zu definieren, was „geliefert“ bedeutet. Bedeutet es integriert und demonstriert? Bedeutet es eingesetzt? Bedeutet das, dass ein Feature-Flag aktiviert wurde? Je nach Kontext, in dem das Team arbeitet, könnte dies eine dieser Bedeutungen haben. Die Definition könnte sich auch im Laufe der Zeit ändern, wenn das Team seine Fähigkeiten zum Entwerfen, Entwickeln, Testen, Bereitstellen und Betreiben des Systems verfeinert.

Es gibt auch Möglichkeiten, die Arbeit auf verschiedene Arten aufzuteilen, die eine bessere Demonstration und schnelles Feedback ermöglichen. Sie brauchen nicht unbedingt eine End-to-End-Erfahrung, um Feedback zu erhalten. Am Beispiel „Produktliste sortieren“ können Sie eine Benutzeroberfläche auf einem bestimmten Bildschirm oder einer bestimmten Seite demonstrieren, die im Frontend mit Daten vorbelegt ist. Sie könnten noch einen Schritt weiter gehen und das Front-End Daten von einem Back-End laden lassen, aber eine einfacher lesbare Datenquelle wie eine Textdatei verwenden, um die API zwischen einer Front-End- und einer Back-End-Komponente auszulagern. Oder Sie könnten noch einen Schritt weiter gehen und vorab Daten in einer Datenbank anlegen. Alles andere könnte die Fähigkeit erfordern, Daten in der Datenbank hinzuzufügen und/oder zu bearbeiten, was wahrscheinlich andere Geschichten wären.

Ich würde nicht empfehlen, Geschichten anders früh als später zu verwenden. Ich würde erkennen, dass es andere Arten von Geschichten als Benutzergeschichten geben kann, wie z. B. verschiedene Arten von technischen Befähigungsgeschichten. Eine Geschichte ist im Grunde nur ein Platzhalter für ein Gespräch. User Stories konzentrieren sich auf den Kunden oder Endbenutzer, aber es gibt keinen Grund, warum Sie keine Platzhalter für technische Gespräche über das Erstellen von Datenbanken, APIs und Leistung haben sollten. Ich würde auch empfehlen, sich darauf zu konzentrieren, die Feedback-Schleife zu straffen, sei es das Einholen von Feedback von Benutzern auf der Benutzeroberfläche oder von Entwicklern zu den technischen Entscheidungen, um sicherzustellen, dass Sie auf dem richtigen Weg sind.

Ich denke, es ist auch fair zu sagen: „Manchmal werden User Stories (und Scrum im Allgemeinen) diesen Idealen gerecht, und manchmal eben nicht.“ Das Konzept einer „User Story“ ist wirklich nur ein Leitfaden, der Ihnen hilft, die Arbeit in kleine Einheiten zu unterteilen und diese Einheiten sehr eng mit Dingen zu verknüpfen, die der Endbenutzer tatsächlich beobachten wird. Aber gerade in der Anfangsphase eines umfangreichen Projekts, das von Grund auf neu gestartet wird, macht das manchmal nicht viel Sinn. Und das ist in Ordnung.

Zum Beispiel: ein Haus bauen. Was ist die "Benutzergeschichte" all dieser sorgfältig platzierten Blöcke und Teile von PVC-Rohren, die überall herausragen? Nun, es gibt sorgfältig erstellte Hauspläne, aber nicht zu viel von einer "Geschichte". Alle Arbeiten, die Sie sehen, werden einen möglichen Zweck haben und müssen jetzt unbedingt dort platziert werden, und zwar sehr genau dort, wo sie sind. Aber „User Stories allein“ wäre kein guter Weg, um dieses Projekt in diesen frühen, grundlegenden Phasen zu planen oder auszuführen. Stattdessen haben Sie einen "Wasserfall", der von einem lizenzierten Architekten lange im Voraus geplant wurde. Denn das macht an dieser Stelle am meisten Sinn.

Die Metapher der „User Stories“ ist auch in frühen Phasen noch sehr nützlich und wichtig, aber sie können das Projekt nicht streng leiten , bis die Grundlagen gelegt sind.

Das Problem, auf das Sie stoßen, ist, dass Sie mit einer Lösung im Sinn beginnen. Dann zerlegen Sie diese Lösung in ihre Einzelteile. Das Problem, das Sie ansprechen, ist nicht wirklich eines mit User Stories. Es ist: Wie lösen Sie schnell ein Teil eines Benutzerbedarfs, damit Sie mehr über diesen Bedarf erfahren können.

Letzte Woche habe ich eine Marktumfrage-App in 5 Stunden fertiggestellt. Ich habe keine User Story verwendet, aber wenn ich es täte, würde es ungefähr so ​​​​aussehen:

Als Analyst möchte ich potenziellen Kunden 2 Aussagen zur Produktfähigkeit präsentieren und sie diejenige auswählen lassen, die sie am meisten anspricht, damit ich sehen kann, welche Fähigkeiten für meinen Markt am wichtigsten sind.

Dies war Datenbank, Logik, Benutzeroberfläche, Bereitstellung.

Wir haben es am nächsten Morgen für eine interne Demonstration verwendet, und es ist potenziell lieferbar in dem Sinne, dass ich es könnte, wenn ich mich entscheide, es wirklich mit gelesenen Kunden zu verwenden.

Ich habe mit mehreren Teams zusammengearbeitet, die neue Apps in nur ein oder zwei Tagen bereitstellen. Nun, es kann viele Dinge in Ihrer Umgebung geben, die Sie davon abhalten, dies zu erreichen, und Sie müssen entscheiden, ob die Möglichkeit, so schnell zu liefern, Ihnen einen Nutzen bringt, der die Kosten wert ist, dies in Ihrem Kontext zu ermöglichen. Aber es ist absolut machbar.