Innovation Games® – bessere Produkte spielerisch entwickeln

Im Rahmen des letzten Treffens der Agile Usergroup Rhein-Main präsentierte uns Michael Tarnowski von plays-in-business die 13 von Luke Hohmann entwickelten sogenannten Innovation Games®.
Es handelt sich dabei um einen Set von „Spielen“ (mal mehr, mal weniger spielerisch angehaucht), die genutzt werden können, um gemeinsam mit Kunden, Anwendern oder auch dem Team Ideen für ein Produkt oder einen Service zu generieren. Der Fokus der Spiele ist jeweils unterschiedlich, von Spielen für die Priorisierung von Features bis hin zur Entwicklung von neuen Feature-Ideen reicht das Spektrum.

Im ersten Schritt gab uns Michael einige Hintergrundinformationen zu den Innovation Games®:

Gegeben der beschränkten Zeit haben wir uns aus den 13 Games per Dot-Voting die interessantesten für die Teilnehmer herausgesucht und dann in vier Gruppen jeweils eines durchgespielt. Zwei davon möchte ich an dieser Stelle einmal kurz vorstellen.

Give them a hot tub

Give them a hot tub

In der Gruppe, der ich angehörte, haben wir uns mit „Give them a hot tub“ beschäftigt. Dabei geht es darum, in eine Liste mit Features, die sehr vernünftig erscheint, auch solche zu integrieren, die abwegig erscheinen. Das soll die Teilnehmer nach einem ersten Moment der Überraschung dazu bringen, darüber nachzudenken, ob an der abwegigen Option nicht doch etwas dran ist.
Als Basisprodukt hatten wir einen Einkaufswagen, den wir nach und nach um abwegigere Features erweiterten. Es ist uns dabei aufgefallen, dass es gar nicht so einfach war, auf wirklich abwegige Features zu kommen. Wir hatten viele Ideen, die sich rund um den Antrieb drehen, also etwa eine Motorisierung des Einkaufswagens. Dann überlegten wir uns z.B., dass der Einkaufswagen auch durch Solarzellen mit Strom für den Antrieb versorgt werden könnte. Auch ein paar Ideen in Richtung Aufprallschutz sind uns gekommen, wie ein Kuhfänger oder ein Airbag, die sicherlich auch in der Realität hilfreich sein könnten. 😉 Deutlich abwegiger wurde dann unsere „Ich spioniere den Wagen der anderen Leute aus und greife dann Ware, die ich auch haben möchte, aus deren Einkaufswagen ab“-Funktion.
Mit dieser Vorarbeit könnten wir nun eine Feature-Liste für einen Einkaufswagen erstellen, in der ein paar realistische und auch einige abwegige Features enthalten wären, die die Teilnehmer des eigentlichen Workshops dann bei einer Konfrontation mit der Liste zum Nachdenken anregen würden.

My worst nightmare

My worst nightmare

Ein weiteres Spiel, dass an dem Abend in einer Gruppe angewendet wurde, war „My worst nightmare„. Das Team entschied sich, als Thema „Häusle bauen“ zu nehmen, also ihren schlimmsten Alptraum in Verbindung mit einem Hausbau zu schildern. Es kam eine ganze Reihe von Anregungen zustande, die auf einem Flipchart-Papier visualisiert wurden. Zu nennen ist etwa, wenn der Bauträger komplett falsch versteht, was man eigentlich haben wollte, und das Haus später „auf dem Dach steht“. Auch vollkommen überzogene Baukosten oder extrem verlängerte Bauzeiten sind verständliche Sorgen, denen sich z.B. manche Fertighaus-Anbieter mit Fixpreisen stellen wollen. Aber auch die Behörden können Bauprojekte beschwerlich machen. Einige weitere Punkte sind noch zusammengekommen und am Ende waren sich alle einig, dass der eigentliche „worst nightmare“ wäre, wenn das alles auf einmal eintritt.
Es ist an dem Beispiel deutlich geworden, dass „My worst nightmare“ für die Vermarktung eines Produktes sehr hilfreich sein kann. Wenn die Sorgen und Ängste potentieller und bestehender Kunden bekannt sind, kann darauf gezielt eingegangen werden. Dies kann der Start einer besonders guten Kundenbeziehung werden, wenn der Kunde das Gefühl hat, vom Dienstleister gut verstanden und ernstgenommen zu werden.

