In Projekten sind die klassische Requirements-Analyse und die Erstellung von detaillierten Lasten- und Pflichtenheften sehr aufwändig und es dauert oft lange, bis diese von allen Beteiligten abgesegnet sind.
Auch zeigt die genaue Erfüllung und Umsetzung am Ende des Projekts oft, dass sich während der Projektlaufzeit Anforderungen, Technologie und die Erwartungen bei den Nutzern verändert haben und daher aufwändig umgesetzte Anforderungen nicht mehr dem Stand der Technik oder den Erwartungen der Nutzer*innen entsprechen.
Agile Methoden, insbesondere SCRUM, konzentrieren sich von Anfang an auf die Kundenanforderungen und -wünsche, die nicht als detaillierte Lasten- und Pflichtenhefte beschrieben werden, sondern als kurze, prägnante User Storys, die aus der Sicht der Anwender formuliert werden. Daraus resultiert jeweils eine rasche Einzellösung, die sich auf genau eine formulierte Problemstellung ausrichtet. Aufwandsschätzungen, Termine und Pläne werden auf der Ebene der einzelnen User Storys formuliert und sind für das Team dann bindend.
Die Erfolg der Umsetzung hängt also ganz wesentlich von gut formulierten User Storys ab.
Mit diesen 6 Kriterien lässt sich erkennen, ob eine User Story gut ist *)
- Unabhängig: Jede einzelne User Story sollte unabhängig von anderen Storys sein. Die Umsetzung einer Story darf nicht voraussetzen, dass vorher eine andere Story umgesetzt wurde.
- Verhandelbar: User Storys sind nicht unveränderbar. Product Owner, Stakeholder und das Entwicklerteam diskutieren und präzisieren die User Story gemeinsam, um ein optimales Verständnis zu erzielen.
- Nützlich: Das Ergebnis der User Story muss für den Anwender sinnvoll sein und Nutzen stiften.
- Schätzbar: Das Entwicklerteam muss die Aufwände für die Realisierung abschätzen können.
- Klein: Der Umfang der User Story sollte in einem Sprint realisierbar sein.
- Testbar: Jede User Story muss getestet werden können, um die erfolgreiche Umsetzung feststellen zu können.
*) siehe INVEST-Kriterien (William Wake)
