Habe gerade eben in der Online Version des Harvard Business Review von Ed Catmull, dem Mitgründer von Pixar neben Steve Jobs, einen tollen Artikel zum Thema Kollektive Kreativität gelesen. Das Fazit des Artikels “How Pixar Fosters Collective Creativity” ist alles andere als unerwartet: Für Pixar sind es nicht die guten Ideen, die sehr wertvoll sind, sondern einzig und alleine die guten Teams. Denn erst ein wirklich gutes Team bringt schliesslich auch genügend wirklich gute Ideen um daraus quasi Blockbuster vom Fliessband zu liefern – was Pixar ja bemerkenswerterweise seit dem Ersterfolg Toy Story tatsächlich nun immer wieder gelungen ist. Denn auch die darauf folgenden Filme A Bug’s Life, Toy Story 2, Monsters Inc, Finding Nemo, Cars und Ratatouille spielten allesamt Rekordergebnisse ein und erhielten fast durchwegs glänzende Kritiken.

Wieso ist der Artikel so spannend für den zimtblog? Nun, weil zwischen einem Team welches Filme produziert und einem Team welches Software produziert ja genau genommen kein wirklicher Unterschied besteht. In beiden Fällen ist das Zusammenstellen eines Teams, das Sicherstellen der richtigen Arbeitsumgebung sowie der Tools Voraussetzung dafür, dass gute Ideen immer noch besser gemacht und schliesslich daraus ein tolles Produkt resultiert.

So sehen User Stories aus. Und so wird aktuell gerade die komplette Spezifikation für die v2.0 von smaboo.de erstellt. Dies erlaubt eine sehr agile Vorgehensweise und mit der gewählten Projektmethodik “Scrum” ein beeindruckendes Mass an Gestaltungsfreiheit. Scrum ist die Antwort auf die Illusion, ein Web-Projekt von Anfang an sauber und stringend spezifizieren zu können. Der wohl grösste Vorteil von Scrum ist die Einfachheit, die wenigen aber sehr klaren Regeln und Verantwortlichkeiten. Vereinfach gesagt funktioniert der Prozess wie folgt: Benutzer schreiben aus ihrer Sicht, was sie mit der Plattform machen können. Der Scrum Master ordnet diese Anforderungen in Form von User Stories, splittet auf oder ergänzt, weist diese dann Iterationen zu (in Scrum werden diese “Sprints” genannt) und Entwickler setzen die User Stories schliesslich um. Ein frappanter Vorteil von Stories: Fokus und Detailgrad kann sich im Verlauf des Projekts verändern. So werden am Anfang typischerweise sogenannte “Epic Stories” erfasst, d.h. die Bedienungsmuster als grosses Ganzes. Im Verlaufe der Sprints können dann die Stories immer weiter herunter gebrochen und an die im Projektverlauf gemachten Erfahrungen angepasst werden.

Der Aufbau einer Story ist dabei sehr einfach gehalten:
As a <type of user> I want to<specific goal> so that <specific reason/business value>

Ebenso einfach definiert sind die typischen Inhalte einer User Story:

• Karte: Hier wird die eigentliche Spezifikation mit Verhaltensmustern und erwarteten Ergebnissen definiert.
• Diskussion: Dies ist das Gefäss für Diskussionen zu den einzelnen Details und Fragen.
• Tests: Hier werden die Akzeptanzkriterien definiert, d.h. wann eine Story korrekt erfüllt ist und wann nicht.

In der Heimatsprache der Methodik klingt dieser Dreiklang natürlich sehr viel schöner: Card, Conversation, Confirmation.

Wer noch etwas mehr zum Thema Scrum und User Stories erfahren möchte, dem seien die folgenden Ressourcen ans Herz gelegt:
- Artikel Advantages of the “As a user, I want” user story template.
- Powerpoint Slides von Mike Cohn “Effective User Stories for Agile Requirements”