Was ist eine User Story?

Was ist eine User Story?

Eine User Story ist eine Notiz, die erfasst, was ein Benutzer tut oder tun muss, als Teil ihrer Arbeit. Jede User Story besteht aus einer kurzen Beschreibung, die aus der Sicht des Benutzers mit natürlicher Sprache verfasst ist. Im Gegensatz zur traditionellen Anforderungserfassung konzentriert sich die User Story darauf, was der Benutzer braucht, anstatt darauf, was das System liefern soll. Dies lässt Raum für weitere Diskussionen über Lösungen und das Ergebnis eines Systems, das tatsächlich in die Geschäftsabläufe der Kunden passt, ihre operativen Probleme löst und vor allem Wert für die Organisation schafft.

Konzept der 3C’s

Die 3C’s beziehen sich auf die drei entscheidenden Aspekte guter User Stories. Das Konzept wurde von Ron Jeffries vorgeschlagen, dem Mit-Erfinder der User Story-Praxis. Heute beziehen wir uns bei der Rede über User Stories meist auf die Art von User Stories, die aus diesen drei Aspekten bestehen.

1. Karte – User Stories werden als Karten verfasst. Jede User Story-Karte enthält einen kurzen Satz mit gerade ausreichendem Text, um alle daran zu erinnern, worum es bei der Geschichte geht.
2. Gespräch – Anforderungen werden durch kontinuierliche Gespräche zwischen Kunden und Entwicklungsteam während des gesamten Softwareprojekts gefunden und verfeinert. Wichtige Ideen und Entscheidungen werden während der Stakeholder-Meetings entdeckt und dokumentiert.
   
3. Bestätigung – oder auch bekannt als Akzeptanzkriterien der User Story. Während der Diskussion der Anforderungen teilt der Kunde dem Analysten nicht nur mit, was er möchte, sondern bestätigt auch unter welchen Bedingungen und Kriterien die funktionierende Software akzeptiert oder abgelehnt wird. Die definierten Fälle werden als Bestätigung verfasst. Beachten Sie, dass die Bestätigung darauf abzielt, die Richtigkeit der Arbeit der entsprechenden User Story zu überprüfen. Es handelt sich nicht um eine Integrationstest.
   

Wie identifiziert man eine User Story?

User Stories sollten gemeinsam mit den Stakeholdern identifiziert werden, vorzugsweise in einer persönlichen Besprechung. Die User Story ist ein Prozess der Anforderungserfassung und kein Prozess der vorab erfolgenden Anforderungsanalyse. Bei den traditionellen Ansätzen der Anforderungserfassung versucht der Systemanalyst, die Bedürfnisse der Kunden zu verstehen und anschließend eine detaillierte Anforderungsspezifikation für das System vorzubereiten. So funktioniert der Ansatz der User Story nicht. Statt eines Dokumentationsprozesses ist die Identifizierung der User Story eher ein Prozess des Notizenmachens. Durch Gespräche mit den Nutzern hören wir zu, verstehen ihre Probleme und Bedürfnisse und notieren ihre Bedürfnisse gleichzeitig als User Stories. Diese User Stories werden dann zur Quelle der Anforderungen. Die Details können anschließend just-in-time ergänzt werden und liefern dem Team während des gesamten Entwicklungsprozesses eine „ausreichende“ Referenz für Anforderungen.

Abbildung von Geschäftsprozessen mit User Stories

BPMN ist eines der leistungsstärksten Werkzeuge für die Geschäftsanalyse und -modellierung. Neben der Prozessverbesserung können wir mit ihm auch User Stories aus jenen Prozessen identifizieren, die automatisiert werden sollen, durch die folgenden Schritte:

1. Modellieren Sie einfach den Arbeitsablauf des Benutzers mit einem BPMN-Geschäftsprozessdiagramm.
2. Gehen Sie das Prozessmodell gemeinsam mit den Benutzern durch.
3. Und analysieren Sie die Geschäftsaktivitäten des Problems und identifizieren Sie dann die User Stories, die mit dem zu automatisierenden Prozess zusammenhängen, was auch als Geschäftsprozess-zu-User-Story-Zuordnung bekannt ist.

Wie schreibt man eine User Story?

Wenn Sie eine User Story schreiben, versuchen Sie, in der Stimme des Benutzers zu schreiben, wie im folgenden Beispiel (oder stellen Sie zumindest sicher, dass das, was Sie geschrieben haben, die folgende Aussage erfüllt):

Als <Rolle> möchte ich <geschäftliches Ziel> erreichen, damit <geschäftlicher Wert/Grund>.

