Von der User Story zum Use Case. Agil und langfristig.
In diesem Artikel werde ich die spezifische Idee herausarbeiten, in einem Scrum-Team User Stories und Use Cases zu verwenden. Es wird also gezeigt, warum beide Artefakte Verwendung finden und wie der Übergang von der User Story zum Use Case gestaltet wurde. Sowohl nach, als auch vor diesem Teilprozess müssen weitere Schritte in einem sinnvollen Requirements Engineering abgearbeitet werden. Eine klare Vorstellung über die umzusetzenden Themen und ein profundes Wissen über den Systemkontext sind Voraussetzungen. Damit verfügen wir über Stakeholder, die ihre umzusetzenden User Stories beschreiben können. Zuerst muss definiert werden, was eine Story ist.
Benutzergeschichten
"User Stories setzen sich aus drei Bestandteilen zusammen:
- einer schriftlichen Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird;
- Gesprächen über die Story, um die Details der Story herauszuarbeiten;
- Tests, die Details vermitteln und dokumentieren und mit denen festgelegt wird, wann eine Story vollständig umgesetzt ist. " [2]
Demnach ist eine User Story ein Planungsinstrument für eine beabsichtigte Funktionalität, eine Erinnerung, die Anforderungen dazu detailliert auszuarbeiten und die Aufforderung die Akzeptanzkriterien zu dieser Funktionalität zu beschreiben. Bevor wir User Stories sammeln, wurde in Bezug auf umzusetzende Themen eine Systemkontextanalyse durchgeführt, in der wir eine Reihe von Kontextobjekten angelegt haben. Das können Dokumente, Stakeholder, Systeme und Prozesse sein. Mit Hilfe dieses Verständnisses des Systemkontextes kann für thematische Zusammenhänge (Themen) die Aufgabe der Bildung von User Stories beauftragt werden. Zu diesem Zeitpunkt sollte eine gewisse Planungssicherheit ermöglicht werden, und außerdem wird damit die zu liefernde Funktionalität konkretisiert. Das Ergebnis dieser Aufgabe sind User Story-Objekte.
"Eine gute User Story muss sechs Eigenschaften haben:
- independent (unabhängig)
- negotiable (verhandelbar)
- valuable (werthaltig) für User oder Kunden
- estimatable (schätzbar)
- small (klein)
- testable (testbar)" [3]
Diese sogenannten INVEST-Eigenschaften durchzuhalten, ist nicht gerade einfach. Besonders die Unabhängigkeit bereitet große Schwierigkeiten. Wenn zwei User Stories voneinander abhängig sind, dann gilt es, diese Abhängigkeit zu beachten. Das erschwert die Planung. Empfohlen wird bei abhängigen Stories die Zusammenlegung zu unabhängigen größeren Stories oder eine andere Aufteilung. Zumindest sollten diese Abhängigkeiten minimiert werden. Mit dem folgenden Template kann eine User Story formuliert werden:
Als [Rolle] möchte ich [Wunsch], um [Nutzen]
Das Template ist der deutschen Wikipedia entnommen [4]. Im Folgenden werden die drei zu ersetzenden Bestandteile erläutern. Ein [Rolle] entspricht einem User. Diese liegen uns als Stakeholder-Kontextobjekte vor. Stakeholder können auch zu Gruppen zusammengefasst werden, sogenannte Nutzerrollen wie Administratoren und Sachbearbeiter einer Software. Für diese Nutzerrollen können Personas und extreme Charaktere gebildet werden. Diese stellen ebenfalls Kontextobjekte dar.
"User Stories ergeben sich beim Gespräch mit Usern, bei der Beobachtung von Usern, durch Fragebögen und in Story-Workshops. Die besten Ergebnisse werden in Kombination dieser Methoden erreicht und nicht durch blindes Vertrauen in nur eine Methode" [5]. Mit Hilfe dieser Methoden wird also der [Wunsch] ermittelt. Viele Wünsche können aus den zuvor erfassten Ideen abgeleitet werden. Sie bilden jedoch nur eine Teilmenge der zu ermittelnden Wünsche. Eine wichtige Überlegung ist der [Nutzen] wert. In ihm dokumentiert sich der Geschäftswert. In einigen Templates kann dieser Teil auch weggelassen werden. Ich plädiere dafür, ihn in jedem Fall zu erfassen. Man sollte sich klar sein, welchen Geschäftswert eine Funktionalität besitzt. Man vermeidet damit die Umsetzung von Unnützem.
Zu jeder User Story können Hinweise und Randbedingungen aufgenommen werden. Sie bieten für die spätere Ausarbeitung der Anforderungen wichtige Ausgangspunkte. Von absoluter Wichtigkeit sind jedoch die Akzeptanztests. "Akzeptanztests dienen zur Darstellung von Details, die sich aus den Gesprächen zwischen Kunden und Entwickler ergeben" [6]. "Akzeptanztests liefern die grundlegenden Kriterien, die feststellen sollen, ob eine Story vollständig implementiert ist" [7]. Im Post „Der Kunde ist für die systematische Erarbeitung der Kundenanforderungen zuständig“ [8] plädierte ich dafür, dass der Kunde die Funktionalität bestimmen sollte, die er haben will. Auch COHN fordert für die Akzeptanztests, dass sie eher vom Kunden, als vom Entwickler geschrieben werden sollten. Es ist nur logisch, dass derjenige, der etwas haben will, bestimmt, unter welchen Umständen er es abnehmen wird. Das ist auch eine Sache der Fairness.
Die fertiggestellten User Story-Objekte dienen nun als Planungsinstrument. Zuerst werden die User Stories mit Hilfe von Story Points geschätzt. "Schätzwerte und Stories müssen vom Team gemeinsam entschieden und getragen werden" [9]. "Setzen Sie zunächst den Kunden und die Entwickler, die die Schätzwerte erstellen sollen, an einen Tisch" [10]. Der Kundenvertreter dient zur Beantwortung von Rückfragen bei Unklarheiten. Das Team einigt sich auf Story Points pro User Story. Es gibt verschiedene Methoden, diese Schätzungen durchzuführen. Welche Arbeitszeit ein Story Point wirklich beinhaltet, zeigt die Velocity des Teams erst nach einigen Sprints.
Ein Themenobjekt besitzt nun eine Menge von geschätzten User Stories. Danach werden die User Stories priorisiert. Dazu wird ein Gemium gebildet, in dem unbedingt ein Kundenvertreter sitzen sollte. Man kann eine Priorisierungsmethode seiner Wahl verwenden. Allerdings sollte am Ende ein wirklicher Unterschied in den Prioritäten feststellbar sein. Die User Stories werden dann in der Reihenfolge ihrer Prioritäten abgearbeitet. Innerhalb gleicher Priorität werden die User Stories zuerst abgearbeitet, die ein hohes inhärentes Risiko tragen.
In Bezug auf die User Stories muss geklärt werden, welche Probleme zu lösen sind. Einschränkende Randbedingungen müssen ermittelt und ein Zielmodell aufgestellt werden. Da ich in meiner Methode Use Cases aus User Stories erstelle, ist es ebenfalls notwendig, die Unterschiede zwischen User Stories und Use Cases herauszuarbeiten.
User Stories und Use Cases sind nicht das Gleiche
"Einer der offensichtlichsten Unterschiede zwischen Stories und Use Cases ist deren Umfang. Beide sind größenmäßig so angelegt, dass sie einen Geschäftswert bieten, aber Stories werden kleiner gehalten, (beispielsweise nicht mehr als zehn Tage Entwicklungsarbeit), so dass sie zur Planung der Arbeit verwendet werden können. Ein Use Case deckt fast immer einen viel größeren Umfang als eine Story ab" [11]. COHN stellt fest, dass User Stories einzelnen Szenarien eines Use Cases gleichen. Sie können z.B. das Hauptszenario darstellen, wenn auch nicht notwendigerweise. Festzustellen bleibt, dass der detaillierte Ablauf einer User Story einem Szenario gleicht.
"User Stories und Use Cases unterscheiden sich auch im Grad der Vollständigkeit. James Grenning führt aus, dass der Text auf einer Story Card >>plus Akzeptanztests im Grunde dasselbe ist, wie ein Use Case<<. Grenning meint damit, dass die Story dem Szenario für den Haupterfolg des Use Cases entspricht und dass die Tests der User Story den Erweiterungen der Use Cases entsprechen" [12]. Hier wird noch einmal erhärtet, dass aus einer User Story Szenarien abgeleitet werden können. In den Akzeptanztests vermutet Grenning Alternativ- und Ausnahmeszenarien. Auch wenn COHN die 1:1-Entsprechung von User Story und Use Case anders sieht, so vermutet auch er zu entwickelnde Szenarien in einer User Story. Die abgeleiteten Szenarien einer oder mehrerer Stories können sich so zu einem Use Case zusammensetzen.
"Ein weiterer wichtiger Unterschied zwischen Use Cases und User Stories ist deren Langlebigkeit. Use Cases sind häufig permanente Artefakte, die solange bestehen, wie das Produkt aktiv entwickelt oder gewartet wird. Stories sind andererseits nicht dazu gedacht, die Iteration zu überleben, in der sie der Software hinzugefügt werden" [13]. Im Arbeitsprozess entwickelt das Team gemeinsam Szenarien aus den User Stories. Diese Szenarien werden zu Use Cases hinzugefügt. Sie können ggf. Use Cases ändern, indem alte Szenarien geändert oder gelöscht werden und neue hinzukommen. Im Use Case verbirgt sich die langfristige Beschreibung eines umzusetzenden Zusammenhangs. Die Dokumentation ist dabei das Ergebnis gemeinsamer Wissensarbeit und sie ist zur späteren Erinnerung an diesen Prozess gedacht. Auch für die Einarbeitung neuer Mitarbeiter ist eine Dokumentation eine Frage der Fairness und der Effizienz.
Bei der Ableitung von Szenarien aus User Stories und deren Zusammensetzung zu Use Cases muss darauf geachtet werden, dass die Szenarien nicht aus Annahmen zur Benutzeroberfläche bestehen. Die Entwicklung einer geeigneten Benutzeroberfläche ist dem Ausformulieren von Anforderungen nachgelagert. Man verwendet hier eine Lösung zur Formulierung des WAS und versperrt sich die Sicht auf andere Lösungen. COHN erwähnt, dass Constantine und Lockwood den Einsatz von Essential Use Cases vorgeschlagen haben. "Ein Essential Use Case ist ein Use Case ohne stillschweigende Annahmen zu Technologie und Implementierung" [14].
COHN zeigt außerdem auf, dass Use Cases und User Stories für unterschiedliche Zwecke geschrieben werden. Use Cases dokumentieren die Anforderung in einer für Kunden und Entwicklung akzeptablen und langfristigen Form. User Stories sind hingegen eher ein Planungsinstrument. Im beschriebenen Vorgehen bilden die User Stories einen Platzhalter zur Entwicklung von Use Cases und sie sind ein Mittel, das Vorgehen in Iterationen planbar zu machen. In diesem Vorgehen ist die User Story auch eine Erinnerung, Use Cases zu entwickeln.
Das soll nicht heißen, dass User Stories Szenarien sind. "Die primären Unterschiede zwischen User Stories und Szenarios sind Umfang und Ausführlichkeit. Szenarios enthalten viel mehr Einzelheiten und ihr Umfang deckt in der Regel mehrere Stories ab" [15]. Für die Arbeit im Team heißt das, Szenarios müssen entwickelt werden. Die User Stories sind nur der Anfang, der Ausgangspunkt der Arbeit, die in der Zusammenfassung der Szenarien in Use Cases endet.
"Ein Szenario beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele. Es konkretisiert dadurch eines oder mehrere Ziele. Ein Szenario enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext" [16]. Bei der Entwicklung von Aktionsfolgen zwischen Anwendung und Kontext spielt das Ziel eine besondere Rolle. Finden wir zu einem Szenario kein zu verwirklichendes Ziel, so ist dieses Szenario für die Anwendung ohne Wert. Somit haben wir die Szenarien mindestens mit den User Stories und mit den Zielen zu verknüpfen, aus denen wir sie abgeleitet haben und die sie erfüllen müssen.
Welche Szenarien kennen wir?
Für die Bildung von Use Cases spielen Haupt-, Alternativ- und Ausnahmeszenarien eine besondere Rolle. Wir kennen weitere Klassifizierungen für Szenarien, die in unserer Betrachtung nicht untersucht werden. Im Folgenden die Definitionen dieser Szenarioarten von POHL:
"Ein Hauptszenario ist ein Szenario, das die Interaktionsfolge dokumentiert, die normalerweise ausgeführt wird, um eines oder mehrere mit dem Szenario assoziierte Ziele zu erfüllen" [17]. Andere bezeichnen dieses Szenario auch als den Happy Path. Ein Use Case hat genau ein Hauptszenario.
"Ein Alternativszenario ist ein Szenario, das zu einem Hauptszenario eine alternative Interaktionsfolge definiert. Ein Alternativszenario erfüllt die gleichen Ziele wie das zugehörige Hauptszenario" [18]. Falls der normale Weg also nicht durchführbar ist, um das Ziel zu erreichen, werden Alternativen angeboten, die auf Umwegen zum Ziel führen.
"Ein Ausnahmeszenario ist ein Szenario, das eine Interaktionsfolge definiert, die ausgeführt wird, wenn in einem Szenario (Haupt-, Alternativ- oder anderes Ausnahmeszenario) ein Ereignis eintritt, das die Erfüllung eines oder mehrerer mit dem Szenario assoziierter Ziele verhindert" [19]. Ausnahmeszenarien zeigen also, wie im Fehlerfall gehandelt wird.
Szenarien setzen sich zu Use Cases zusammen
Im Deutschen kann man einen Use Case auch Anwendungsfall nennen. "Ein Anwendungsfall beschreibt anhand eines zusammenhängenden Arbeitsablaufs die Interaktionen mit einem (geschäftlichen oder technischen) System. Ein Anwendungsfall wird stets durch einen Akteur initiiert und führt gewöhnlich zu einem für die Akteure wahrnehmbaren Ergebnis" [20]. "Ein Anwendungsfall spezifiziert Aktionsfolgen (Szenarien) einschließlich Alternativ- und Ausnahmeszenarien, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen" [21]. Bei der Definition von OESTEREICH als auch bei der von POHL zählen Szenarien, Akteure und Ergebnis bzw. Mehrwert zu den Inhalten eines Use Cases.
Mit Hilfe unserer User Stories entwickeln wir Szenarien. Diese Szenarien können wir als Haupt-, Alternativ- und Ausnahmeszenarien kennzeichnen. Jetzt gilt es, die Szenarien so zu ordnen, dass sie sich in einem Use Case wiederfinden. Dabei ist es sehr hilfreich, dass jeder Use Case nur ein einziges Hauptszenario enthält. Auf diese Art und Weise können wir recht einfach Use Cases bilden. Jedes Hauptszenario initiiert einen Use Case. Die verbleibenden Szenarien werden den jeweiligen Use Cases zugeordnet. Alternativszenarien sind andere Wege, das Ziel des Hauptszenarios zu erreichen und Ausnahmeszenarien beschreiben den Ausstieg im Fehlerfall.
Jedes der zum Use Case zusammengefassten Szenarios ist mit der Verwirklichung eines oder mehrerer Ziele verbunden. Damit ergibt sich automatisch eine Menge von Zielen, die mit dem Use Case verbunden sind. Der Mehrwert des Use Cases ist somit gesichert.
Die Gesamtheit der Szenarios in einem Use Case nennt POHL ein Use Case-Szenario. "Ein Use Case-Szenario ist eine gültige Interaktionsfolge, die sich aus den für den Use Case definierten Haupt-, Alternativ- und Ausnahmeszenarien ergibt und zu einer definierten Terminierung des Use Cases führt. Terminierung bedeutet dabei, dass das Use Case-Szenario entweder zu der Erfüllung der mit dem Use Case assoziierten Ziele oder zu einem definierten Abbruch führt" [22].
Die Visualisierung eines Use Cases besteht somit aus einem Use Case-Diagramm und den Szenarien als Aktivitätsdiagramm. Es wäre vorstellbar, dass man zuerst das Use Case-Diagramm sieht. In diesem sind eine begrenzte Anzahl von Use Cases sichtbar. Nun klickt man einen Use Case an und öffnet ein Aktivitätsdiagramm, welches nur das Hauptszenario zeigt. Dieses kann sukzessive um Alternativ- und Ausnahmeszenarios erweitert werden.
Zu jedem Diagramm empfehle ich eine tabellarische Beschreibung. Diese erläutert in Textform das Gesehene. Hier kann man die Referenzschablonen von POHL verwenden. Er hat unter anderem Schablonen für Szenarien und für Use Cases entwickelt.
Der vorgestellte Weg zeigt eine eindeutige Entwicklungsrichtung auf. Ideen werden zu Themen geordnet. Themen werden Kontextobjekten, User Stories und Zielen zugeordnet. User Stories und Ziele gebären Szenarien und Szenarien werden zu Use Cases zusammengefasst. Diese eindeutige Richtung gibt es natürlich nicht. Der Denkprozess ist mehr oder weniger eine Kreisbewegung, die mit jedem erfolgten Schritt die Dinge genauer fasst. Ein ungenaues Ziel, eine ungenaue User Story initiiert ein grobes Szenario. Beim Entwickeln des Szenarios verfeinert sich die Zielvorstellung, die wiederum bessere Szenarien initiiert. Die Folgen dieses hin und her im Denken sind ein immer besseres Modell. Auch später kann sich dieses Modell durch Change Requests ändern.
Im weiteren Prozess bilden die Use Cases, die mit Zielen und Szenarien verbunden sind, die geeigneten Denkmodelle, um Anforderungen zu entwickeln. Dabei werden die Anforderungen aus unterschiedlichen Perspektiven bedacht: der Datenperspektive, der Funktionsperspektive und der Verhaltensperspektive, von POHL als traditionellen Perspektiven bezeichnet.
Drei Perspektiven öffnen uns den Weg zu den Anforderungen
Nachdem gezeigt wurde, wie man aus einer User Story und den dazu gehörenden Akzeptanztests Szenarien entwickelt und diese dann zu Use Cases zusammenfasst, können wir nun untersuchen, wie man auf diesem Weg weiter zu sinnvollen Anforderungen gelangt. Seitdem wir mit der Bildung von User Stories die Planungsphase verlassen haben, befinden wir uns mitten in der Entwicklungsphase. Das tiefe Durchdenken der Anforderungen ist Voraussetzung für die Vermeidung einer Reihe von teuren Fehlentwicklungen, die sonst in der Implementierungs- und Bugfixingphase behoben werden müssten. Die Ermittlung guter Anforderungen ist wichtig für die Entwicklung des richtigen Systems.
Laut POHL bilden Ziele und Szenarien die Grundlage für lösungsorientierte Anforderungen. "In der Regel ist es nicht möglich, alle lösungsorientierten Anforderungen vollständig, präzise und im notwendigen Detaillierungsgrad aus den vorhandenen Zielen und Szenarien abzuleiten. Die Vervollständigung, Präzisierung und Detaillierung der lösungsorientierten Anforderungen erfolgt daher inkrementell durch den Einsatz von Gewinnungstechniken. Durch die Gewinnung neuer Ziele und Szenarien wird die Gewinnung von lösungsorientierten Anforderungen bzw. deren Detaillierung fokussiert und unterstützt" [23]. Im beschriebenen Modell sind alle schon erwähnten Objektarten bei der Gewinnung von Anforderungen zu beachten.
Bei der Analyse spielen die folgenden Perspektiven zur Beschreibung von Anforderungen eine große Rolle:
"Datenperspektive: Die Datenperspektive betrachtet die statische Struktur der Daten (d.h. Datentypen, deren Attribute sowie Beziehungen zwischen den Datentypen) und wird daher auch als Strukturperspektive bezeichnet.
Funktionsperspektive: Die Funktionsperspektive betrachtet die Manipulation der Daten durch die Funktion des Systems, d.h. die Transformation von Eingaben und Funktion in Ausgaben.
Verhaltensperspektive: Die Verhaltensperspektive beschreibt das Verhalten des Systems, d.h. dessen Reaktion auf externe Stimuli in Form von erlaubten Zuständen, Zustandsänderungen und erzeugten Ausgaben" [24].
Die Diskussion der drei Perspektiven erfolgt im Team und mit den jeweiligen Stakeholdern. Jede Perspektive wird dabei mit einer geeigneten Modellsprache durchdacht. Wir verwenden für alle drei Perspektiven die UML. Die Datenperspektive wird mit Hilfe des Klassendiagramms modelliert, die Funktionsperspektive mit Aktivitätsdiagrammen und die Verhaltensperspektive mit Zustandsdiagrammen. Jedes Diagramm wird durch eine Tabelle erläutert, in der genauere Informationen abgelegt werden.
Im Folgenden erläutere ich nur die Betrachtung der Datenperspektive. Für die anderen Perspektiven verweise ich auf die Darstellung in meinem Blog [25]. Die Datenperspektive wird durch ein Klassendiagramm dargestellt (s. Abb. 4).
Die erklärende Tabelle dient der genaueren Erläuterung des Klassendiagramms und man kann mit Hilfe der Tabelle das Diagramm rekonstruieren. In der Tabelle findet man die Klassennamen, die zugehörigen Attribute, Methoden und Beziehungen. In der Tabelle werden außerdem alle Beschreibungen hinterlegt, die sich nicht in Modellelementen ausdrücken lassen. Somit wäre eine automatische Validierung möglich, die eventuelle Unstimmigkeiten im Modell aufzeigt.
Erläuterung des Klassendiagramms
| ID-ParentID | Typ | Untertyp | Anforderungsname | Beschreibung |
|---|---|---|---|---|
| 1-0 | Klasse | - | Lehrer | Ein Lehrer ist eine Fachkraft zum unterrichten von Schülern. |
| 2-1 | - | Attribut | Fach | Jeder Lehrer unterrichtet ein spezifisches Fach. |
| 3-1 | - | Attribut | Gehalt | Jeder Lehrer bezieht ein festes monatliches Gehalt. |
| 4-1 | - | Verhalten | unterrichten | Ein Lehrer unterrichtet Schüler. |
| 5-1 | - | Beziehung | besitzt Klasse | Jedem Lehrer ist eine feste Klasse zugeordnet. |
| 6-0 | Klasse | - | Schüler | Ein Schüler ist ein junger Mensch, der etwas lernen will. |
| ... | ... | ... | ... | ... |
Die Funktionsperspektive stellt Algorithmen dar. Somit gibt es eine Verknüpfung mit der Datenperspektive über den Untertyp Verhalten. In der Funktionsperspektive beschreiben wir den zugehörigen Algorithmus durch ein Aktivitätsdiagramm und eine erläuternde Tabelle.
In der Verhaltensperspektive werden einzelne Objekte (Klassen) auf ihre Zustände hin untersucht. Die Zustandsübergänge bilden wieder Methoden, die durch Algorithmen in der Funktionsperspektive abgebildet werden können. Somit ergeben sich vielfältige Verknüpfungen zwischen den verschiedenen Perspektiven.
Die gemeinsame Diskussion dieser Perspektiven und deren Dokumentation erfolgt im Team und mit den jeweils erforderlichen Stakeholdern. So gewinnt man ein gemeinsames mentales Modell und steigert das Verständnis des Anforderungsgegenstandes enorm.
Quellen
[1] Requirements Engineering - Der Frei-Tags-Blog.
[2] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 26
[3] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 39
[4] Wikipedia: User Story
[5] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 73
[6] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 92
[7] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 93
[8] Requirements Engineering - Der Frei-Tags-Blog.
[9] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 108
[10] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 108
[11] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 153
[12] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 155
[13] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 155
[14] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 156
[15] Mike Cohn, 2010: "User Stories", 1. Auflage, mitp, Heidelberg, S. 159
[16] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 123
[17] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 137
[18] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 137
[19] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 138
[20] Bernd Oestereich, 2006: „Analyse und Design mit UML 2.1“, 8. Auflage, Oldenbourg Wissenschaftsverlag GmbH, München, S. 220
[21] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 139
[22] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 140
[23] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 184
[24] Klaus Pohl, 2008: "Requirements Engineering", 2. Auflage, dpunkt.verlag GmbH, Heidelberg, S. 184
[25] Requirements Engineering - Der Frei-Tags-Blog.
Robert
am 23.06.2022Der PO wird sich natürlich mit anderen Personen abgestimmt haben, aber die tatsächliche Entscheidung der Priorisierung der Items im Product-Backlog obliegt bei Scrum nur dem PO.