Noch bis morgen einreichen: Call for Sessions der Tools4AgileTeams

Am 8. November möchten wir gemeinsam mit Euch eine Konferenz in Wiesbaden speziell zur Nutzung und Anwendung von Tools in der agilen Softwareentwicklung veranstalten.
An welchen Stellen ist die Anwendung von Tools wirklich hilfreich, an welchen Stellen eher ein „Impediment“? Und welches Tool eignet sich besonders gut für einen spezifischen Einsatzzweck?
Wir möchten Anwender, ScrumMaster, Manager, Tool-Hersteller und alle, die sich für das Thema interessieren, an diesem Tag zusammenbringen. Am Vormittag wird es 8 Vorträge geben, für die wir derzeit noch bis zum kommenden Freitag, 31.8., Einreichungen entgegen nehmen.
Am Nachmittag möchten wir dann Open Space mit mehreren parallelen Slots machen, um möglichst spezifisch auf alle brennenden Fragen an diesem intensiven und hoffentlich lehrreichen Tag eingehen zu können.

Weitere Informationen zur Einreichung von Sessions findet Ihr hier:
http://tools4agileteams.com/display/2012/Call+for+Sessions

Tickets für die Veranstaltung sind derzeit noch bis Ende September zum Earlybird-Preis von 199 Euro zu erwerben:
http://tools4agileteams.com/display/2012/Anmeldung+und+Preise

——–
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.

Produktmanagement Lesetipps: Product Owner-Rolle, Kunden- und Anwenderbefragungen, Bereitschaft zu Fehlern, Pretotyping

Nach längerer Pause gibt es wieder einige Leseempfehlungen aus meinem RSS-Reader zu verschiedenen Themen, die für Produktmanager von Bedeutung sind.

Die Rolle des Product Owners

Roman Pichler stellt zwei typische Varianten gegenüber, wie die Product Owner-Rolle besetzt wird: Die Besetzung durch den Kunden selbst sowie eine Besetzung mit einem Proxy. Er schlägt aber auch vor, bei einem größeren Projektportfolio die beiden Varianten zu nutzen, je nachdem, ob nur für einen Kunden oder für eine Vielzahl von Kunden entwickelt wird: „Two common ways to apply the product owner role„.

Hilfreiche Tipps für Kunden- und Anwenderbefragungen

Egal ob Customer Development, Lean Startup oder agile Softwareentwicklung – sie alle empfehlen die aktive Einbeziehung von Kunden und Anwendern. Ein Mittel hierfür ist die Durchführung von Kunden- und Anwenderbefragungen. Zur Durchführung solcher Befragungen gibt es hier zahlreiche Tipps von einem erfahrenen Produktmanager: „How do I set up customer interviews?

Keine Angst vor Fehlern

Im hervorragenden Blog von HackFwd, dem Pre-Seed Investor von Lars Hinrichs, wird die Bedeutung des Scheiterns und des Fehler machen betont. Für die Realisierung von neuen Produkten ist es wichtig, die Bereitschaft aufzubringen, Fehler zu machen und aus ihnen zu lernen: „Fail better„.

Minimale Feedbackschleifen – Pretotyping

Wie kann so schnell wie möglich Feedback vom Markt eingeholt werden, um sicherzustellen, dass nur wirklich Nutzen schaffende Produkte und Features realisiert werden? Der Begriff des Prototyping ist bekannt. Doch auch für so manchen Prototypen wird noch Wochen und Monate gearbeitet.
Alberto Savoia empfielt: „Pretotype it!„. Und stellt auch gleich ein kostenfreies E-Book bereit, in dem er erklärt, wie hierfür vorzugehen ist.

Weitere Ausgaben der Produktmanagement Lesetipps:

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

Aus Fehlern eine Chance machen

Problems are OpportunitiesEin aktueller Vorfall bei UserVoice zeigt sehr schön, wie sich aus Fehlern eine Chance machen lässt. UserVoice ist eine Webanwendung, die es ermöglicht, gemeinsam mit den Nutzern Feature-Wünsche und Fehlermeldungen zusammen zu tragen, zu diskutieren und bewerten zu lassen. Es hilft entsprechend, die Bedürfnisse der Kunden und Anwender besser zu verstehen und passgenauere Lösungen zu entwickeln.

Ungewollt wurde den kostenfreien Nutzern eine Funktion freigeschaltet, die eigentlich nur für kostenpflichtige Nutzer vorgesehen ist: sie konnten mehrere Administratoren gleichzeitig hinterlegen.

Die Ankündigung der Behebung dieses Fehlers erfolgt durch den UserVoice Community Manager Evan Hamilton auf diese Weise:

„Hey there,

The other day we discovered that we screwed up, and you benefited from it. You basically got the „Bank Error in Your Favor“ card from the Monopoly board game. 🙂

