Verwaltung macht Zukunft

Als ... möchte ich ..., um ...! Oder: Welchen Zweck haben eigentlich Userstories?

16:56 12.01.2018

Auf den ersten Blick klingt sie wenig hilfreich, ja sogar künstlich, die Satzformel zur Beschreibung von Userstories: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“. Wieso sollte ich mich so einem Formalismus unterwerfen? Wie sollte ich die vielfältigen Wünsche der Kunden in immer wieder gleiche Formulierungen verpacken? Als ich zu Beginn meiner Arbeit als Productowner bei MACH vor etwa 2,5 Jahren zum ersten Mal mit dieser Satzformel in Kontakt kam, waren genau das die ersten Gedanken, die mich den Kopf schütteln ließen. Dennoch habe ich mich darauf eingelassen und es „einfach mal versucht“ (Wenn es dem Team nicht hilft, kann ich es ja auch wieder sein lassen.). Aber immerhin gab es in der Welt „da draußen“ eine Menge Leute, die das so hilfreich finden, dass es sogar in der Wikipedia steht.

Userstories bei MACH

Zwei Jahre später. Ich habe viel gelernt und noch mehr Erfahrungen gemacht. Und ich denke vollkommen anders über diese Satzformel, weiß diesen scheinbar engen Formalismus sehr zu schätzen. Woher dieser Schwenk? Die Antwort ist kurz: Weil es hilft! Sehr hilft! Weil es mir selbst zu großer Klarheit verhilft, was ich mit einem Entwicklungsvorhaben eigentlich erreichen will. Und weil ich dem Team besser erklären kann, worum es geht. Kein "Mach mal da unten rechts eine grüne Schaltfläche, die ... tut!", sondern "Der Benutzer benötigt ..., weil er sonst eine ganze Menge Mehrarbeit hat. Dafür suchen wir nun (gemeinsam) die beste Lösung."

Schaut man genauer hin, beantworten sich bei der Arbeit mit dieser Satzformel drei wesentliche, nein die wesentlichen drei Fragen:

  • Zunächst ist da die Frage „Wer spricht?“ – wer also ist <Rolle>, wem muss unsere Lösung helfen? Einem technisch versierten Administrator kann ich andere Oberflächen und Funktionen „zumuten“ als dem Sachbearbeiter, der in seiner Abteilung Fachexperte ist und für den der Computer nur als Arbeitswerkzeug dient. Vielleicht mag der Admin ja die Kommandozeile sogar viel lieber als das ständige Maus-Geklickere...
  • Dann wenden wir uns dem "Was will der Benutzer tun?" zu: Hier tauchen wir in die Fachlichkeit ein - und wohlgemerkt nicht in "unten rechts auf eine Schaltfläche klicken." Hier verstehe erst ich und später das gesamte Team den Arbeitskontext und die Aufgaben des Benutzers.
  • Die letzte Frage: „Was ist das Ziel der Person?“ Hier geht es um das eigentliche Ziel des Entwicklungsvorhabens, also den Nutzen für den Benutzer. „Ich benötige Überblick und möchte daher in einer Liste möglichst viele Objekte mit wenig Detailinformationen sehen.“ Auch hier sind wir mitten in der Fachlichkeit des Benutzers angekommen und sprechen nur sehr wenig über die konkrete Softwarelösung. Und das ist so wertvoll! Wir müssen verstehen, was der Benutzer wozu tun möchte.

Mit der Zeit sind bei mir ähnliche Satzmuster hinzu gekommen und ich verwende sie je nach Bedarf, z. B. „Als <Rolle> erwarte ich <irgendwas>, weil es <einen Grund gibt>.

Manchmal helfen mir die Satzformeln auch beim „Nein-Sagen“: Mein Scrumteam erzeugt nicht nur jeden Tag neue Software, es produziert auch immer wieder Ideen, bei denen es uns allen in den Fingern juckt, sie sofort umzusetzen. „Hier könnte ich noch … einbauen.“ Dummerweise würde die Umsetzung manches Mal nicht nur zwei Minuten brauchen, sondern eher zwei Tage. Ich schaue dann nach „ganz oben“ in der Spezifikation, lese kurz und antworte vielleicht: „Gute Idee, werden wir vielleicht später verfolgen, aber deine Idee erfüllt jetzt nicht das primäre Ziel des Benutzers. Ich werde das demnächst mal mit dem Kunden diskutieren."

Ich weiß, dass nicht alle Productowner bezüglich der Satzformeln so denken. Mag sein, dass es Typsache ist. Ich zumindest möchte diese Formel nicht mehr missen.

Jan-Hendrik Krause

Jan-Hendrik Krause

Bei MACH bin ich schon seit über 18 Jahren. Seit Mitte 2015 Jahren arbeite ich als Product Owner für unsere E-Akten-Lösung MACH E-Verwaltung.

An meiner Arbeit als Product Owner gefallen mir die vielfältigen Möglichkeiten, sowohl die Software als auch das Unternehmen zu gestalten.

Besonders spannend finde ich, wenn im iterativen Scrum-Prozess aus einer ersten Formulierung "Als ... möchte ich ..., um das Ziel ... zu erreichen" über viele Stufen des Gesprächs mit unterschiedlichen Personengruppen hinweg eine Lösung entsteht, über die mir der Kunde in der Videokonferenz "Das ist gut!" bestätigt.

Zurück

Einen Kommentar schreiben

Diese Website verwendet Cookies. weiterlesen