Übungen "User Stories, Epics, Product Backlog Items"
Zusammenfassung¶
Hier finden Sie die Definitionen der wichtigsten Begrifflichkeiten aus diesem Kapitel.
INVEST-Kriterien¶
- Independent (= unabhängig)
- Negotiable (= verhandelbar)
- Valuable (= wertvoll)
- Estimable (= abschätzbar)
- Short (= kurz)
- Testable (= testfähig)
Drei Cs¶
- Card - physisch oder digital
- Conversation - Product Owner und Developer haben sich ausführlich über die User Story ausgetauscht
- Confirmation - Akzeptanzkriterien (acceptance criteria) wurden festgehalten
CTF-Kriterien¶
- Clear (= klar verständlich)
- Testable (= testbar)
- Feasible (= machbar)
Agiles Schätzen¶
Relative Abschätzung des Arbeitsaufwandes der Einträge im Product Backlog anhand von Story Points o. ä., üblicherweise im Team.
Definition of Ready¶
Eine Bezeichnung für Einträge im Product Backlog, welche von den Developern verstanden wurden und bereit für die Umsetzung im nächsten Sprint sind. Üblicherweise handelt es sich dabei um oben gelistete Einträge.
Story Points¶
Der gefühlte Arbeitsaufwand und die Wertigkeit einer User Story. Beeinflusst werden können Story Points bspw. durch Unsicherheiten, durch die Menge und die Komplexität der Arbeit. Sie sind weder monetär noch zeitbasiert, sondern sie stellen selbst die Maßeinheit dar, um die Product Backlog Items schätzen zu können.
Planning Poker¶
Planning Poker, auch bekannt als Scrum Poker, hilft Developern den relativen Aufwand bzw. die Komplexität einzelner Product Backlog Items abzuschätzen. Hierfür kommen die Developer im Team zusammen und verwenden eine Art Kartenspiel. Auf die Karten werden Zahlen, Kleidergrößen etc. geschrieben, die zur Schätzung herangezogen werden.
Übungsfragen¶
Bitte beantworten Sie die folgenden Fragen selbstständig. Nehmen Sie sich Zeit und überlegen Sie genau, was Sie antworten würden, bevor Sie sich die Lösungen anzeigen lassen.
Welche sind die Inhalte von User Stories?
Eine User Story beinhaltet Informationen bezüglich "Rolle" (wer?), "Funktionalität" (was?) und "Geschäftswertbeitrag" (warum?). Wenn eine User Story formuliert wird, sollte folgender Satz um die Rolle die der Nutzer einnimmt, die Funktionalität die von der User Story erwartet wird und den Geschäftswertbeitrag ergänzt werden:
Als ... möchte ich ..., so dass ...
Was bedeutet Definition of Ready?
Der Status "Definition of Ready" (DoR) bedeutet, dass ganz oben im Product Backlog gelistete User Stories so formuliert sein müssen, dass diese für die Developer verständlich sind und beim nächsten Sprint bearbeitet werden können.
Wieso werden User Stories überhaupt geschrieben? Worauf muss beim Verfassen geachtet werden?
User Stories helfen den Developern zu verstehen, was sich Endnutzer wünschen und Endnutzer können unkompliziert ihre Wünsche mitteilen, ohne über technisches Know-how verfügen zu müssen. Auf diese Art und Weisen wird ein gemeinsames Verständnis geschaffen. Beim Verfassen sollten die drei Cs beachtet werden und User Stories sollten den INVEST- oder CTF-Kriterien genügen.
Wer schreibt User Stories?
User Stories werden aus Sicht des Anwenders formuliert - geschrieben werden können sie vom Anwender selbst, vom Product Owner oder gemeinschaftlich vom Product Owner mit den Developern.
Wofür steht das Akronym INVEST?
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
In welchem Zusammenhang finden INVEST- bzw. CTF-Kriterien Anwendung?
INVEST- bzw. CTF-Kriterien sind wichtig, wenn es um die Definition of Ready geht. User Stories, die sich weiter oben im Product Backlog befinden müssen "ready" sein, dass die Developer mit der Umsetzung beginnen können. Das heißt, die Developer müssen sagen, dass sie die User Stories verstanden haben und diese müssen den INVEST bzw. CTF-Kriterien genügen, dass sie im Sprint umgesetzt werden können.
Erläutern Sie die drei Cs der User Stories.
Card: Die wichtigsten Daten einer User Story werden auf einer Karte festgehalten. Dazu gehören die Priorität der User Story, ihre Akzeptanzkriterien und auch der Arbeitsaufwand für die Umsetzung einer User Story, der in einer Schätzklausur ermittelt wurde. Da eine Karte nur begrenzt Platz bietet, muss die User Story auf den Punkt gebracht werden.
Conversation: Aus einer User Story, die kurz und knapp formuliert ist, sollte sich ein Gespräch zwischen Product Owner und den Developern ergeben. Diese sollen sich ausführlich über die User Story austauschen und jeder soll das Ziel der User Story verstehen.
Confirmation: Aus dem Gespräch zwischen Product Owner und Developer müssen sich Akzeptanzkriterien (acceptance criteria) ergeben, welche festgehalten werden. Der Product Owner nimmt die Umsetzung der User Story als Increment durch entsprechenden Akzeptanztests ab.
Was ist ein Story Point?
Story Points stellen den gefühlten Arbeitsaufwand dar und spiegeln die Wertigkeit einer User Story wider. Beeinflusst werden können Story Points bspw. durch Unsicherheiten, durch die Menge und die Komplexität der Arbeit. Sie sind weder monetär noch zeitbasiert, sondern sie stellen selbst die Maßeinheit dar, um die Product Backlog Items schätzen zu können.
Worauf wird beim Agilen Schätzen verzichtet und wieso?
Es wird auf konkrete Vorhersagen verzichtet (z. B. auf die Angabe von Arbeitsstunden). Vielmehr geht es darum, relative Größen zu ermitteln. Durch die relativen Aufwandsgrößen ist es einfacher, die Release-Pläne an geänderte Randbedingungen, die die Velocity (Entwicklungsgeschwindigkeit) verändern, anzupassen, und die Auswirkungen der Veränderungen zu bewerten. Der Fokus wird, statt auf genaue Zahlen auf eine gewollte Ungenauigkeit und damit auf nicht lineare Zahlenskalen gesetzt. Zusätzlich wird die Abschätzung "aus dem Bauch" heraus vorgenommen.
Welche Möglichkeiten der Schätzung gibt es?
Gängige Methoden zur Schätzung sind die Fibonacci-Folge oder Kleidergrößen.