User Stories sind der heilige Gral in der agilen Softwareentwicklung. Es gibt eine Art sie gut zu schreiben und hundert schlechte. Obwohl sie recht simpel sind, verstehen viele Produktentwickler sie falsch. Wir benutzen die Standardform: ‚Als Lehrer will ich einen Kurs erstellen, sodass ich Materialien mit meine Schülern austauschen kann.’ Jede User Story hat Prerequisites oder Voraussetzungen: ‚der Kurs existiert nicht’. Und wir haben Postrequisites oder Zielergebnisse: ‚der Kurs existiert’. Danach schreiben wir die User Story in Pseudocode. Dieser ist genauso aufgebaut, wie Programmier-Code. Der einzige Unterschied ist, dass man sich nicht an bestimmte Programmierkonventionen halten und deswegen nicht darauf achten muss ob der Code am Ende compiled werden kann. Eine gute User Story kann in Scrum-Planung eingeschätzt werden und darf nicht über 8 Story-Punkte lang sein. Wenn sie das Limit überschreitet, dann muss sie in zwei oder mehr Stories runtergebrochen werden. Die größte Story war bisher 5 Punkte groß, das heißt wir haben einen guten Job gemacht. Pro Zweiwochen Sprint schaffen wir rund 25 Punkte. So hat es bis jetzt immer gut geklappt, die Entwickler haben alle Sprints erfolgreich abgeschlossen. Darüber hinaus nehmen sie immer noch ‚technische’ Stories mit in den Sprint auf. Beim sogenannten Refactoring werden Teile des Codes neu geschrieben wenn dadurch die Performance der Seiten verbessert wird. Auch die Infrastruktur muss weiterentwickelt werden. Bei der Sprintplanung werden alle User-Stories auf Karteikarten geschrieben. Diese nehmen die Entwickler mit in ihr Büro und haften sie an unser Kaban-Brett, aufgeteilt in die Felder ‚offen’, ‚in Arbeit’, ‚erledigt’. Es ist schön zu sehen, wenn am Ende des Sprints alle Karten im letzten Feld hängen.