Ich arbeite hart an User Stories und es zahlt sich aus, aber etwas juckt.
Wir verwenden Jira, aber das Problem ist, dass der Rückstand von oben ungeschickt erscheint.
Wir müssen eine Zusammenfassung für die Benutzergeschichte schreiben, damit Jira sie anzeigen kann, aber diese Zusammenfassungen sind manchmal etwas irreführend oder nicht hilfreich, um eine bestimmte Geschichte zu finden.
Wir machen kein Scrum, wir verwenden nur Backlog und modifiziertes Kanban-Board, um unseren Fortschritt zu visualisieren.
Ich möchte, dass Backlog (und das Board) Geschichten in einer (lesbaren) kohärenten Struktur anzeigen, damit ich leichter navigieren kann.
In diesem Moment, um dieses Problem zu lösen, sehe ich, dass ich entweder:
Ich weiß nicht wie ich bei Punkt 2 vorgehen soll.
Einige Ideen für Punkt 1 bisher:
Mehr denke ich darüber nach, ich denke, dass die User Story keine Zusammenfassung hat (?). Sie stammen aus Karteikarten(?) und stellen einen kleinen Ausschnitt einer Anforderung dar.
Sie scheinen so kurz wie möglich zu sein.
Einige Beispielgeschichten (bitte seien Sie vorsichtig, wenn sie Fehler haben) im Zusammenhang mit Verkaufsautomaten oder Bezahlstationen, die eine Kartenzahlungsoption anbieten.
Als Kunde
möchte ich daran erinnert werden, dass sich meine Karte im Kartenterminal befindet, nachdem ich die Kartenzahlung storniert habe,
damit ich sie nicht an der Kasse vergesse.Als Kunde
möchte ich daran erinnert werden, dass sich meine Karte im Kartenterminal befindet, nachdem ich mit Karte bezahlt habe,
damit ich sie nicht an der Zahlstation vergesse.Als Kunde
möchte ich wissen, ob ich die Kartenzahlung vom Kartenterminal erfolgreich storniert habe,
damit ich nicht verwirrt bin, ob ich bezahlt habe oder nicht.
Verwenden Sie stattdessen Job-Storys .
Alle Ihre User Stories beginnen mit „Als Kunde“, also verschwenden Sie diese Zeile. Wir wissen, dass sie ein Kunde sind. Das ist eine gegebene.
Stattdessen lauten Job-Storys:
Wenn... ich will... damit ich...
Also - zum Beispiel -
Wenn ich eine Kartenzahlung storniert habe, möchte ich daran erinnert werden, dass meine Karte im Kartenterminal steckt, damit ich sie nicht vergesse.
(Und dann können Sie eine letzte Zeile hinzufügen – „Dieser Bedarf ist erfüllt, wenn …“, damit Sie genau wissen, was Sie tun müssen. Wenn Sie möchten.)
Es wird mir sehr schwer fallen, eine kanonische Antwort auf diese Frage zu finden, und in Anbetracht des Problems, das Sie möglicherweise von anderen Community-Mitgliedern teilen, werde ich einige Gedanken teilen.
Ihr grundlegendes Problem ist, wie das Team den Rückstand visualisiert. Unabhängig davon, wie detailliert die Zusammenfassung ist, es ist nur eine ... Zusammenfassung. Sie sollten nicht erwarten, alles von der Zusammenfassung zu verstehen.
Versuchen Sie, Zusammenfassungen als "Hinweise" zu sehen. Ihr Team sollte eine Sitzung abhalten, um die wichtigsten Backlog-Elemente zu überprüfen (um den tatsächlichen „Inhalt“ kennenzulernen). Wenn sich die Leute das nächste Mal den Rückstand ansehen, sollten sie beim Lesen der Zusammenfassung eine Vorstellung davon haben, worum es bei jedem Element geht. Lesen Sie mehr über die Backlog-Verfeinerung .
Berücksichtigen Sie nun Ihre spezifischen Story-Beispiele und Ihre Jira-Nutzung. Wenn Sie ein Scrum-Board anstelle eines Kanban-Boards verwenden, können Sie die obigen Storys unter einem Epic namens „Payment by Card“ gruppieren … und dann im Scrum-Backlog auf dieses Epic im Epic-Filter auf der linken Seite klicken Seite des Rückstands. Sie können ein Beispiel in DIESER Antwort sehen.
Sie könnten dieselbe Logik auf andere Epics anwenden, z. B. „Barzahlung“, oder sogar ein bestimmtes Epic für „Zahlungen“ belassen. Die Quintessenz ist, dass das Backlog einfach zu lesen und zu navigieren sein sollte.
Außerdem ist es äußerst wichtig, sich daran zu erinnern, dass „eine ‚User Story‘ kein Quellcode ist!“ Eine User Story ist einfach eine Formulierung einer Anforderung in menschlicher Hinsicht. Wenn Sie es "zusammenfassen", gehen Sie zwei pragmatische Risiken ein:
Sie ändern es, schreiben es bewusst oder unbewusst im Hinblick auf das Design oder die Implementierung des sich entwickelnden Softwaresystems um.
Sie legen eine Bedeutung – Ihre – auf etwas, das aus der „Perspektive des Benutzers“ möglicherweise etwas anderes bedeuten sollte.
Ihr Ziel ist es , diese Geschichten während des Prozesses der Formulierung von Entwürfen und Implementierungen zu verwenden, damit Sie diesen Entwurf dann mit ihnen vergleichen können, um zu sehen, wie die in dieser "Geschichte" genannten Anforderungen sowohl vom System als auch von den erfüllt werden sollen hypothetischer Benutzer, der „die Geschichte erzählt“ hat, als er versucht, das System zu verwenden. Wenn Sie sie zusammenfassen (umschreiben) , verlieren Sie sehr schnell ihren beabsichtigten Wert.
Ja, das ist richtig, wenn Sie wirklich das Konzept der User Stories verwenden, gibt es keine Zusammenfassung. Nur das "Wie ich will, damit"-Format.
Wenn Sie mehr Zusammenfassung schreiben wollen oder können, dann machen oder haben Sie Analysearbeit geleistet, die später vom Team erledigt werden sollte. Das ist der puristische Ansatz, denke ich. Es ist sogar eine bekannte Praxis, der Geschichte Akzeptanzkriterien hinzuzufügen, vielleicht im Gurkenformat, daher ist es schwer zu argumentieren, dass es immer schlecht ist, mehr als den Titel hinzuzufügen. Natürlich werden Akzeptanzkriterien oft später bei der Verfeinerung hinzugefügt.
Ich denke, wenn man viel Text, Diagramme oder Screenshots hinzufügt, entfernt man sich von der Essenz einer User Story. Das muss nicht immer schlecht sein, nicht alle agilen Anforderungen müssen User Stories sein. Allerdings ist die Art und Weise, wie viele Orte den Begriff User Story verwenden, mit ganzen mehrseitigen Word-Dateien angehängt, nicht wirklich das, was wir uns unter einer User Story vorstellen sollten.
Praktisch könnte man in Jira die Akzeptanzkriterien im Zusammenfassungsfeld hinterlegen.
Barnaby Golden
Todd A. Jacobs