Dies waren zwei der vier Spiele, die wir an dem Abend ausprobiert haben. Das Feedback der Teilnehmer war sehr positiv und wir freuen uns auf eine Fortsetzung zur Erprobung der weiteren Innovation Games.

Weitere Informationen gibt es auch im Blog-Beitrag von Michael zu Innovation Games.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Werbeanzeigen

Produktentwicklung auf die schlanke Art

Wie viele von den Funktionalitäten, die wir in Software einbauen, bringt unseren Anwendern wirklich einen Nutzen? Zu häufig wird diese Frage gar nicht gestellt. Woran liegt das?
Häufig scheint die Überzeugung zu sein, das viel auch viel hilft. Eine endlose Feature-Liste erscheint attraktiv. Genauer betrachtet stellen Features, die den Anwendern keinen echten Mehrwert liefern, eher einen Kostenpunkt dar. Sie müssen gewartet werden und erhöhen die Komplexität einer Software-Anwendung sowohl für die Anwender, als auch die Betreiber.

Der überzeugte Lean Startup-Anwender und Buchautor Ash Maurya berichtet in einem Blogpost darüber, wie er selbst vorgeht, um nur Features in seiner Software bereitzustellen, die auch wirklich einen Nutzen für einen Großteil der Anwender erzielen.

Sein „Framework“ hierfür besteht aus mehreren Elementen. Zu jeder Zeit wählt er einen zentralen Zielwert, der angestrebt werden soll. Beispielsweise die Quote von Neu-Anwendern, die für eine dauerhafte Nutzung der Software aktiviert werden kann. Zu jeder Zeit gibt es nur eine zentrale Zielsetzung, die mit den Feature-Entwicklungsbemühungen erreicht werden soll.

Auf dem Weg von Entwicklung bis dauerhafter Aufnahme einer Funktionalität in den Produktumfang durchläuft sie vier zentrale Schritte.
Die erste Stufe beginnt mit der Priorisierung des Backlogs. Da es einen zentralen Zielwert gibt, kann die Priorisierung nach dem Beitrag für diesen Zielwert, im Verhältnis zu den für die Realisierung anfallenden Kosten, erstellt werden.
Wenn die Priorisierung geklärt ist, wird als nächstes das Top-Item genommen und durch Kunden-Interviews abgeklärt, wo genau das dahinter liegende Problem liegt. Es geht an dieser Stelle nicht darum, was die Kunden wünschen. Vielmehr geht es darum, warum sie etwas wünschen. Ausgehend von den Rückmeldungen der Kunden wird dann entschieden, ob etwas gemacht wird oder der Feature-Wunsch verworfen wird.

In der zweiten Stufe wird dann entschieden, wie das Feature umgesetzt werden soll. Es werfen hierfür erste Screens gestaltet und dann mit den Kunden, die auch interviewed wurden, dazu befragt. Es werden dann üblicherweise mehrere Iterationen durchlaufen, bevor eine Umsetzung angedacht wird.

Die Funktionalität wird dann in einem Continous Deployment-Prozess realisiert. Mit Hilfe eines Feature Flipper Systems kann dafür gesorgt werden, dass die Features auf das Live-System eingespielt werden, ohne dass sie den Anwendern zugänglich sind, bis sie fertig sind. Nach Fertigstellung wird die Funktionalität einer selektierten Kundengruppe zur Verfügung gestellt und von denen ein qualitatives Feedback eingeholt. Wenn dabei Fehler auftreten oder das Feedback negativ ausfällt, können noch vor einem größeren Roll-out Korrekturen vorgenommen werden.

Es folgt die vierte Stufe, wenn das qualitative Feedback zufriedenstellend war bzw. Nachbesserungen erfolgt sind. Die Funktionalität wird allen Anwendern zur Verfügung gestellt und quantitative Metriken gesammelt. Während die Messungen laufen, wird mit der Arbeit an der nächsten Funktionalität gestartet, denn meist dauert die Erhebung der metriken etwas. Dann folgt eine Auswertung der Zahlen.
Die Kombination von qualitativem Feedback und quantitativen Metriken sorgt für eine gute Entscheidungsgrundlage. Nur, wenn die Funktionalität sich als förderlich für den zentralen Zielwert herausstellt, wird es dauerhaft in der Anwendung belassen. Ansonsten fliegt es konsequent raus.

