Im Kontext von agilen Projekten kommen h\u00e4ufig sogenannte User\u00a0Stories zur Beschreibung von Anforderungen zum Einsatz. Um diese zu formulieren, legen sich Teams h\u00e4ufig auf ein festes Schema fest, um folgende Hauptaspekte beschreiben zu k\u00f6nnen: WER\u00a0(1) fordert WAS (2) und WARUM (3)?<\/p>\n\n\n\n
Eines der meistgenutzten Schablonen stellt sich wie folgt dar:<\/p>\n\n\n\n
\u201eAls <Rolle> m\u00f6chte ich <Funktionalit\u00e4t>, damit <Nutzen\/ Grund>.\u201c<\/p>\n\n\n\n
Im Folgenden werden einige Beispiele von User Stories dargestellt:<\/p>\n\n\n\n
\u2022 \u201eAls <Leser:in des Buches> m\u00f6chte ich <ein kategorisiertes In- haltsverzeichnis sehen>, damit <ich einen schnellen \u00dcberblick \u00fcber alle Methoden bekomme>.\u201c<\/p>\n\n\n\n
\u2022\u00a0\u201eAls <Leser:in des Buches> m\u00f6chte ich <zu jeder Methode eine beispielhafte Durchf\u00fchrung sehen>, damit <ich besser nachvollziehen kann, wie ich diese Methode in der Praxis anwenden kann>.\u201c<\/p>\n\n\n\n
\u2022 \u201eAls <Besucher:in von Amazon> m\u00f6chte ich <die Produkte nach Rezensionen filtern k\u00f6nnen>, damit <ich eine bessere Entscheidungsgrundlage f\u00fcr den Kauf meines Produktes habe>.\u201c<\/p>\n\n\n\n
Wie man sieht, kann man das Format der User Stories sowohl auf technische als auch nicht-technische Systeme anwenden.<\/p>\n\n\n\n
Des Weiteren werden User Stories meistens um weitere Aspekte\u00a0wie bspw. Akzeptanzkriterien erg\u00e4nzt, um diese User Story n\u00e4her\u00a0spezifizieren und hinterher abnehmen zu k\u00f6nnen.<\/p>\n\n\n\n
User Stories bieten zur Anforderungsdefinition mitunter folgende Vorteile:<\/p>\n\n\n\n
\u2022\u00a0Sie stellen sicher, dass die gew\u00fcnschte Anforderung einen Mehrwert f\u00fcr eine bestimmte Rolle oder Persona stiftet, und f\u00f6rdern damit kundenzentrierte Entwicklungen.<\/p>\n\n\n\n
\u2022 Sie sind f\u00fcr alle Stakeholder-Gruppen leicht zu verstehen und f\u00f6rdern aufgrund des \u201eStory\u201c-Formats die Kommunikation und Diskussion.<\/p>\n\n\n\n
\u2022\u00a0Sie sind l\u00f6sungsfrei und bieten den Umsetzern daher die M\u00f6glichkeit, die bestm\u00f6gliche L\u00f6sung zu finden.<\/p>\n\n\n\n
\u2022 Sie f\u00f6rdern Verst\u00e4ndnis und Transparenz, weil der Grund f\u00fcr die Anforderung hinterlegt ist.<\/p>\n\n\n\n
\u2022 Sie k\u00f6nnen schnell verfasst werden und Schritt f\u00fcr Schritt durch bspw. Akzeptanzkriterien verfeinert werden,<\/p>\n\n\n\n
Die formulierten User Stories werden in agilen Projekten in einem\u00a0sogenannten \u201eProduct Backlog\u201c festgehalten. Dieses stellt somit eine dynamische Liste dar, in der s\u00e4mtliche Anforderungen gesammelt werden. Obwohl das Backlog kontinuierlich gepflegt,\u00a0verfeinert und priorisiert werden muss, geht in gr\u00f6\u00dferen Projekten\u00a0h\u00e4ufig die \u00dcbersicht verloren, worunter insbesondere die Makro- Ebene zu leiden hat.<\/p>\n\n\n\n
User Story Maps sind daf\u00fcr ein exzellentes Tool, um sich ganzheitlich einen \u00dcberblick zu verschaffen und die User Stories in einer speziellen Form zu visualisieren. Wohingegen ein Product Backlog User Stories in einer eindimensionalen Liste darstellt, werden diese in einer User Story Map in einer zweidimensionalen Matrix dargestellt. Dies bietet u.a. folgende Vorteile:<\/p>\n\n\n\n
Eine User Story Map wird \u00fcblicherweise von oben nach unten\u00a0(grobe nach feine Anforderungen) und von links nach rechts (zeitliche Reihenfolge) gelesen und beinhaltet damit folgende Bestandteile (diese k\u00f6nnen auch erweitert oder reduziert werden):<\/p>\n\n\n\n
Mit User Story Maps kann man ganzheitlich einen \u00dcberblick \u00fcber die User Stories in einer zweidimensionalen Form visualisieren.<\/p>\n","protected":false},"featured_media":44794,"template":"","meta":{"_surecart_dashboard_logo_width":"180px","_surecart_dashboard_show_logo":true,"_surecart_dashboard_navigation_orders":true,"_surecart_dashboard_navigation_invoices":true,"_surecart_dashboard_navigation_subscriptions":true,"_surecart_dashboard_navigation_downloads":true,"_surecart_dashboard_navigation_billing":true,"_surecart_dashboard_navigation_account":true,"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":""},"working-guide":[],"transformation-blocks":[66],"innovation-stage":[],"class_list":["post-44774","methode","type-methode","status-publish","has-post-thumbnail","hentry","transformation-blocks-exploring"],"_links":{"self":[{"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/methode\/44774","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/methode"}],"about":[{"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/types\/methode"}],"version-history":[{"count":0,"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/methode\/44774\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/media\/44794"}],"wp:attachment":[{"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/media?parent=44774"}],"wp:term":[{"taxonomy":"working-guide","embeddable":true,"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/working-guide?post=44774"},{"taxonomy":"transformation-blocks","embeddable":true,"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/transformation-blocks?post=44774"},{"taxonomy":"innovation-stage","embeddable":true,"href":"https:\/\/www.innovation.wiki\/de\/wp-json\/wp\/v2\/innovation-stage?post=44774"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}