tekom-Jahrestagung 2012 - ActiveDoc

User Assistance
Gute User Stories
schreiben
etwa „auf Graf_008erg noch print_graf3 einbinden“. Doch nicht immer
werden solche Anforderungen sofort umgesetzt, die Software entwickelt
sich mit jedem Sprint weiter und nach ein paar Wochen weiß keiner
mehr, was mit solch einer kryptischen Notiz gemeint war.
Um dem vorzubeugen, helfen einfache Eselsbrücken. Im ersten Schritt
wendet man das Formulierungsmuster [MC] an: Als [wer] möchte ich
[welche Funktion] damit ich [warum]? Die drei „Ws“ sind einfach zu
ersetzen. Die genaue Form ist dabei nicht entscheidend, wichtig ist, dass
die Informationen enthalten sind. Etwas detaillierter sind die INVEST-
Kriterien für Anforderungen [BW]:
––
I – Independent: Ist es eine in sich geschlossene und von anderen
Anforderungen unabhängige Anforderung?
––
N – Negotiable: Weiß ich als Entwickler, was der Nutzer braucht, und
kann somit verschiedene Lösungen für die technische Umsetzung
verhandeln?
––
V – Valuable: Ist diese Funktion wirklich wichtig? Hat sie einen Geschäftswert?
––
E – Estimatable: Kann ich für diese Anforderung abschätzen, wie lange
ich brauche? Liegt die Zeitschätzung unter 2 Tagen?
––
S – Small: Ist es wirklich das kleinstmögliche Inkrement oder kann
ich die Anforderung in mehrere Inkremente aufbrechen?
––
T – Testable: Kann ich die Umsetzung der Anforderung testen? Welche
Angaben fehlen mir, damit ich weiß, was ich testen muss?
Abb. 2: INVEST-Kriterien auf User Story anwenden
Vom Bierdeckel
zum Handbuch
Doch warum sind die User Stories, die die Entwickler nutzen, nun für
Technische Redakteure interessant? Vor allem, weil sich die User Stories
fast allein zu einem aufgabenbasierten Handbuch zusammenfügen.
Es ist sofort klar, in welches Handbuch die neu programmierte Funktion
gehört, in unserem Beispiel ins Handbuch für Labor-Mitarbeiter. Auch
die Tätigkeit, das Ausdrucken, steht schon direkt in der User Story und
522
tekom-Jahrestagung 2012