Das CCC-Modell Für User Stories

Wenn man die Anforderungen eines Kunden zufriedenstellend erfüllen möchte, muss man schon mal tief in den Zauberhut greifen. Ein Modell, das helfen soll bessere User-Stories zu schreiben und dem Ziel damit näher zu kommen, ist das CCC-Modell.

Eine User-Story drückt eine Anforderung an ein Produkt in einem einfachen, hoffentlich kurzen aber dennoch informationsgeladenen Satz aus. Letztlich soll sie helfen, dass der Kunde bekommt, was er braucht.

Wie das geht?

Dabei hilft das “Card, Conversation, Confirmation”- oder kurz CCC-Modell.

Card

Die beste Art eine User Story darzustellen ist auf einer nicht zu großen Index-Karte.

Denn so wird die User Story zu einem Token, das die eigentliche Anforderung repräsentiert. Etwas das man anfassen, rumreichen oder an ein Board hängen kann.

Diese Form ermöglicht es, dass alle Beteiligten an die Anforderung erinnert werden. Vor allem zwingt das Format zur notwendigen Kürze einer User Story. Deshalb hilft zumindest die Vorstellung von der User Story als eine Index-Karte auch, wenn vielleicht doch ein elektronisches Hilfsmittel verwendet wird.

Conversation

Eine gute User Story ermöglicht Konversation zwischen den Beteiligten.

Ob nun in Scrum oder Xtreme Programming: bei agilen Methoden geht es immer um Kommunikation. Bei User Stories geht es darum, Kommunikation zwischen den Stakeholdern und den Umsetzern zu ermöglichen – nicht diese zu ersetzen.

Idealerweise geschieht dieser Gedanken- und Meinungsaustausch im Face-to-Face-Gespräch, kann aber auch durch Dokumente ergänzt (und festgehalten!) werden.

Confirmation

Nichts stellt zuverlässiger sicher, dass eine Anforderung zufriedenstellend umgesetzt wird, als die mit der Story verbundenen Erwartungen zu klären und zu verschriftlichen.

Eine User Story sollte deshalb um Abnahme- oder auch Akzeptanzkriterien aus Sicht des Kunden versehen sein oder im Gespräch um diese erweitert werden. Praktischerweise bietet die User Story in Form einer Index-Karte auch gleich eine Rückseite, auf der diese festgehalten werden können. 😉

Für die Kriterien gilt, dass sie überprüfbar sind, also konkrete, durchführbare Akzeptanztests beschreiben. Bei IT-Projekten bietet es sich dabei an, wenn diese sich letztlich auch automatisieren lassen.

Akzeptanzkriterien müssen keinesfalls alle Tests umfassen, damit eine Story als fertig gelten kann. Im Allgemeinen werden sie durch allgemeine Fertigstellungskriterien flankiert, etwa die Definition of Done des Teams.