Scrum-Grundlagen: Agile Softwareentwicklung

User Stories

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
User Stories, Business Value, Story Points: Lernen Sie, wie man komplexe Funktionalität in einem einzigen Satz beschreiben kann und warum das manchmal ganz schön schwer ist.
07:02

Transkript

Funktionalität in einem Product-Backlog wird oft in Form von User Stories definiert. Zu den User Stories gibt es noch Story Points und Business Value und diese drei Themen sind Inhalt von diesem Film. Was ist eine User Story? Eine User Story ist eine schematisierte Art und Weise, um Funktionalität greifbar zu machen. Ich versuche also, neben der Priorität und einem Titel wie z.B. "Startseite" oder "Log-in", einen Satz zu definieren, der immer den gleichen Aufbau hat: Als "irgendwer" will ich "irgendwas", damit "ich" einen Zweck erfüllen kann. Immer diese drei Teile. Das wird jetzt Lyriker unter uns etwas langweilen, weil es doch immer gleich klingt, aber ein Softwareentwickler stellt sicher, dass ich wirklich immer alle drei Aspekte abgedeckt habe und damit auch herausarbeiten kann, warum ein Feature überhaupt entstehen soll. Neben diesem Satz, den wir uns in einer Minute ein bisschen genauer anschauen, gibt es noch Akzeptanzkriterien - quasi Kleingedrucktes - was diese Story erfüllen muss, damit sie auch wirklich den Wert bringt, den sich der Product Owner wünscht. Es wird ein Grobaufwand geschätzt, in Story Points, und ein Business Value, quasi der Geschäftswert, nicht in Dollar oder Euro, sondern in einer abstrakten Einheit, den diese Funktionalität dem Kunden, bzw. dem Product Owner, bringen würde. Lassen Sie uns eine konkrete User Story anschauen. Wir sind wieder bei unserem Beispiel, der Online-Videothek 3000, und eine Anforderung, eine User Story, könnte sein: Als Bestandskunde will ich meine Adressinformationen speichern können, um sie nicht bei jeder Bestellung neu eingeben zu müssen. Bestandskunde wäre der "Aktor", Adressinformationen speichern wäre das "Feature", und sie nicht neu eingeben zu müssen wäre der "Zweck" der Story. Was haben wir hier als Kleingedrucktes, als Akzeptanzkriterien? "Liebes Entwicklerteam, bitte achte darauf, dass wir eine Unterscheidung brauchen zwischen "Lieferadresse" des Films und "Rechnungsadresse. Und wenn ihr die Anschrift überprüft, achtet bitte darauf, dass die Postleitzahl in einem gültigen Format ist. Da genügt es uns für den Anfang, dass wir nur das Postleitzahlenformat von Deutschland angeben." Das wäre eine typische User Story. Diese User Story wird angereichert mit "Priorität" und "Business Value". Die Priorität ist einfach zu greifen: Je kleiner die Zahl ist, desto wichtiger ist es. Wenn man sich unser Product Backlog anschaut, da ist ganz klar: Prio 1 hat die Startseite, Prio 2 hat die Kontaktseite, Prio 3 haben die Produktseiten für die Actionfilme und Prio 4 hat das Impressum. Reicht uns das nicht schon? Dem Entwicklerteam würde es helfen, neben der Priorität noch besser einschätzen zu können, wie die untereinander gewichtet sind. Sie wissen die Priorität, aber sie wissen nicht, um wieviel wichtiger Prio 1 als Prio 2 ist usw. Und deswegen kann man mit einem Business Value arbeiten. Stellen Sie sich vor, das ist eine Einheit, die von 1 bis 1000 geht. 1000 von 1000, das wäre sehr wertvoll für den Erfolg unserer Online-Videothek und 0 von 1000 wäre: "Muss ich vielleicht machen, aber damit verdiene ich keinen müden Euro mehr." Wenn wir uns das hier mal anschauen: 900 von 1000. Die Startseite scheint wirklich wichtig zu sein. Solange die nicht da ist, existiert die Firma im Internet nicht, und wir verdienen kein Geld. Wenn Sie sich aber z.B. den Unterschied zwischen Zeile 3 und 4 anschauen: Die Produktseite für die Actionfilme hat einen Business Value von 600 von 1000 und die Impressum-Seite auf einmal nur 200 von 1000. Also die ist wesentlich unwichtiger. Diese Gewichtungsunterschiede würden wir mit "Priorität" alleine nicht abdecken können, deswegen nimmt man noch den Business Value dazu. Der Aufwand für eine Funktionalität, für ein Feature, für eine User Story, wird abstrakt abgeschätzt in sogenannten "Story Points". Story Points sind eine abstrakte Größe, um Funktionalität, oder den Umfang von Funktionalität, zu messen, abzuschätzen. Und hier versucht man bewusst, von Personentagen oder von nötigen Stunden wegzugehen und eine abstrakte Einheit zu wählen. Die muss jetzt auch nicht Story Points heißen, sondern es kann auch genauso gut "Äpfel", "Birnen" oder "Bratwürste" sein. Das Ganze hat den Hintergedanken, dass man dieses lästige Stunden- jonglieren vermeiden will. Sie kennen vielleicht zwei Typen von Software Teams. Das eine Team neigt dazu, sich gegenseitig immer zu unterbieten. "Was, du brauchst 12 Stunden für dieses Feature? Ich mach's dir in 10." Und das andere Team ist eher konservativ unterwegs und sagt: "Ja, 12 Stunden, das ist schon fast ein bisschen knapp. Lass uns mal 20 schätzen." Dazwischen gibt es natürlich noch viele Graustufen von Teams, aber diese zwei Extreme sieht man ab und zu mal. Und wenn man was Abstraktes nimmt und die Stunden weglässt, fällt es den Teams leichter, irgendetwas in Relation zueinander zu sehen. Darum geht es auch. Man kann viel leichter einschätzen: Dieses Feature ist ungefähr 5 groß und das andere, naja, ich denke, es ist ungefähr doppelt so umfangreich, also 10. Und schon ist es ganz leicht, irgendetwas gegeneinander zu vergleichen und nicht mehr in absoluten Zahlen zu messen. Ein Story Point misst die Größe des Funktionsumfangs. Da scheiden sich in der Scrum-Welt auch ein bisschen die Geister. Ist es am Ende nicht doch der Aufwand, nur in einer anderen Einheit? Letztlich denke ich: Es ist egal, solange eine einheitliche Definition innerhalb Ihres Teams dafür vorliegt. Und Sie können auch davon ausgehen: Je größer ein Team Story Points schätzt, desto unklarer ist das Feature. Sie müssen es kleiner schneiden, in kleinere Häppchen verpacken oder Sie müssen es besser erklären, es könnte auch ein Indiz sein. Das waren Story Points, das war Business Value und das waren User Stories.

Scrum-Grundlagen: Agile Softwareentwicklung

Machen Sie sich mit der Softwareentwicklung mit Scrum vertraut und sehen Sie, wie Sie komplexe Projekte agiler, qualitativ besser, kundenorientierter und motivierter meistern.

3 Std. 34 min (49 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!