Anforderungs-Management

Spiel: https://miro.com/app/board/o9J_lcazzOo=/

Disclaimer

• Keine Wahrheit, Meine Erfahrung / Beobachtung

• Ich möchte im besten Sinne Impulse für Eure Arbeit setzen

• Unterschiedlicher Detailgrad

• Ich denke immer im agilen Umfeld

• Manfred (Manne) Wolff

• im 22. Jahr bei Neusta

• Agile Coach - Architekt - (Trainer) - Business Analyst

Disclaimer

• Keine Wahrheit, Meine Erfahrung / Beobachtung

• Ich möchte im besten Sinne Impulse für Eure Arbeit setzen

• Unterschiedlicher Detailgrad

• Ich denke immer im agilen Umfeld

• Produktvision / -ziel

• MVP

• Rollen / Personas

• Anforderungen aufschreiben

• Story Mapping (Spiel)

• Anforderungen schneiden

Produktvision / -ziel

MVP

 minimal viable product 

lebensfähig / realisierbar

MVP

Product Owner

MVP

• Produktpflege

• Suche

• Ergebnisseite

• Detailseite

• Warenkorb

• Checkout

• Fulfilment / Rücksendung

• Payment

• Logistik

• ...

• Parfum (30 Produkte)

• Abhohlung

• Bezahlung vor Ort

MVP

• Produktpflege (30 Produkte)

• Suche

• Ergebnisseite

• Detailseite

• Warenkorb

• Checkout

• E-Mail Prozess

• Fulfilment

• Payment

• Abhohlprozess

• Logistik

• ...

Personen / Personas

Personas (lat. Maske) sind Nutzermodelle, die Personen einer Zielgruppe in ihren Merkmalen charakterisieren.  Personas verfügen über Ziele und Verhaltensweisen, haben Vorlieben und Erwartungen.

Persona A

• Name: Manuel Stoll, Alter: 19

• Beruf: Student

• Herkunft: Kassel

• Bedürfnisse: günstig, zuverlässig, cool

• Befürchtungen: Er ist sich nicht sicher, ob er für sein mühsam erspartes Budget sowohl ein zuverlässiges als auch einigermaßen cooles Fahrzeug bekommen kann.

• Kontaktpunkt: Manuel sucht über Google Fahrzeughändler, stöbert aber auch durch die Angebote auf Mobile24.de.

• Zitat: „Ich bin Manuel und habe vor ein paar Monaten meinen Führerschein bekommen. Nun habe ich etwas Geld zusammen, um mir ein Auto für die Strecken zwischen Uni und Nebenjobs leisten zu können. Ich weiß, dass ich mir nicht den neuwertigen Sportwagen leisten kann, den ich gerne hätte, doch ich suche alle Online-Angebote durch bis ich zumindest ungefähr das kriege, was gleichzeitig Geldbörse und Optik befriedigt.“

Persona B

• Name: Frank Neuberger, Alter: 46

• Beruf: Geschäftsführer

• Bedürfnisse: Firmenflotte, strapazierfähig, technische Ausstattung (Navigation etc.)

• Befürchtungen: Er ist bemüht möglichst das beste Angebot im Preis-Leistungsverhältnis zu bekommen und fürchtet, dass ihm kurz nach dem Kauf doch etwas Günstigeres oder ein besserer zusätzlicher Service bei einem anderen Anbieter auffällt.

• Kontaktpunkt: Herr Neuberger holt sich Tipps von Geschäftsfreunden und aus der Belegschaft ein, die er dann online überprüft.

• Zitat: „Guten Tag, wir benötigen mehrere Kraftfahrzeuge, die ein hohes Fassungsvermögen für unsere Ausrüstung aufweisen. Gleichzeitig müssen die Modelle aber auch repräsentativ sein und unseren Fahrern ein gewisses Maß an Komfort bieten, da diese den Großteil ihres Tages darin verbringen.“

Persona C

