Ich überlege, User Stories für unser nächstes Webprojekt zu verwenden. Zum Beispiel:
Es wird eine Homepage mit einigen Informationen und den neuesten Projekten für den Kunden geben.
Wie könnte man daraus eine User Story machen? Und es muss von einem Designer entworfen und dann entwickelt werden ... Aber wenn dies nur eine Karte ist, wie können wir das auf der Tafel verfolgen, damit wir feststellen können, ob der Designer sie gerade entwirft oder ob jemand sie entwickelt?
User Stories werden aus der Sicht des Endnutzers geschrieben. Eine beispielhafte User Story könnte etwa so aussehen:
Als Website-Benutzer möchte ich wichtige Informationen auf der Homepage sehen, damit ich diese Seite nützlich finde
Die Arten von Informationen, die Sie zeigen, könnten in den Akzeptanzkriterien für die Geschichte weiter detailliert werden. Diese Akzeptanzkriterien ergeben sich aus einer Diskussion mit Ihrem Product Owner oder Stakeholdern.
Das Taskboard verfolgt genau die Art von Informationen, die Sie erwähnen. Sie könnten beispielsweise die folgenden Spalten auf Ihrem Taskboard haben:
Jede Karte stellt eine Geschichte dar und die Spalte, in der sie sich befindet, zeigt an, wer daran arbeitet.
Sie können Epics, wie Sie sie beschrieben haben, nicht sinnvoll verwalten oder nachverfolgen. Darüber hinaus sind User Stories, denen es an Kontext und einem klar definierten Wertkonsumenten mangelt , im Allgemeinen nicht nützlich für das Projektmanagement oder sogar als Gesprächsplatzhalter für die Geschäftskommunikation.
Es wird eine Homepage mit einigen Informationen und den neuesten Projekten für den Kunden geben.
Das ist nicht einmal ein Epos. Abgesehen davon, dass die INVEST-Kriterien nicht befolgt werden, vermittelt ein Epos dieser Größe nicht einmal nützliche Informationen über die Themen und Geschichten, die darunter verpackt sein könnten.
Wie könnte man daraus eine User Story machen?
Die kurze Antwort lautet:
User Stories sollten viel detaillierter sein als das, was Sie in Ihrem ursprünglichen Beitrag beschrieben haben. Wenn Stories klein genug sind und ihnen klar definierte Aufgaben zugeordnet sind, wird es möglich, die Stories über Ihre Swimlanes oder Statusspalten zu verfolgen.
Aber wenn dies nur eine Karte ist, wie können wir dies auf der Tafel verfolgen, damit wir feststellen können, ob der Designer sie gerade entwirft oder ob jemand sie entwickelt?
Wenn die Geschichten in Aufgaben zerlegt werden, dann kann die Geschichte klar definiert von Funktion zu Funktion weitergegeben werden. Dies ist jedoch kein agiler Ansatz. Anstatt das Design von der Entwicklung zu trennen, sollten User Stories einen vertikalen Wertanteil durch beide Funktionen darstellen und die Teammitglieder sollten gemeinsam und kollaborativ daran arbeiten.
Ihr Kanban-Board spiegelt dann den Status jeder Story oder ihre Position in Ihrer Prozesspipeline wider und nicht, wer woran arbeitet. Während diese Art von Details an User Stories angehängt werden können, ist dies oft ein „Projektgeruch“, bei dem das Team immer noch einem wasserfallbasierten, im Voraus erstellten Designprozess folgt.
Es gibt viele Informationen im Internet und in Büchern darüber, wie man aussagekräftige User Stories erstellt und wie man sie verwaltet und verfolgt. Antworten hier können keine kanonische Liste von Ressourcen liefern, die ein Praktiker kennen sollte, aber Sie können sicherlich mit einigen Klassikern beginnen wie:
Erwarten Sie bitte nicht, dass Antworten auf einer Q&A-Website das Grundwissen über User Stories ersetzen. User Stories wirklich zu verstehen, wie man sie anwendet und wie man sie in Ihrem Projektmanagementprozess verwaltet, ist ein komplexes Thema.