Die folgende Präsentation stellt das Vorgehen von Ash Maurya dar:

How We Build Features

View more presentations from ashmaurya

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Tipps zur Priorisierung des Product Backlogs von Mike Cohn

Product Backlog PriorisierungEine echte Perle zum Thema Priorisierung des Product Backlogs habe ich kürzlich bei Axel Heinz gefunden. Es handelt sich dabei um einen Vortrag von Mike Cohn (ich habe hier schon über sein Buch „User Stories Applied“ geschrieben). In diesem Vortrag stellt er nach einer Einführung in das Thema und dessen Bedeutung die vier Ansätze für die Priorisierung des Backlogs vor: Kano-Analyse, Theme-Screening, Theme-Scoring und relative Gewichtung.

Die Bedeutung guter Backlog-Pflege

Mike Cohn betont zunächst noch einmal die Bedeutung der Pflege des Backlogs. Er konnte in der Praxis zahlreiche Teams beobachten und die richtig guten Teams zeichneten sich alle dadurch aus, dass sie rund 10% ihrer Zeit in die Pflege des Product Backlogs stecken und diesen aktiv pflegen.
Das Stichwort lautet hier Backlog Grooming und kann zum Beispiel in Form von Workshops mit dem ganzen Team erfolgen.
Mike Cohn betont, dass es für Entscheidungen in der Backlog Priorisierung immer eine solide Grundlage geben sollte, wie etwa die Ergebnisse von Umfragen, aus Statistiken oder ähnliches. Statistisch signifikant braucht es für ihn nicht zu sein, aber z.B. das Feedback von 20-30 Anwendern im Rahmen einer Umfrage kann schon viel aussagen.
Nun aber zu den vier Maßnahmen, die er im folgenden vorstellt.

Kano-Analyse

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten in verschiedene Kategorien möglich ist:

  • Basisfaktoren: Basisfaktoren werden von den Anwendern als selbstverständlich vorausgesetzt. Werden sie erfüllt, entsteht keine Zufriedenheit, bei Nichterfüllung entsteht jedoch Unzufriedenheit.
  • Leistungsfaktoren: Diese wirken linear und ein mehr von dieser Funktionalität führt zu mehr Zufriedenheit der Anwender.
  • Begeisterungsfaktoren: Begeisterungsfaktoren werden vom Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, den seine Frau spitze fand, der 1993 noch keineswegs selbstverständlich war. So etwas kann sogar das „Zünglein an der Waage“ für eine Kaufentscheidung sein.

Manchmal ist es gerechtfertigt, darüber Schätzungen abzugeben, in welche Kategorie eine Funktionalität fällt. Noch sinnvoller ist meist jedoch die Befragung einer kleinen Gruppe von Anwendern, etwa 20-30 Stück.
Als Tipp für die Einplanung in das Produkt schlägt er vor, dass alle Basisfaktoren integriert werden, da sonst mit Unzufriedenheit gerechnet werden muss. Darüber hinaus sollten einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren eingeplant werden.

Weitere Informationsquellen für das Kano-Modell:

Theme-Screening

Das Vorgehen beim Theme-Screening erfolgt mit den folgenden Schritten:

  1. Identifiziere als erstes die Faktoren, die für die Priorisierung als Kriterien für das nächste Release herangezogen werden sollen. Zum Beispiel die Bedeutung für die bestehenden Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa 5-9 Kriterien sein.
  2. Nach der Festlegung der Priorisierungskriterien wird ein „baseline theme“ gewählt. Eine Story oder ein Theme, die im weiteren Vergleich als Basis für die relative Bewertung genutzt wird. Dafür eignen sich solche, die wahrscheinlich in das nächste Release aufgenommen werden und das allen Teammitgliedern vertraut und verständlich ist. Es sollte aber nicht das wichtigste Theme sein, da in diesem Fall alle weiteren Themes im Verhältnis schlechter abschneiden würden. Das gilt also analog zu Referenz-Stories beim relativen Beschätzen des Product Backlogs, wo meist eine mittelgroße oder eine eher kleinere Story als Vergleich genutzt wird.
  3. Alle Themes oder Stories, die zur Auswahl stehen, werden nun im Vergleich zum „baseline theme“ nach allen Kriterien bewertet. Für die schlechter abschneidenden Themes wird jeweils ein – eingetragen, für die besser abschneidenden ein + und für die gleich zu bewertenden Themes eine Null.