• Name: Elisabeth Müller

• Alter: 71

• Beruf: Rentnerin

• Bedürfnisse: komfortabel, niedrige Ladekante im Kofferraum

• Befürchtungen: Elisabeth ist sich nicht sicher, ob sie einem Händler vertrauen kann und bringt einen sachverständigen Verwandten mit.

• Kontaktpunkt: Sie lässt sich von ihrem sachverständigen Verwandten einen Händler empfehlen.

• Zitat: „Hallo, mein Name ist Elisabeth Müller. Ich suche ein ganz einfaches Fahrzeug, das gar nicht so viel Schnickschnak braucht. Es soll nur bequem sein. Und wenn ich meinen Koffer in den Kofferraum lade (für die Tour zu meinen Kindern), dann muss das einfach gehen. Da möchte ich den Koffer nicht so fürchterlich hoch heben müssen.“

Persona vs. Rolle

• Produktangebot

• Usability

• Design

• Verfügbarkeit

• ...

Wo spielen Personas eine Rolle

Anforderungen schreiben

Card

User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Softwareentwicklungsteam vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten.

CCC

Card - Conversation - Confirmation

Als [Nutzer] möchte ich [Funktion], damit / um / weil [Wert].

[Nutzer] – Wer?

Den Platzhalter [Nutzer] füllst Du mit Rollen bzw. deinen Personas. Eine Persona ist ein typischer Vertreter deiner Zielgruppe. Die Rolle des Nutzers kann auch  durch den jeweiligen Kontext definiert sein. So kann die gleiche Rolle z.B. für unterschiedliche Personas gelten und das Verhältnis zu deinem Produkt beschreiben.

[Funktion] – Was?

Den Platzhalter [Funktion] ersetzt Du mit der Erwartung, den Zielen und Wünschen der [Nutzerin]. Damit beantwortest Du die Frage, WAS der Kunde braucht und erwartet. 

[Wert] – Warum?

Der Platzhalter [Wert] beantwortet die Frage nach dem WARUM. Auch wenn der Satzbau dazu verleitet diesen Nebensatz weg zu lassen, ist eine User Story ohne diesen Zusatz nicht komplett.

Das heißt, erst mit dem [Wert] bringst Du zum Ausdruck, warum die Erreichung der [Funktion] für den [Nutzer] überhaupt wichtig ist und welchen Mehrwert die Erfüllung der User Story schafft. 

I   
N
V
E
S
T

ndependent
egotiable
aluable
stimable
mall
estable

Bill Wake: INVEST in Good Stories, and SMART Tasks, XP123 Blog, erschienen am 17. August 2003, abrufbar unter http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Independent bedeutet, dass die User Story unabhängig von anderen sein soll. Ihr werdet mit Sicherheit den Fall entdecken, dass Ihr eine Story vor der anderen machen müssen. Vermeidet aber User Stories zu schreiben, in denen Ihr zum Beispiel 20 User Stories umsetzen müsst, da Sie sonst bei Problemen im Sprint gar nichts liefern können.

Negotiable bedeutet, dass die User Story immer verhandelbar sein muss. Sie ist also nie so ausspezifiziert, dass diese einmal festgelegt wird und dann in die Umsetzung kommt. Die Beschreibung ist bewusst so gewählt, dass schnell und kostengünstig neu über die User Story verhandelt werden kann und diese dann auch neu geschrieben werden kann. Während diese im Product Backlog vorhanden ist, besteht laufend die Möglichkeit diese zu verändern.

Value bedeutet, dass die User Story immer einen Mehrwert besitzen muss. Eine User Story ist also nicht Mittel zum Zweck, sondern liefert einen (in sich abgeschlossenen) Mehrwert. Das hilft auch für die Bildung des Inkrements, was am Ende des Sprints (alter Scrumguide) zur Verfügung stehen muss.

