Wie formatiere ich negative User Stories?

9

Dem formalen User Story-Stil folgen:

Da <user>will ich das <goal>so <benefit>.

Unser Team hat Schwierigkeiten, Dinge auszudrücken, bei denen die Eigentümer des Systems den Wunsch haben, etwas zu tun, das sich negativ auf den Benutzer auswirkt.

Nehmen wir als willkürliches Beispiel an, der Eigentümer möchte, dass das System Kunden jedes Mal belastet, wenn sie ihre E-Mails abrufen.

Nach dem formalen Stil von User Stories können Sie dies wie folgt schreiben:

Als Kunde möchte ich jedes Mal belastet werden, wenn ich meine E-Mails überprüfe, damit der Systembesitzer seinen Umsatz steigern kann.

Offensichtlich hat der Kunde keine Lust, belastet zu werden; Die Geschichte wird zum Lesen erschütternd und die Sprache steht den Tatsachen im Weg.

Wie könnte die Anforderung anders geschrieben werden?

user-story Paul Turner
quelle
1
Haben Sie Probleme beim Schreiben der Geschichte oder beim Erstellen von etwas, das Sie nicht für ethisch halten?
JeffO

Antworten:

24

Wenn die Zahlung von Geld die Kunden negativ beeinflusst, würden sie diesen Service nicht nutzen. Mach dir darüber keine Sorgen. Außerdem zahlen Benutzer (normalerweise) kein Geld, weil sie Systembesitzern helfen möchten, sondern weil sie einen Dienst im Austausch wünschen, sodass Ihr Beispiel wirklich so aussehen sollte:

Als Kunde möchte ich jedes Mal belastet werden, wenn ich meine E-Mails überprüfe, damit ich Service X im Austausch erhalten kann.

Außerdem werden User Stories aus der Perspektive aller Benutzerrollen geschrieben, nicht nur der Endkunden. Erwägen Sie, diese aus der Sicht des Systembesitzers als eine andere Benutzerrolle zu schreiben:

Als Systembesitzer möchte ich, dass Kunden jedes Mal belastet werden, wenn sie ihre E-Mails abrufen, damit ich meinen Umsatz steigern kann.

Ein allgemeiner Rat: Konzentrieren Sie sich auf den positiven Teil der User Story und überdenken Sie ihn nicht. Sie sollten einfach sein. Wenn die User Story sehr negativ ist und nicht vermieden werden kann, liegt das Problem in der Konzeption des Systems. In diesem Fall spielt es keine Rolle, was Sie auf Ihre Karten schreiben.

Goran Jovic
quelle
Die Gefahr beim Schreiben aus der Sicht des Systembesitzers besteht darin, dass alle Geschichten im Wesentlichen von den Besitzern stammen und der Wert des userTeils der Geschichte abnimmt.
Paul Turner
@ProgrammingHero: Das ist nur eine Alternative, die ich vorgeschlagen habe. :)
Goran Jovic
5
@ProgrammingHero Ich denke, Sie können auf Semantik aufgehängt werden. Der Systembesitzer kann der Besitzer des Systems sein (z. B. Product Owner). Dieser Systembesitzer kann auch eine eindeutige Benutzerrolle in der Software selbst sein. Die User Story sollte gegen die Rolle oder den Benutzertyp geschrieben werden, der zufällig der Systembesitzer ist, wobei die Person als Systembesitzer eine Person in der Product Owner-Rolle eines Softwareentwicklungsteams ist, was in Wirklichkeit völlig anders ist.
maple_shaft
4
@Programming Here: Denken Sie daran, dass die Geschichte existiert, um Ihnen zu dienen - um Ihnen zu sagen , warum die Funktion benötigt wird und wem sie zugute kommt. Wenn es dem Unternehmen zugute kommt, sagen Sie dies in der Geschichte, damit dem Team klar ist, warum die Funktion vorhanden ist. Die Karte dient unter anderem der Transparenz. Zu wissen, dass Sie etwas tun, das dem Benutzer nicht zugute kommt, ist eine gute Sache .
Bryan Oakley
11

