Produktmanagement Lesetipps: Next Feature Fallacy, Erfolgreich Pitchen, Werthaltige Innovation, Software-Architektur, Daily Standup

glasses

Die Lesetipps von heute fassen mal wieder ganz kompakt ein paar Blogartikel über wesentliche Themen des Produktmanagements von Internetanwendungen zusammen, deren Lektüre lohnenswert ist.

 

 

  • „Next Feature Fallacy“: Das kommende Feature wird die Leute dazu bringen, das Produkt zu nutzen? Nein! Häufig ist das nicht der Fall und es ist wichtig, sich darauf zu fokussieren, dass das Grund-Produkt einen guten Value liefert, schreibt Andrew Chen. Den Reiz von neuen Features kenne ich aus der eigenen Backlog-Priorisierung heraus auch sehr gut. Ein guter Reminder, noch einmal die Grundfeste des Produkts zu überprüfen und nicht auf die Zugkraft von neuen Features zu hoffen.
  • Die eigene Idee zu pitchen, ob gegenüber Investoren oder potentiellen Kunden, gehört gerade in der Anfangsphase der Produktentwicklung häufig zum täglichen Brot eines Produktverantwortlichen. Worauf bei einem Pitch geachtet werden sollte, könnt Ihr aus Investorensicht bei Matt Bolton (Bolt Capital) lesen. Sehr schön insbesondere noch einmal der Hinweis, einen relevanten Use-Case vorzuweisen, anstatt lange über Features und Spezifikationen zu sprechen. Am Ende ist es der Nutzen für den Kunden und die Anwender, der entscheidend ist.
  • Bei Innovation geht es um Problemlösung und nicht darum, Ideen zu haben. Und Autor Aaron Shapiro liefert in seinem Beitrag auch gleich noch ein paar Anregungen, wie sich echte Probleme finden lassen.
  • Ein ProductOwner spezifiziert, was und wie es gebaut wird. Kann er auch die Software-Architektur vorgeben? Mike Cohn bejaht diese Frage und schildert Fälle, in denen es auf jeden Fall auch sinnvoll sein kann, dass der ProductOwner entsprechenden Einfluss nimmt.
  • Das Daily Scrum / Daily Standup ist zu viel Zeitverschwendung und sollte automatisiert werden? Mark Levison erläutert, warum weder der erste, noch der zweite Teil zutreffend sind. Die Ziele des „Daily“ sind nur in einem persönlichen Austausch wirklich erreichbar, dafür sollten dann aber auch 15 Minuten ausreichend sein.

 

 

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

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

10 deutsche Scrum-Experten, denen zu folgen sich lohnt

Ken Schwaber, Mike Cohn, Jeff Sutherland – wer sich mit Scrum beschäftigt, braucht nicht lange, um über die Namen dieser internationalen Experten zu stolpern.
Wie schaut es mit unserer deutschen Szene und den dortigen Experten aus? Wem solltet Ihr folgen, um möglichst viele wertvolle Impulse mitzunehmen?

Hier findet Ihr einmal eine Liste mit ein paar Empfehlungen, die Ihr gerne per Kommentar ergänzen könnt.

Roman Pichler

Der Certified Scrum Trainer Roman Pichler ist nicht zuletzt durch seine zahlreichen Publikationen rund um Scrum und agile Softwareentwicklung, wie etwa „Scrum – Agiles Projektmanagement erfolgreich einsetzen„, bekannt. In seinem Blog stellt er regelmäßig neue Methoden und Ansätze zur Entwicklung innovativer Produkte vor.

Roman Pichler (@romanpichler) bei Twitter | Blog | Website

Boris Gloger

Seit 2003 berät Boris Gloger, der als direkter Schüler von Ken Schwaber ausgebildet wurde, Kunden darin mit Scrum effektiver, schneller und zuverlässiger Produkte zu entwickeln und hat dazu beigetragen, dass sich Scrum in Europa, Südafrika und Brasilien zum defacto Standard der agilen Software Entwicklung durchgesetzt hat.

Boris Gloger (@borisgloger) bei Twitter | Blog | Website

Stefan Roock

Stefan Roock arbeitet seit 2000 als Coach, Trainer und Teammitglied für agile Ansätze wie Scrum, Kanban und XP. Er ist Certified Scrum Trainer (CST) und hat mehrere Bücher geschrieben, unter anderem über eXtreme Programming, Refactoring und Hibernate.

Stefan Roock (@StefanRoock) bei Twitter | Blog | Website

Simon Roberts

Simon Roberts ist ein Certified Scrum Trainer und Scrum Coach bei ScrumCenter. Er setzt bereits seit 2002 auf Scrum und hat sich auf die Einführung dessen in traditionellen Unternehmen, insbesondere aus dem Finanzsektor, in Deutschland und in Großbritannien spezialisiert.

Simon Roberts (@srob) bei Twitter | Blog | Website

Ralf Wirdemann