Zum Beispiel: Als Kunde, möchte ich eine SMS erhalten, wenn das Produkt angekommen ist damit ich geh es holen.

wo:

1. <Rolle> stellt die Person, das System, das Subsystem oder jede andere Entität dar, die mit dem zu implementierenden System interagieren wird, um ein Ziel zu erreichen. Er oder sie wird durch die Interaktion mit dem System Werte erlangen.
2. <Geschäftsziel> stellt eine Erwartung des Benutzers dar, die durch die Interaktion mit dem System erreicht werden kann.
3. <Geschäftswert> stellt den Wert hinter der Interaktion mit dem System dar.

Es ist keine Regel, sondern eine Anleitung, die Ihnen hilft, über eine Benutzerstory nachzudenken, indem Sie Folgendes berücksichtigen:

1. Die Benutzerstory bringt Wert für jemanden oder eine bestimmte Partei (z. B. Kunden).
2. Die Benutzerstory erfüllt einen Bedarf des Benutzers (z. B. eine SMS erhalten, wenn das Objekt angekommen ist)
3. Es gibt einen Grund, diese Benutzerstory umzusetzen (z. B. der Kunde kann das von ihm gekaufte Objekt abholen)

Jede Benutzerstory sollte Wert für jemanden bringen. Manchmal ist der Wert jedoch bereits aus dem Geschäftsziel ersichtlich. Den Wert in der Aussage aufzuschreiben, ist mühsam. In solchen Fällen lassen wir ihn einfach weg. Hier sind einige Beispiele:

Als Kunde möchte ich die Zahlung per Kreditkarte tätigendamit ich meine Kreditkarte beim Online-Einkauf verwenden kann.

Als Benutzer möchte ich suchen, indem ich den Namen meines Freundes eingebedamit ich meinen Freund mit ihrem Namen finden kann.

Unabhängig davon, wie Sie eine Benutzerstory schreiben, sollten Sie zwei Dinge im Auge behalten. Erstens muss eine Benutzerstory aus der Sicht des Benutzers geschrieben werden. Zweitens sollte die Beschreibung „nur ausreichend“ sein. Vermeiden Sie, zu viele Details zu Beginn eines Softwareprojekts hinzuzufügen. Später haben Sie die Möglichkeit, die Benutzerstory zu verfeinern und zu konkretisieren, damit sie etwas wird, das die Entwickler bei der Gestaltung und Implementierung nutzen können.

Lebenszyklus einer Benutzerstory

Im weiteren Sinne gibt es sechs Hauptzustände für jede Benutzerstory während eines Softwareprojekts:

1. Ausstehend – Durch die Kommunikation zwischen Benutzer und Projektteam werden Benutzerstories identifiziert. In diesem Zustand verfügt die Benutzerstory lediglich über eine kurze Beschreibung des Benutzerbedarfs. Es gab noch keine detaillierte Diskussion über Anforderungen, keine Systemlogik und keine Bildschirmgestaltung. Tatsächlich dient die Benutzerstory zu diesem Zeitpunkt lediglich als Erinnerung für alle Beteiligten an eine zukünftige Diskussion über die Anforderung des Benutzers, die in dieser Benutzerstory (Karte) formuliert ist. Es ist möglich, dass die Benutzerstory später verworfen wird.
2. Zu erledigen – Durch eine Diskussion zwischen verschiedenen Beteiligten werden die Benutzerstories festgelegt, die in den nächsten Wochen bearbeitet werden sollen, und werden in einen Zeitraum namens Sprint eingereiht. Solche Benutzerstories gelten als im Zustand „Zu erledigen“. In diesem Zustand wurde noch keine detaillierte Diskussion geführt.
3. In Diskussion – Wenn eine Benutzerstory sich im Zustand „In Diskussion“ befindet, wird der Endbenutzer mit dem Entwicklungsteam kommunizieren, um die Anforderungen zu bestätigen und die Akzeptanzkriterien zu definieren. Das Entwicklungsteam wird die Anforderungen oder Entscheidungen als Gesprächsnotizen festhalten. Der UX-Spezialist kann Wireframes oder Storyboards erstellen, damit der Benutzer die vorgeschlagenen Funktionen in visuellen Mock-ups vorab sehen und erleben kann. Dieser Prozess wird als Benutzererfahrungsgestaltung (UX-Design) bezeichnet.
   