Das <user>muss nicht der Endbenutzer sein - es kann leicht der Geschäftsinhaber / Systembesitzer sein:

As a system owner
I want to charge customers
So that the business can pay my programmers
Oded
quelle
Ich denke nicht, dass es richtig ist, den Systembesitzer als Benutzer zu haben. Jede Geschichte könnte aus ihrer Perspektive geschrieben werden, wenn dieser Ansatz gültig ist.
Paul Turner
Mein Verständnis war auch, dass die Geschichte eher auf etwas reagiert, das der Benutzer tut (seine E-Mails abrufen), als auf etwas, das der Systembesitzer tut, sodass es aus der Sicht des Benutzers korrekter erscheint, sie zu haben.
JohnL
4
@ JohnL: Die Geschichte reagiert nicht auf irgendetwas. Es ist eine Erklärung, warum Sie die Funktion implementieren. Obwohl es den Anschein hat, dass der Benutzer nicht davon profitiert, tun sie dies normalerweise. Selbst in diesem speziellen Fall profitieren sie davon, dass das Unternehmen profitabel ist, wenn Sie sie ändern, wodurch das Unternehmen den Dienst weiterhin für den Benutzer bereitstellen kann.
Bryan Oakley
4

User Stories existieren nicht, um irgendeine methodische Anforderung zu erfüllen. Sie existieren nur, um zu klären, was ein Team tut, warum sie es tun und wer davon profitiert. Wenn Sie die Wörter verdrehen, um die Bedeutung zu verschleiern, oder eine strenge Anforderung erfüllen, wie eine Geschichte aussehen soll, dient sie niemandem.

Beantworten Sie also ehrlich die Frage "Wer profitiert davon?" Und "Warum setzen wir dies um?". Ihr Entwicklungsteam benötigt diese Informationen, um seine Arbeit zu erledigen. Auch wenn die Geschichte aus Sicht des Benutzers negativ ist, sind dies wertvolle Informationen.

Abgesehen davon klingt das, was Sie beschreiben, eher nach einem Anwendungsfall als nach einer Geschichte. Wenn Sie dies auf kleinere Teile reduzieren, ist es möglicherweise sauberer, wer die Eigentümer und Nutznießer sind. Die Gebührenerhebung für das Abrufen von E-Mails besteht beispielsweise aus mehreren Komponenten. Zumindest gibt es eine UI-Komponente und eine Back-End-Komponente sowie möglicherweise eine Geschäftsregel.

Sie können Ihr Feature in folgende Geschichten unterteilen:

Als Anbieter eines E-Mail-Dienstes möchte ich für jede gelesene E-Mail eine Gebühr erheben, damit ich Geld verdienen und den Dienst weiterhin bereitstellen und verbessern kann

Als Benutzer möchte ich, dass die Erfassung der E-Mail-Gebühr automatisch erfolgt, damit ich meine E-Mail lesen kann, ohne jede Gebühr bei der Erfassung bestätigen zu müssen, damit meine Erfahrung angenehmer wird.

Als Benutzer möchte ich in der Lage sein, die Nutzungsbedingungen und Gebührenbeträge einfach zu überprüfen, damit ich die Gebühren verstehe, die erhoben werden, damit ich sicher sein kann, dass ich auf meine Kosten komme.

Als Benutzer möchte ich, dass die Abholgebühr für das Lesen von E-Mails gering ist, damit ich mir die Nutzung dieses Dienstes leisten kann

Bryan Oakley
quelle
2
Ich mag diese Antwort - es gibt Methoden, um etwas aufzubauen. Wenn sie zu einem Dogma werden, dem man blind folgen kann, dienen sie nicht mehr dem beabsichtigten Zweck.
Jay Elston
-1