Mike Cohn stellt auf seiner Website sogar ein kleines Tool zum Theme-Screening bereit, das auch schnell das Vorgehen beim Theme-Screening verdeutlicht.

Weitere Informationsquellen für das Theme-Screening:

Theme-Scoring

Theme-Scoring ist dem Theme-Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Als erstes werden auch hier die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie einen Prozentwert, der sich zu 100% aufsummiert.

Als nächstes werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes bewertet auf einer Skala von 1-5, wobei 1 für eine schlechte Erfüllung des Kriteriums und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, als erstes für alle Kriterien ein Basis-Theme festzulegen, dass eine Bewertung von 3 erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.

Mike Cohn stellt auf seiner Website auch ein kleines Tool zum Theme-Scoring bereit.

relative Gewichtung

Die relative Gewichtung („relative weighting“) ist ein Priorisierungsansatz, bei dem sowohl die positive Auswirkung der Präsenz eines Features als auch die negative Auswirkung der Abwesenheit eines Features in die Beurteilung einbezogen wird. Für jede Funktionalität wird eine bewertung von 0 (gering) bis 9 (hoch) vorgenommen.

Die Themes werden dabei in die Reihen einer Tabelle eingetragen. Dann wird jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und der Strafe bei Abwesenheit hinterlegt. Zusätzlich wird noch ein Wert für den geschätzten Aufwand, etwa in Story Points oder auch einem Euro-Betrag, hinterlegt. Es werden also in diesem Fall die Kosten einer Funktionalität explizit mit berücksichtigt.
Es wird dann geschaut, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden durcheinander geteilt und es ergibt sich eine Priorisierungskennzahl.

Anteil am Gesamtnutzen Anteil an den Gesamtkosten Priorisierung
57% 67% 0.85
43% 33% 1.30

Das als zweites in diesem Fall aufgeführte Feature bringt zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger. Dadurch ist der Return on Investment (ROI) von letzterem größer.

Auf der Website Mike Cohn gibt es auch zur relativen Gewichtung ein kleines Tool.

Links zum Vortrag von Mike Cohn

Der Vortrag von Mike Cohn
Folien von Mike Cohn (PDF)

An dieser Stelle möchte ich auch noch auf eine Excel-Vorlage für die Product Backlog Priorisierung von Michael Romer hinweisen.

Foto: peterstev
——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Englische Version des Artikels

Wie schreibe ich eine User Story?

User Stories scheinen sich zu einer „State of the art“-Methode zur Formulierung von Anforderungen entwickelt zu haben. Kaum ein Buch über agile Softwareentwicklung, dass nicht auf diese Form der Beschreibung von Anforderungen verweist. Aber: Wie schreibt man eigentlich eine User Story?
Erst einmal zur Beruhigung: User Stories schreiben ist wie Fahrad fahren! Am Anfang ist es ungewohnt und fühlt sich seltsam an. Nach ein paar Versuchen läuft es dann aber wie von alleine und man verlernt es nie!

Nach über einem Jahr der Arbeit mit User Stories kann ich mir kaum noch vorstellen, wie ich mit meinen Teams vorher Anforderungen formuliert habe.

Grundsatz: Formulierung aus Sicht des Nutzers

Ein wichtiger Grundsatz bei User Stories ist, dass sie aus der Sicht eines Anwenders geschrieben werden. Daher werden sie auch frei von technischem Schnickschnack gehalten. Jeder, der am Projekt beteiligt ist, also auch jeder Anwender, sollte sie optimalerweise verstehen können. Hingegen sollte das Entwicklungsteam tolerant gegenüber der Fachsprache der Anwender sein.

3 Bestandteile einer User Story

Eine User Story setzt sich mindestens aus den folgenden drei Elementen zusammen:

  • Einem kurzen, prägnanten Namen.
  • Einer kurzen Beschreibung der Anforderung.
  • Mehreren Akzeptanzkriterien, die die Details ausdrücken und dokumentieren und bei der Klärung helfen, ob eine Story wirklich abgeschlossen ist.