4. Entwicklung – Nach Klärung der Anforderungen wird das Entwicklerteam die Funktionen entwerfen und implementieren, um die Wünsche des Nutzers zu erfüllen.
5. Bestätigung – Sobald das Entwicklerteam eine Benutzerstory implementiert hat, wird diese von dem Endbenutzer bestätigt. Ihm/ihm wird Zugang zur Testumgebung oder einem halb-fertigen Softwareprodukt (manchmal auch als Alpha-Version bekannt) gewährt, um die Funktion zu bestätigen. Die Bestätigung erfolgt anhand der Bestätigungsmerkmale, die bei der Detailierung der Benutzerstory festgelegt wurden. Bis zur Bestätigung gilt die Benutzerstory als im Zustand „Bestätigung“.
6. Abgeschlossen – Schließlich wird die Funktion als abgeschlossen bestätigt, und die Benutzerstory gilt als im Zustand „Abgeschlossen“. Typischerweise ist dies das Ende der Benutzerstory. Falls der Nutzer eine neue Anforderung hat, sei es eine neue Funktion oder eine Verbesserung der abgeschlossenen Benutzerstory, wird das Team für die nächste Iteration eine neue Benutzerstory erstellen.

Benutzerstory detaillieren – Wann und warum?

Ein wesentlicher Unterschied zwischen Benutzerstories und traditionellen Ansätzen zur Erfassung von Anforderungen ist, dass der Ansatz der Benutzerstory die Identifizierung von Problem und Lösung in zwei Schritte aufteilt, die zu unterschiedlichen Zeitpunkten eines Softwareprojekts durchgeführt werden. Während Probleme und eine kurze Einsicht in die Nutzeranforderungen zu Beginn des Softwareprojekts ermittelt werden, werden die Details der Systemanforderungen erst kurz vor Beginn der Gestaltung und Implementierung ermittelt. Hier sind einige Vorteile dieser Vorgehensweise:

1. Kann auf aktuelle Nutzerbedürfnisse reagieren, da die Anforderungen unmittelbar vor der Implementierung detailliert werden, anstatt alles zu Beginn abzuschließen.
2. Kann die richtigen Anforderungen leichter identifizieren, da sowohl Probleme als auch Lösungen ausführlich diskutiert werden. Bei traditionellen Ansätzen müssen die Details aller Anforderungen zu Beginn eines Projekts ermittelt werden, wodurch die „vorab festgelegten Anforderungen“ im Laufe der Zeit verändert werden könnten, was zu erheblichem Aufwand bei der Analyse führt.
3. – Andererseits können Benutzerstories, die sich als ungültig erweisen, leicht verworfen werden. Sie verlieren nicht viel Zeit an vorhergehender Untersuchung und Dokumentation

Wie nutzt man Benutzerstories effektiv?

Genau wie viele andere Softwareentwicklungsmethoden, können Sie mit einer korrekten Anwendung von Benutzerstories in Ihrem Softwareprojekt ein qualitativ hochwertiges System entwickeln und das Vertrauen sowie die Zufriedenheit der Kunden gewinnen. Beachten Sie bei der Anwendung von Benutzerstories folgende Punkte:

1. Halten Sie die Beschreibung der Benutzerstory kurz.
2. Denken Sie beim Schreiben einer Benutzerstory von der Perspektive des Endbenutzers aus.
3. Ein (UML-)Use Case stellt ein Geschäftsziel dar. Die Möglichkeit, Benutzerstories unter Use Cases zu gruppieren, ermöglicht es Ihnen, sicherzustellen, dass eine Benutzerstory ein Geschäftsziel erfüllt, mit anderen Worten, dass sie dasselbe Systemziel verfolgt. Es dient als Platzhalter, um Benutzerstories effizienter zu verwalten, zu planen und zu priorisieren.
4. Bestätigungsmerkmale müssen definiert werden, bevor Sie mit der Entwicklung beginnen
5. Schätzen Sie die Benutzerstory vor der Implementierung, um sicherzustellen, dass die Arbeitsbelastung Ihres Teams unter Kontrolle bleibt.
6. Anforderungen werden gemeinsam mit den Endbenutzern ermittelt, nicht durch den Endbenutzer allein oder ausschließlich durch das Entwicklerteam. Eine gute Beziehung zu den Endbenutzern ist für beide Seiten eine Win-Win-Situation.
7. Kommunikation ist immer wichtig, um zu verstehen, was der Endbenutzer möchte.

Visual Paradigm bietet alle Tools, die Sie benötigen für agile Softwareentwicklung, einschließlich UML-Use-Case-Diagramm-Tool, (agile) Benutzerstory, Sprint, Storyboard und Wireframes für UX-Design, Aufgabenverwaltungstool, usw.