Ich bin damit einverstanden, dass das Schreiben in Bezug auf den Systembesitzer falsch erscheint, da der Systembesitzer diese Geschichte nicht initiiert - der Benutzer tut dies, wenn er seine E-Mails abruft. Aber ich denke nicht, dass Sie darüber sprechen müssen, was der Benutzer will, sondern was er erwartet.

As a customer
When I check my email
I should be charged
So I continue to recieve Service X

Der Benutzer würde eine Belastung erwarten, da Sie ihm Ihren Zahlungsplan mitgeteilt haben.

JohnL
quelle
3
Es ist egal, wer die Geschichte "initiiert". Der Punkt der Geschichte ist, dass das Team den geschäftlichen Wert der Geschichte versteht. Manchmal besteht der geschäftliche Wert darin, das Kundenerlebnis zu verbessern, manchmal nicht. Sei ehrlich. Es ist nicht so, dass der Kunde die Karte sieht. Das Ziel ist es, sicherzustellen, dass dem Team klar ist, warum Sie etwas tun. Wenn die Realität so ist, tun Sie dies, um dem Benutzer Geld zu entziehen. Wenn das eigentliche Ziel jedoch darin besteht, im Geschäft zu bleiben, damit Sie dem Benutzer dienen können, sagen Sie dies.
Bryan Oakley
1
Wenn Ihnen auf diese Weise beigebracht wurde, User Stories zu schreiben, muss ich Ihnen leider mitteilen, dass Sie in die Irre geführt wurden. Eine User Story definiert, was ein Benutzer braucht oder will, nicht was er erwartet. Die Tatsache, dass Gebühren für E-Mails anfallen, ist selbstverständlich. Als Benutzer MUSS ich belastet werden, damit ich meine E-Mails abrufen kann. Diese Antwort ist sachlich und eindeutig falsch, und ich schlage vor, sie zu löschen.
maple_shaft
Ich glaube, ich habe es damals falsch verstanden, obwohl ich vorschlagen würde, dies nur als Ihre Antwort hinzuzufügen. Ich schätze es, richtig eingestellt zu sein, die Abwertung nicht so sehr . Und ich denke, es ist wichtig, wer die Geschichte initiiert, denn so weiß ich, mit welchen Geschichten ich mich gerade beschäftige. Es gibt keine Möglichkeit, sie alle auf einmal im Kopf zu behalten. Um herauszufinden, was passiert, wenn ein Benutzer seine E-Mails abruft, gehe ich zu der Geschichte, die mit beginnt. As a user, when I check my email...Wenn ich das nicht zuverlässig tun kann, sind Benutzergeschichten grundlegend kaputt. Es tut uns leid.
JohnL
2
@JohnL: Was Sie beschreiben, klingt eher nach Anwendungsszenarien als nach User Stories. Beide Formate sind in Ordnung, um Softwareanforderungen zu beschreiben. Verwenden Sie das, was für Sie besser funktioniert und sich besser in Ihren Entwicklungsworkflow einfügt.
Goran Jovic
2
Goran und Bryan machen hervorragende Punkte. Es hört sich so an, als würden Sie sich mit Anwendungsfällen befassen, weil User Stories Ihnen nicht zugute kommen. Diese Dinge sollen Ihrem Projekt zum Erfolg verhelfen. Wenn Sie der Meinung sind, dass sie im Allgemeinen ein allgemeines Hindernis darstellen, sind Anwendungsfälle und User Stories für Sie wahrscheinlich von geringem bis keinem Nutzen, und Sie sollten sich nicht zwingen, sie zu verwenden. Dies ist ein absolut legitimes Szenario, wenn die tatsächliche Geschäftslogik, Komplexität und der vom Benutzer wahrgenommene Wert Ihrer Software so gering sind, dass User Stories entweder spärlich oder allgemein bekannt sind.
maple_shaft