Mit vielen Fachartikeln, Konferenzvorträgen und dem Buch Scrum mit User Stories hat Ralf Wirdemann sich als Agile Coach (CSM, CSP) einen Namen in der deutschsprachigen Scrum-Szene verschafft.

Ralf Wirdemann (@rawi) bei Twitter | Blog | Website

Henning Wolf

Henning Wolf ist seit 2005 Geschäftsführer bei it-agile konnte bereits zuvor Erfahrungen in Scrum, XP und Kanban als Entwickler, Coach und Product Owner sammeln. In Publikationen und auf Konferenzen gibt er seine Erfahrungen weiter.

Henning Wolf (@henningwolf) bei Twitter | Blog | Website

Sebastian Neus

Sebastian Neus ist zertifizierter ScrumMaster und Scrum Professional. Als Vorstand der itemis ist er für den Bereich Marketing und Vertrieb zuständig. Darüber hinaus berät er Unternehmen bei der Auswahl und Einführung von Softwarearchitekturen und IT-Vorgehensmodellen. Er ist einer der Autoren von www.scrum-kompakt.de und dem zugehörigen E-Book.

Sebastian Neus bei Twitter | Blog | Website

Holger Koschek

Holger Koschek arbeitet als Berater und Coach bei der Holisticon AG. Er unterstützt Unternehmen bei der Einführung agiler Vorgehensweisen sowie der Modernisierung ihrer Softwarearchitekturen. Sein Wissen gibt er gerne in Form von Büchern, Fachartikeln und Konferenzbeiträgen weiter. U.a. in seiner Publikation: Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten.

Holger Koschek (@holgerkoschek) bei Twitter | Blog | Website

André Häusling

André Häusling besetzt ein spezielles Segment in der Scrum-Szene. Er hat mit scrumjobs „die erste Personalberatung die sich auf die Beratung und Vermittlung von Scrum-Professionals spezialisiert hat“ aufgebaut und liefert immer wieder interessante Impulse, was die Schnittstelle von agiler Softwareentwicklung und Personalarbeit angeht.

André Häusling (@scrumjob) bei Twitter | Blog | Website

Christoph Mathis

Christoph Mathis ist Coach, Mentor und Trainer bei improuv mit langjähriger Erfahrung mit Scrum und agiler Softwareentwicklung. Selbst nutzt er seit 2003 Scrum und ist zertifiziert als Certified Scrum Trainer (CST) und Certified Scrum Coach (CSC).

Christoph Mathis (@krishan_mathis) bei Twitter | Blog | Website

Wen sollte man darüber hinaus auf keinen Fall verpassen? Teilt es uns mit einem Kommentar mit.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, 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

User Stories schreiben ist wie Fahrrad fahren


Schon einmal versucht, jemandem zu erklären, wie man Fahrrad fährt? Macht nicht wirklich Sinn, oder? Man muss einfach üben, üben, hinfallen, weiter üben.

So ähnlich ist das auch mit dem Schreiben von User Stories. Diese Form der Anforderungsbeschreibung lässt sich natürlich grundlegend auch rein verbal erklären. Eine User Story besteht aus einem Namen, einem beschreibenden Satz und einer Reihe von Akzeptanzkriterien. Aber gute Stories schreiben lernt man nicht durch eine Erklärung. Das ist genau so ein Balanceakt wie Fahrrad fahren. Die Stories sollen weder zu ungenau, noch zu detailliert, weder zu groß, noch zu klein sein. Übung im Schreiben von User Stories an sich und der Austausch mit dem Team ist dabei unerlässlich. Das Team wird in der Regel sehr deutlich kommunizieren, welcher Detaillierungsgrad einer Story ausreichend ist und insbesondere, wenn er es einmal nicht ist. Ein Anforderungsworkshop mit dem gesamten Team zum Start des Projektes kann helfen, sich aufeinander einzuspielen.

Im Laufe des Projekts entwickelt sich eine gemeinsame Sprache zwischen den Beteiligten, die zu einer Vereinfachung der Zusammenarbeit führt und es damit gerade auch jenen leichter macht, die in dem Projekt einen großen Teil der Stories schreiben.

Aber am Anfang steht: der Anfang. Wie beim Fahrrad fahren. Der Mut wird belohnt.

Weitere Informationen zu User Stories:

Foto: Von Bruce McAdam

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

Buch Review: User Stories Applied von Mike Cohn

Userstories sind eine besondere Form der Beschreibung von Anforderungen in Software-Entwicklungsprojekten. An die Stelle einer technischen Beschreibung oder Anforderungsliste tritt eine „Geschichte“ aus der Perspektive des Nutzers, die auch Nicht-Technikern ein Verständnis und eine Wertschätzung ermöglichen.

Wie Userstories in der Praxis richtig angewendet werden können, lässt sich mit Hilfe des Buches „User Stories Applied“ erlesen. Der Autor des Buches Mike Cohn ist einer der absoluten Top-Experten im Bereich agile Softwareentwicklung. Er hat ein hilfreiches Werk für Einsteiger und Auffrischer geschaffen.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: