Kostenlos User-Story-Vorlagen
Die folgenden Vorlagen können für verschiedene Zwecke verwendet werden. Sie können User-Story-Backlogs schreiben, zuordnen und verwalten, Epen schreiben und vieles mehr. Viele dieser Vorlagen ähneln sich, wählen Sie also nach persönlicher Vorliebe oder nach dem speziellen Prozess (und somit dem Format) Ihres Unternehmens aus.
Produkt- und Projektmanager können die Backlog-Vorlage verwenden, um den Überblick über die User-Stories zu behalten. Sie können aber auch die anderen Vorlagen verwenden, um User-Stories zu erstellen oder darzustellen. Andere Teammitglieder können die User-Story- oder Eposvorlagen verwenden, um User-Stories zu erstellen.
User-Story-Vorlage
User-Stories helfen den Produktteams, sich auf die Bedürfnisse der Benutzer zu konzentrieren und ihre Arbeit bei der Entwicklung von Funktionen zu steuern. Projekt- und Produktmanager können diese Vorlage verwenden, um die vom Benutzer generierte Arbeit zu verwalten. Alle anderen Teammitglieder können damit User-Stories schreiben.
User-Story-Backlog-Vorlage
Verwenden Sie diese Vorlage, um Ihr User-Story-Backlog während der Produktentwicklungsiterationen zu verwalten.
Das Backlog wird während der Sprint-Planung erstellt, bei der ein Team die wichtigsten Elemente des Produkt-Backlogs auswählt und sie dann zu seinen Sprints hinzufügt. Das Backlog enthält alle Arbeiten, die in die Entwicklungsphase verschoben wurden, und stellt eine To-Do-Liste der Aufgaben dar, die in der aktuellen Iteration erledigt werden müssen. Diese Liste sollte abschließend sein (d. h., Aufgaben sollten an dieser Stelle nicht mehr hinzugefügt oder entfernt werden).
Die Vorlage enthält Spalten für Backlog-Elemente, Story-Points, Verantwortlichkeiten, Status und die ursprünglichen Schätzungen. In den Spalten, die die Tage 1-5 darstellen, können Produkt- oder Projektmanager die Anzahl der zusätzlichen Entwicklungsstunden hinzufügen, die jeden Tag für eine Aufgabe erforderlich sind. Die Gesamtzahl der zusätzlichen Entwicklungsstunden für jeden Tag für alle Aufgaben im Sprint wird in der Summenzeile angezeigt. Das Burndown-Chart stellt dann diese ausstehenden Arbeiten dar.
User-Story-Mapping-Vorlage
Dies ist eine Vorlage, die Sie mit Post-it-Notizen oder Karteikarten ergänzen oder neu gestalten können. Die Anzahl der Kästchen kann je nach den Aktivitäten, die bei der Nutzung eines bestimmten Systems stattfinden, variieren.
Projekt- und Produktmanager können diese Vorlage verwenden, um die Reihenfolge der Aktivitäten festzulegen, die ein Benutzer bei der Nutzung eines Systems erlebt. Die y-Achse zeigt die zunehmende Komplexität der abgebildeten Funktionalität; die x-Achse enthält die Reihenfolge der Aktionen, die die Benutzer bei der Nutzung eines Systems erleben. Die erste Zeile enthält die grundlegendsten Funktionen, in den folgenden Zeilen nimmt die Komplexität zu.
Excel-Vorlage herunterladen
Epos-Vorlage
Ein Epos ist ein Arbeitsabschnitt, der sich mit einer zu entwickelnden Funktionalität befasst, und kann zur Erstellung von User-Stories verwendet werden. Verwenden Sie diese Vorlage, um Epen zu schreiben. Verfolgen Sie dann die User-Stories, die aus jedem Epos entstehen. Projekt- und Produktmanager können diese Vorlage verwenden, um die aus den Epen generierte Arbeit zu verwalten, und alle anderen Teammitglieder können sie zur Erstellung von Epen verwenden.
Was ist eine User-Story?
Eine User-Story ist eine kurze (ein oder zwei Sätze), einfache und spezifische Beschreibung einer Interaktion mit einem Produkt in der Entwicklungsphase, in der Regel einer App oder Webseite. (Natürlich können sie auch für die Entwicklung anderer Projekte eingesetzt werden.) User-Stories dienen als Leitfaden für Entwickler, Designer, Produktmanager und andere, die an der Entwicklung eines Produkts beteiligt sind.
User-Stories sollten festlegen, wer die Benutzer sind und was sie mit dem Produkt oder der Dienstleistung tun. Sie sollten auch einen Benutzertyp, die gewünschte Aktion des Benutzers und den Wert enthalten, den der Benutzer erhält, wenn die Aktion abgeschlossen ist. Eine User-Story sollte jedoch nicht beschreiben, wie ein Merkmal oder eine Funktionalität zu implementieren oder zu entwickeln ist.
User-Stories sind ein integraler Bestandteil der Softwareentwicklungsmethodik Agile. Im Vergleich zu herkömmlichen Projektmanagementmethoden (z. B. Waterfall), ist Agile ein flexibler und iterativer Prozess. Agile läuft in Zyklen, sogenannten Iterationen ab, die von einer bis zu vier Wochen dauern. In jeder Iteration arbeiten die Entwickler daran, neue Funktionalitäten zu erstellen oder vorhandene zu verbessern. User-Stories werden verwendet, um die Erstellung von Funktionalitäten zu leiten. Die folgenden kostenlos herunterladbaren Vorlagen können zum Erstellen und Arbeiten mit User-Stories in verschiedenen Phasen des Agile-Prozesses verwendet werden. Hier erfahren Sie mehr über Agile und können kostenlose Vorlagen für Agile-Projektmanagement herunterladen.
Was ist Scrum?
Scrum ist eine Variante der weitverbreiteten Agile-Methode. Es gibt einige Unterschiede zwischen den Verfahren der beiden Methoden: Scrum bezieht sich auf ein tägliches, kurzes Team-Meeting, um Fortschritte und Pläne zu besprechen. In Scrum werden Zyklen Sprints und nicht Iterationen genannt. Akzeptanzkriterien werden als Definition of Done (DOD) bezeichnet. Scrum und Agile haben jedoch die gleichen übergeordneten Prinzipien.
Wie ist eine User-Story strukturiert?
Es gibt kein bestimmtes Format für Agile-User-Stories, daher gibt es eine Reihe von Varianten (die jedoch nur geringfügig in der Terminologie variieren). Die grundlegende Form einer User-Story nimmt die Perspektive eines bestimmten Benutzers des Produkts auf und beschreibt, was er mit dem Produkt machen möchte und welchen Wert er von der Durchführung dieser Funktion erhält: Als , möchte ich
Hier sind einige Beispiele für User-Stories für Software zur Nachverfolgung von Geschäftsausgaben:
- Als Datenerfasser möchte ich Tabellenblätter hochladen, damit ich keine Daten ausschneiden und einfügen muss.
- Als Vertriebsmitarbeiter auf Reisen möchte ich Bilder von Quittungen importieren, damit ich sie nicht mit mir herumtragen muss.
- Als Finanzmanager möchte ich in der Lage sein, Änderungen an den Vorlagen für Bestandskostenabrechnungen vornehmen, damit ich die Berichte nicht jeden Monat überarbeiten muss.
Wie werden User-Stories erstellt?
User-Stories werden oft Epen entnommen, die oft ein ähnliches Format wie User-Stories aufweisen. Epen sind jedoch auf einer höheren Ebene angesiedelt und decken mehrere Funktionalitäten ab. (Sie können auch als kurze Sätze angegeben werden.) Epen sind zu umfangreich, um in einer einzigen Agile-Iteration abgeschlossen zu werden. Daher müssen sie aufgeteilt werden. Die Idee ist, nichts aus dem Epos zu eliminieren, sondern User-Stories zu erstellen, die granular genug sind, um in einer einzigen Iteration abgeschlossen werden zu können. Beispiel-Epen für eine Kalender-App könnten Folgendes enthalten:
- Als Benutzer möchte ich alle meine Termine von meinem Telefon aus verwalten können.
- Als Benutzer möchte ich meinen Familienkalender und meinen Geschäftskalender zusammen sehen.
- Als Benutzer möchte ich die volle Funktion in den Erinnerungen haben, ohne die App zu öffnen.
Anfangs kann es schwierig sein, zwischen einem Epos und einer User-Story zu unterscheiden, aber mit der Erfahrung wird es einfacher.
Epen und User-Stories sollten auf den Bedürfnissen der Benutzer beruhen und nicht auf Spekulationen – Gespräche mit Benutzern oder potenziellen Benutzern stellen sicher, dass die Stories auf der Realität basieren.
Viele Organisationen verwenden beim Erstellen von User-Stories Personae. Eine Persona ist eine Kurzbiografie eines fiktiven Benutzers, die Designern und Entwicklern hilft, sich auf einen bestimmten Benutzertyp anstatt auf einen allgemeinen, imaginären Benutzer zu konzentrieren.
In einigen Organisationen werden User-Stories in untergeordnete Stories (auch Unter-Storiesgenannt) aufgeteilt, die in einer einzigen Iteration bearbeitet werden können. Einige sind jedoch der Meinung, dass eine User-Story, wenn sie sich aufschlüsseln lässt oder nicht in eine Iteration passt, tatsächlich ein Epos ist.
Wer schreibt User-Stories?
Jeder Projektteilnehmer kann während des Projekts jederzeit User-Stories schreiben. Im Allgemeinen findet vor der ersten Iteration eine Story-Schreibsitzung statt, die dem Produktteam einen Backlog an Stories verschafft, die es zu bewältigen gilt. Lesen Sie hier mehr über den Prozess des Schreibens von User-Stories.
Es gibt einige hilfreiche Leitfäden, mit deren Hilfe Sie starke User-Stories schreiben können. Einer der bekanntesten dieser Leitfäden ist eine Mnemonik namens INVEST, die Unternehmensberater und Softwareentwickler Bill Wake erstellt wurde:
- Independent: Es sollte in sich abgeschlossen sein (d. h., nicht von einer anderen User-Story abhängen).
- Negotiable: Es sollte Platz für Diskussionen geben.
- Valuable: Die Geschichte muss den Beteiligten einen Mehrwert bieten.
- Estimable: Der Aufwand für die Implementierung der Funktionalität, die aus Story entsteht, lässt sich abschätzen.
- Small: Sie sollte in einem einzigen Sprint abgeschlossen werden können.
- Testable: Die Story muss genügend Details enthalten, damit Tests erstellt werden können, um die Funktionalität aus der Erzählung überprüfen zu können.
Was sind einige der Vorteile von User-Stories?
User-Stories sind in der Agile-Methode und anderen Vorgehensweisen beliebt, da sie Mehrwert bieten und Produktentwicklungsteams dabei helfen, Funktionalitäten zu schaffen, die den Bedürfnissen der Benutzer entsprechen. Hier sind einige der Vorteile von User-Stories:
- Es ist eine einfache Möglichkeit zu sehen, welche neuen Funktionalitäten und Fähigkeiten benötigt werden.
- Sie machen deutlich, welche Funktionalität zur Lösung von Kundenproblemen erforderlich ist.
- Sie sind leicht zu verstehen und zu merken.
- Sie konzentrieren sich auf den Geschäftswert und die Kundenbedürfnisse.
- Sie erleichtern die Priorisierung.
- Sie konzentrieren sich darauf, wie potenzielle Kunden das Produkt nutzen werden.
- Sie können Zeit sparen, da es weniger Fehlstarts gibt.
- Sie können verwendet werden, um den Werdegang des Produkts nachzuvollziehen, indem verfolgt wird, welche Funktionalitäten in jeder Iteration hinzugefügt wurden.
- Sie verlagern den Schwerpunkt vom Schreiben von Anforderungen darauf, über sie zu sprechen.
- Sie können unterschiedliche Detailebenen aufweisen.
- Durch die Aufteilung der Arbeit in einzelne Abschnitte bieten sie Flexibilität bei der Umsetzung.
- Die technischen Spezifikationen werden den Entwicklern überlassen.
- Sie fördern die Zusammenarbeit und kreative Lösungen.
- Sie verbessern den ROI und die Teammoral.
Was sind die Herausforderungen von User-Stories?
User-Stories sind wie jedes Geschäftswerkzeug oder -prozess hilfreich, aber sie sind nicht perfekt. Hier sind einige der damit verbundenen Herausforderungen:
- Sie befassen sich nicht mit der Benutzerführung, der visuellen Gestaltung oder den technischen Anforderungen.
- Die Absicht hinter User-Stories wird von den Verfassern oft vernachlässigt, obwohl sie der wichtigste Teil des Prozesses ist.
- Wenn die Autoren nicht über die richtigen Daten verfügen oder sich nicht mit den vorhandenen Daten auseinandersetzen, um die Bedürfnisse der Benutzer herauszuarbeiten, werden die User-Stories schwach sein.
- Wenn man die Nutzer nicht vollständig versteht, entstehen Stories, die nicht auf ihre tatsächlichen Bedürfnisse eingehen.
- Wenn die Produktteams nicht über das richtige Fachwissen verfügen, können User-Stories die Bedürfnisse der Benutzer nicht effektiv erfüllen.
Wie werden User-Stories implementiert?
User-Stories sind ein Ausgangspunkt für Diskussionen im Team. Aus diesen Diskussionen sollten sich weitere Details und einige konkrete Ideen ergeben, wie die beschriebene Funktionalität so implementiert werden kann, dass sie für den Benutzer von Nutzen ist. Wenn Sie bereits Personae erstellt haben, ist es hilfreich, diese während dieser Diskussionen zu verwenden, um den nutzerzentrierten Fokus aufrechtzuerhalten.
Während der Diskussion können die User-Stories zusammen mit Personae, Epen und anderen verwandten Elementen mit einem Werkzeug wie StoriesOnBoard oder FeatureMap auf einer Produktübersicht dargestellt werden. Einige Teams erstellen auch niedrig aufgelöste Abbildungen, um die Funktionalität, die eine Lösung für das in der User-Story angesprochene Problem bietet, zu demonstrieren.
Sobald die User-Stories erstellt und diskutiert wurden, müssen sie abgebildet werden. Bei der Abbildung (Mapping) wird ein Raster der User-Stories in logischen Gruppen erstellt, die sich auf eine Funktionalität, eine Funktion oder Aufgaben beziehen, die von den Benutzern ausgeführt werden. Jede dieser Gruppen kann als Thema bezeichnet werden. Es gibt viele Möglichkeiten, User-Stories abzubilden, z. B. sie auf Haftnotizen zu schreiben und an die Wand zu hängen oder eine Schachtel voller Karteikarten zu haben und sie auf einem Tisch auszubreiten. Lesen Sie hier mehr über die Abbildung von User-Stories.
Wie bereits erwähnt, werden User-Stories in einem Backlog gesammelt. Das Backlog ist eine priorisierte Liste der Funktionalitäten, die für das Produkt erstellt werden. Es ist die Aufgabe des Produktverantwortlichen, dafür zu sorgen, dass für jede Iteration genügend User-Stories im Backlog vorhanden sind. Einige Unternehmen verwenden zwar auch andere Elemente in ihrem Backlog, aber User-Stories sind das am häufigsten verwendete Werkzeug.
Im Waterfall-Projektmanagement umreißt ein Anforderungsdokument, welche Merkmale und Funktionen das Endprodukt enthalten soll. User-Stories sind zwar keine echten Anforderungen, aber im Agile-Projektmanagement erfüllt das Backlog einen ähnlichen Zweck wie das Anforderungsdokument.
Aufgrund seiner Struktur ist ein Backlog in Agile viel fließender als das eines Waterfall-Anforderungsdokumentes. Stories im Backlog sollten mit eindeutigen Identifikatoren versehen werden, um die Rückverfolgbarkeit vom Ursprung der Story zu (z. B., einen Fehlerbericht, Benutzerinterviews, ein Support-Ticket oder ein Vorschlag eines Entwicklers) bis hin zu Entwicklung, Test und Einsatz zu gewährleisten. Gängige Werkzeuge zur Nachverfolgung von Stories bis zum Einsatz sind JIRA, GitHub, FogBugz oder sogar ein Excel-Tabellenblatt.
Nachdem sich ein Team auf die ersten Stories geeinigt hat, sollte es sich treffen, um den Rest der Informationen, die für die Entwicklung, das Testen und andere Prozessschritte benötigt werden, zu konkretisieren. Die Beteiligten sollten auch Prioritäten setzen, welche der in den User-Stories beschriebenen Funktionalitäten zuerst entwickelt werden sollen. Auch hier gilt, dass die Priorisierung aufgrund der Struktur von Agile fließend ist und sich aufgrund neuer Benutzerbedürfnisse, neuer User-Stories und neuem Wettbewerbsdruck ändern wird.
Woher wissen Sie, wann Sie mit einer User-Story fertig sind?
Für jede Story benötigen Sie eine Möglichkeit, um zu überprüfen, ob die gewünschte Funktion erfolgreich implementiert wurde. Es gibt eine Reihe von Begriffen, die dies beschreiben, nämlich Akzeptanzkriterien und Zufriedenheitsbedingungen. Einige Experten sind der Meinung, dass diese beiden Begriffe synonym sind; andere sind der Ansicht, dass die Zufriedenheitsbedingungen einen höheren Stellenwert haben als die Akzeptanzkriterien und dass die Angaben in den Akzeptanzkriterien dazu dienen, zu überprüfen, ob die Zufriedenheitsbedingungen erfüllt sind.
Wer verwendet User-Stories?
Ein ganzes Agile-Team kann User-Stories für seine Arbeit an einem Projekt verwenden, aber hier ist eine Liste der wichtigsten Teammitglieder:
- Produktverantwortliche: Stellen sicher, dass ein Produkt geliefert wird, das den Bedürfnissen der Nutzer entspricht.
- Entwickler: Leiten die Arbeit des Teams.
- Tester: Überprüfen, ob das Produkt wie erwartet funktioniert.
- Technische Autoren: Stellen sicher, dass die Supportmaterialien wichtige Anwendungsfälle abdecken.
Mit Ausnahme der Entwickler kann jeder dieser Personen als Stellvertreter für einen Kunden fungieren und in die Rolle eines Kunden oder Nutzers schlüpfen.
Verbessern Sie das Schreiben von User-Stories mit Smartsheet für die Softwareentwicklung
Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.