Estimated bedeutet, dass die User Story eine Schätzung benötigt. Auch wenn sich die Story Points vielerorts durchgesetzt haben, sind diese nach dem Scrum Guide keine Pflicht. Auch ist im neuen Scrum Guide die Schätzung kein Pflichtfeld mehr im Backlog.

Sizeable (Small) bedeutet, dass die User Story die richtige Größe besitzen muss. Sie passt maximal groß in einen Sprint. Alles was nicht in einen Sprint passt, ist erstmal ein Epic und muss dann weiter zerteilt werden. Das kann im Backlog Refinement durchgeführt werden.

Im Idealfall übersteigt die Größe einer Story nicht einem (Paar-)Bearbeitungstag.

Eine gute User Story ist testbar. Das bedeutet, dass diese User Story von einer Tester:in, Endanwender:in oder weiteren Stakeholdern getestet werden kann. Dazu gibt es in der Regel Akzeptanzkriterien aus Benutzer:insicht, damit ein Testen auch möglich ist. Zudem kann der Product Owner so seine Erwartungshaltung an diese User Story ausdrücken.

I   
N
V
E
S
T

ndependent
egotiable
aluable
stimable
mall
estable

Conversation

Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story ist erfahrungsgemäß ein sehr wichtiger Prozess. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und diese dem Team sozusagen „durch den Türschlitz“ zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während eines Anforderungsworkshops, im Rahmen einer Schätzklausur und bei der Sprint-Planung. Die mündlichen Absprachen werden zudem manchmal durch zusätzliche Dokumente wie etwa Vorlagen in einem Projekt-Wiki oder Mockups begleitet.

CCC

Card - Conversation - Confirmation

Confirmation

Um nachzuweisen, dass die Stories in der gewünschten Form implementiert worden sind, werden für jede Story verbindliche Akzeptanzkriterien vereinbart: Der Kunde definiert vor Beginn der Umsetzung einer Story die zentralen Kriterien, nach denen die Abnahme der Story später erfolgen soll. Hierbei bietet sich die Implementierung von Akzeptanztests an, um die Erfüllung der Akzeptanzkriterien sicherzustellen.

CCC

Card - Conversation - Confirmation

• Product Backlog Item (PBI) ist klein genug (z. B. kann im "pair" an einem Tag abgeschl. sein)
• PBI ist für jeden Beteiligten klar verständlich
• PBI ist geschätzt
• PBI hat Akzeptanzkriterien (Min. 1)
• Akzeptanzkriterien sind von jedem Beteiligten verstanden
• PBI hat einen Wert
• Ursprung des PBI ist klar

DoR

• Product Backlog Item (PBI) ist klein genug (z. B. 4-5 User Storys passen in einen Sprint)
• PBI ist für jeden Beteiligten klar verständlich
• PBI ist geschätzt
• PBI hat Akzeptanzkriterien (Min. 1)
• Akzeptanzkriterien sind von jedem Beteiligten verstanden
• PBI hat einen Wert
• Ursprung des PBI ist klar

Story-Map(ing)

Text

Story Mapping ist eine Technik, mit der ausgehend von der User Experience das Big Picture der Anforderungen übersichtlich dargestellt werden kann. Dabei bleibt stets der Kundenfokus erhalten.

Text

Epic ist eine User Story, die in weitere User Storys strukturiert wird. Epics beschreiben Anforderungen auf einer allgemeinen, nicht direkt durch Funktionen eines Produkts umsetzbaren Ebene.

Text

• Backbone: Epics ermitteln und auf der Zeitleiste darstellen.

• Tasks (User Stories) für jedes Epic pro Persona ermitteln .

• MVP (Minimal Viable Product) und weitere Inkremente festlegen.

Lasst uns spielen

Kurze Miroeinführung

https://miro.com/app/board/o9J_lcazzOo=/

Was ist der normale Tagesablauf zwischen “Weckerklingeln" und "Abfahrtbereit für den Bus" sein.