Nach wie vor hilft diese einfache Satzkonstruktion beim Einstieg in das Schreiben einer User Story:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Schauen wir uns die drei Teile dieses Satzes noch einmal etwas genauer an.

Name

Eine kurze, prägnante Benennung, die sich die Teammitglieder und die anderen Beteiligten gut merken können. Am besten ist sie so, dass jeder etwas damit anfangen kann, wenn jemand sagt „Wir sollten noch xy umsetzen“. Wir die Anmeldung an einem System kann also die Bezeichnung „Anmeldung“ ausreichend sein, wenn das Team versteht, was damit gemeint ist.

Beschreibung

Wer möchte eigentlich etwas?

Es ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp „Benutzer“. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie „als Benutzer mit einem Twitter-Account“. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.
Wenn das Team mit Personas arbeitet, kann es sinnvoll sein, die bestimmte Persona zu nennen, die im besonderen diese Anforderung hegt.

Warum will er das tun, welchen Nutzen will er erzielen?

An dieser Stelle steht der zu Grunde liegende Nutzen, der erreicht werden soll. Die Idee ist dabei, dass die anschließend beschriebene Funktionalität aus dem Nutzenstreben abgeleitet sein muss. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht diese nur, um die Kernfunktionen der Software anschließend nutzen zu können.

Durch welche Funktionalität will er den Nutzen realisieren?

In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll.

Insgesamt könnte die Beschreibung einer User Story damit wie folgt aussehen:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten anmelden).

User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen. Dies hängt auch damit zusammen, wie nah oder weit die Umsetzung der Anforderung ist. Es kann sein, dass die Lösung der User Story noch weitgehend offen gehalten werden soll, oder aber es ist schon eine Entscheidung für eine konkretere Umsetzungsvariante gefallen. Wurde etwa bereits festgelegt, dass in unserer Beispiel-Story die Anmeldung per Twitter-Zugangsdaten mit Hilfe des Protokolls OAuth erfolgen soll, könnte die User Story wie folgt konkretisiert werden:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten über das sichere Authorisierungsprotokol OAuth anmelden).

Akzeptanzkriterien

Wie kann festgestellt werden, ob die User Story entsprechend den Anforderungen umgesetzt wurde? Die Akzeptanzkriterien spielen dabei eine besondere Rolle. Sie beantworten die Frage, was getestet werden soll. Eine gute Hilfsregel für die Formulierung von Akzeptanzkriterien ist, dass sie mit „Teste…“ anfangen sollten. Beispiele für unsere obige Story könnten sein:

  • Teste die Eingabe eines ungültigen Benutzernamens…
  • Teste die Eingabe eines ungültigen Passworts
  • Teste die Eingabe eines gültigen Benutzernamens und eines gültigen Passworts

Wie stelle ich sicher, dass das Team die User Stories versteht?

Zunächst kann eine gewisse Unsicherheit vorhanden sein, ob das Entwicklungsteam die User Stories in der Form akzeptiert. Hier ist es aber wie mit vielen anderen Dingen in der agilen Softwareentwicklung. Es gehört Mut dazu, Dinge auszuprobieren und sich einzugestehen, dass am Anfang nicht alles rund läuft. Inspect and adapt. Nach ein paar Wochen der Arbeit mit User Stories haben dann alle Beteiligten eine gemeinsame Vorstellung davon entwickelt, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Das funktioniert am besten, wenn darüber hinaus regelmäßige Backlog Grooming-Sitzungen durchgeführt werden, in denen mit dem Entwicklungsteam und Anwendern zusammen an den Stories gearbeitet wird.

Ergänzende Beschreibungen, Mock-ups, Wireframes,…

Ergänzt werden können diese drei Grundelemente einer User Story durch weitere Informationen, die dem Entwicklungsteam dabei helfen zu verstehen, wie die Umsetzung erfolgen soll. Das können ergänzende Beschreibungen, Mock-ups, Wireframes, Scribbles … you name it … sein. Das wichtigste ist, dass diese das gemeinsame Verständnis der Anforderung unterstützen. Sie sollten aber niemals die persönliche Kommunikation zwischen den Beteiligten ersetzen!

Weiterführende Informationen:

Foto: kmlz

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

%d Bloggern gefällt das: