Was macht eine gute User Story aus? Ganz klar, sie müssen dem INVEST-Schema entsprechen. Das ist doch ein alter Hut! Und was macht man, wenn eine User Story zu groß ist? Kinderkram! Man nimmt einfach eines der Cheat Sheets aus dem Internet, und splittet sie nach den vorgeschlagenen Verfahren! Oder ist es vielleicht doch nicht ganz so einfach?
User Stories gehören zum Kernbestand Agiler Methoden und gelten inzwischen als gut verstanden. Aber was eine gute User Story ausmacht hängt sehr viel stärker von den verfolgten Zielen und dem Kontext ab, als es zunächst klingt. Wir zeigen, wie unterschiedlich gute User Stories aussehen, und welche Fragen Sie sich stellen müssen, bevor Sie das nächste Cheat Sheet zur Hand nehmen.a
Beispiele für die Wichtigkeit der Ziele und des Kontextes:
Unterschiedliche User Stories nach Frontend und Backend aufzusplitten, gilt als sehr schlechte Idee. Tatsächlich kann es aber eine sehr gute Idee sein! Wenn es uns z.B. darum geht, sehr schnell etwas über Usability unserer Software zu lernen, dann ist eine User Story dieser Art vielleicht sehr sinnvoll: “Als Geschäftsführer möchte ich eine klickbare Dummy-Oberfläche haben, damit ich erfahre ob unsere Kunden das neue UI-Konzept verstehen.”
Der User ist dann nicht der Endanwender, und wir erhalten bei erfolgreicher Umsetzung der Story kein nutzbares Feature - trotzdem eine super Story!
Wenn aber in einem anderen Kontext die Planbarkeit im Vordergrund steht, nicht wie eben das Lernen, dann sollten User Stories im Allgemeinen immer Durchstiche durch alle Layer enthalten. Kontext und verfolgtes Ziel beeinflussen hier also maßgeblich was eine “gute” User Story ist.
Dr. Arne Roock arbeitet bei Jimdo in Hamburg, wo er sich insbesondere mit Organisationsentwicklung und Team-Coaching beschäftigt. Davor hat er in seiner Karriere als Trainer und Berater für Lean und Agile mit unterschiedlichen Organisationen gearbeitet – von kleinen Startups über Mittelständler bis hin zu großen internationalen Konzernen.
Zudem ist Arne Roock regelmäßig als Sprecher auf Konferenzen vertreten und hat bereits zahlreiche Fachartikel zu agiler Softwareentwicklung verfasst. Er ist Gründer der ersten Kanban-User-Group in Deutschland (limited-wip-society-hamburg.mixxt.de) und betreibt den Blog www.software-kanban.de.
Sebastian Eichner unterstützt Jimdo seit 2012 in der Softwareentwicklung. Sein Schwerpunkt liegt dabei auf Entwicklungsprozessen, Retrospektiven und Expressive Code.
Davor hat er hauptsächlich mit verschiedenen Hamburger Startups gearbeitet, und deren Wachstum von Wohnzimmergröße auf mehrere Stockwerke begleitet.