„Ich habe verschlafen und nur noch zehn Minuten bis der Bus abfährt. Was sind die wichtigsten Aktivitäten, die ich bis zum Verlassen der Wohnung erledigen muss, um rechtzeitig den Bus zu erreichen?“

„Ich höre den Bus schon, ich habe nur noch zwei Minuten !!"

Schnittmuster zum Schneiden

Die können wir nicht kleiner schneiden, sonst haben wir keinen Mehrwert.

Wie groß ist zu groß?

• 6-10 Stories in einer Iteration

• Die Stories sollen gleich groß sein

• Bestenfalls soll die Story in einem Tag umsetzbar sein

Grundsätze

• 80 / 20 Prinzip

• So klein wie möglich

• Wenn alle Stories gleich groß sind, braucht man nicht mehr zu schätzen

Wie groß ist zu groß?

In der Softwareentwicklung gibt es eine alte Regel, die auf jahrzehntelanger Forschung beruht, wonach 80 Prozent des Mehrwertes einer beliebigen Software von 20 Prozent der Funktionalität bestritten werden.  Überlegen Sie einmal: Wann haben Sie zum letzten Mal den Visual Basic Editor in Microsoft Word verwendet?

Jeff Sutherland: Die Scrum-Revolution

Grundsätze

• 80 / 20 Prinzip

• So klein wie möglich

• Wenn alle Stories gleich groß sind, braucht man nicht mehr zu schätzen

Workflow Steps

• Ich kann einen neuen Blog-Eintrag direkt auf der Website veröffentlichen

• Ich kann den Eintrag nur nach einem Review veröffentlichen.

• Ich kann einen Eintrag auf einer Staging Area vorveröffentlichen

• ...

Simple / Complex

Operations (z.B. CRUD)

• Ein User kann einen neuen Account anlegen

• Der User kann seinen Account editieren

• Der User kann seinen Account löschen

https://agileforall.com/patterns-for-splitting-user-stories/

Ausblick

Ordered: Die Einträge sind von oben nach unten geordnet, damit das bearbeitende Team weiß, welche Aufgaben und Anforderungen wichtig für den Product Owner sind.

Backlog

Prinzipien von DDD

Konzentration auf die Kerndomäne

Ich kann nicht in der ganzen Domäne eine hohe und gleichbleibende Qualität garantieren.

Wo wird das Geld gemacht, wo differenzieren wir uns?

Nach Eric Evans sollte die Core Domäne

• 20% des Wertes des Systems liefern
• 5% der Codebasis ausmachen
• 80% des Aufwands in Anspruch nehmen
• Von den Besten der Besten entwickelt werden

Unterschiedlich detailliert: Die oberen Einträge sind sehr detailreich während sie nach unten hin immer gröber und ungenauer werden. Das ist wichtig, da die oberen Einträge sehr wahrscheinlich mit in den nächsten Sprint kommen werden. Oftmals ist es auch so, dass ein grober Eintrag in mehrere kleine und detaillierte Einträge aufgeteilt wird.

Backlog

Geschätzt: Der Arbeitsaufwand des Product Backlog Items wird vom Team, welches das Item auch bearbeitet, geschätzt. Die Aufwandsschätzung der oberen Einträge ist auch hier wieder präziser. Der Arbeitsaufwand kann von “sehr geringer Aufwand” bis “extrem hoher Aufwand” gehen.

Backlog

Bewertet: Items die weniger aufwendig sind, dafür aber einen großen Nutzen bzw. Wert für den Product Owner haben, rutschen in der Liste weiter nach oben.

Backlog

Dynamisch: Da es sich beim Product Backlog um eine Art dynamische Liste handelt, ist es zu jeder Zeit möglich, dass Einträge hinzugefügt oder auch entfernt werden. Bereits abgeschlossene Items werden mit “done” gekennzeichnet.

Backlog

Alle Fotos unterliegen der Creative Common Licence.

https://pixabay.com/de/