Free UserVoice accounts are only supposed to be allowed to have a single Admin…to add additional Admins, you must upgrade your account. Due to a bug, this wasn’t the case: you, and a number of other accounts, were able to add as many Admins to your Free plan as you wanted. Oh dear.

Obviously, we need to rectify this; we can’t make any money unless we have limits on our accounts. However, this was our error and we do feel badly about that. Here’s what we’re going to do:

We’ll give you a little over 60 days (what with holiday schedules and all) to upgrade your account before we reactivate the restrictions. For more info on our plans, see http://uservoice.com/plans. To change your plan, follow these steps: https://feedback.uservoice.com/knowledgebase/articles/40223. That means you have until about February 13th to make any adjustments.
We’re going to give you 50% off any UserVoice plan for a year, since this was our issue. Just use this code: freebug (How to redeem: https://feedback.uservoice.com/knowledgebase/articles/40216)
I’m extremely sorry you had to be inconvenienced by this (Though I’m glad you were undercharged, not overcharged!) and I’d be happy to answer any questions you might have. Thanks for your understanding!

-Evan Hamilton
Community Manager, UserVoice“

Diese Dinge macht Evan in diesem Fall meines Erachtens besonders gut, um aus dem Fehler eine Chance für eine höhere Kundenbindung und mehr Umsatz zu ziehen:

  • Der offene Umgang mit dem Fehler führt zu einer großen Sympathie und schafft Vertrauen.
  • Es ist ein Anlass für UserVoice, mal wieder alle kostenfreien Nutzer zu kontaktieren. Aus eigener Erfahrung kann ich sagen, dass das kurzzeitig zu einer deutlichen Zunahme der Aktivität der Nutzer führt.
  • Die kostenfreien Nutzer erhalten den Vorteil für weitere 60 Tage, so dass auch andere kostenfreien Nutzer den ungeplanten Vorteil temporär nutzen und somit ein Premium-Feature ausprobieren können.
  • Evan leitet direkt in einen Verkaufsprozess über. Durch das besondere Angebot eines 50%-Discounts wird es besonders interessant, ein Upgrade durchzuführen.

Foto: von Donna Grayson
——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-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.

Anwenderbetreuung mit den richtigen Tools unterstützen

Anwenderbetreuung Für Internetportale, die es mit einer breiten Nutzerschaft zu tun haben, stellt sich die Frage, wie sie die Anwenderbetreuung optimal organisieren. Es gibt eine Reihe von Tools, die dabei unterstützen können, diese Prozesse effektiv und effizient abzubilden. Eine Auswahl davon stelle ich in einem aktuellen Beitrag „Fünf Tools für Nutzerbetreuung“ bei Gründerszene vor: CoTweet zur gemeinsamen Verwaltung von Twitter-Accounts, UserVoice für die Sammlung und Bewertung von Feature-Wünschen durch die Anwender, SnapEngage für Live-Chats mit Website-Besuchern, MailChimp für den Versand von Newslettern und OTRS für die strukturierte Verarbeitung von Mail-Anfragen.

Zum Artikel bei Gründerszene

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: tyle_r

Userstories: Volle Konzentration auf den Kundennutzen

Ein zentraler Vorteil der Verwendung von Userstories für die Beschreibung von Anforderungen ist es, den Kundennutzen stark in den Vordergrund zu stellen. Wofür wird eine Funktion eigentlich entwickelt? Das sollte allen Beteiligten stets präsent sein.

Ein weiterer Vorteil von Userstories ist, dass Stories schreiben eine Übungssache ist und sich von jeder Person erlernen lässt. Vereinfacht wird der Einstieg in das Schreiben von Userstories durch Vorlagen für den Satzbau.
Bisher habe ich meist diese sehr gebräuchliche und verbreitete Vorlage für das Schreiben von Nutzerstories verwendet:

Als (Anwendertyp) möchte ich (folgende Aktion durchführen), um (dieses Ziel zu erreichen).

Für diesen Aufbau einer Userstory finden sich verschiedene Referenzen. Ich habe auch sehr gute Erfahrungen damit gemacht. Der große Fortschritt gegenüber vorher von uns verwendeten Arten der Anforderungsbeschreibung ist u.a. darin zu sehen, dass die Stories für jeden verständlich sind und der Kundennutzen klar ausgedrückt werden muss.

Aus einem Gespräch mit einem Kollegen und ScrumMaster habe ich lernen dürfen, dass eine leichte Modifikation des Aufbaus der Userstory dabei hilft, den Kundennutzen noch stärker in den Fokus zu rücken. Das sieht dann wie folgt aus:

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

Den Fokus auf den Kundennutzen zu richten ist wichtig und richtig. Daher werde ich zukünftig auch diese Vorlage verwenden.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: CannedTuna

%d Bloggern gefällt das: