Commitment gerissen! Na und?

Sprint-Review. Das Scrum-Team hat sich für den Sprint einiges vorgenommen. Schnell stellt sich heraus: ein großer Teil davon konnte nicht erreicht werden. Doch scheinbar stört sich das Team nicht daran. – Wie sollte ein Product Owner darauf reagieren?

Dieses Szenario wurde vor kurzem bei einem OpenSpace besprochen und es sind einige Anregungen zusammen gekommen, wie darauf reagiert werden könnte. Im Kern steht dabei unsere Annahme, dass das Team vor allem deshalb relativ gleichgültig auf das Verfehlen ihres Sprintziels reagiert hat, weil sie nicht mehr erkennen konnten, dass es irgendjemanden interessiert. Die Geschäftsführung hatte sich schon seit Monaten in keinem Review mehr blicken lassen, die Ergebnisse wurden nicht nach außen kommuniziert und die Reviews wurden nur noch pro forma Team-intern durchgeführt.

  • In das Review für regelmäßige Beteiligung von Kunden und anderen Stakeholdern sorgen: Die Beteiligung der Kunden, Geschäftsführung oder anderer Stakeholder könnte dem Team aufzeigen, dass es diesen Teilnehmern wichtig ist, was an Software ausgeliefert wird.
  • Kosten eines Delays aufzeigen: Es könnte dem Team aufgezeigt werden, wie sich die Verzögerung über mehrere Sprints hinweg derart auswirkt, dass das kommende Release über deutlich weniger Funktionalität verfügt und damit auch die Zufriedenheit der Kunden klar gefährdet wird.
  • Gemeinsames Review mit mehreren Teams, wenn vorhanden: Sofern mehrere Teams im Unternehmen arbeiten, könnte ein Review mit mehreren Teams gemeinsam durchgeführt werden. Dies könnte es auch der bereits genannten Geschäftsführung ermöglichen, wieder an Review-Terminen teilzunehmen, wenn nicht jedes Team einen eigenen Termin hat.
  • Die Art des Reviews variieren, z.B. im Stil einer “Messe”: Damit das Review interessant bleibt, könnte das Setting von Zeit zu Zeit variiert werden. Einmal im Besprechungsraum mit allen gemeinsam an einem Tisch, mal im Büro des Scrum-Teams mit verschiedenen Stationen, an denen die einzelnen Arbeitsergebnisse präsentiert werden, … .
  • Kundenbeirat zum Review einladen: Wenn das Unternehmen über einen Kundenbeirat verfügt, könnte dieser einmal zu einem Review eingeladen werden, damit Kunden und Entwickler sich einander annähern und dem Team präsent wird, für wen sie das Produkt entwickeln.

Wie würdet Ihr in so einer Situation verfahren?

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

Über diese Anzeigen

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.

Card, Conversation, Confirmation: Die drei C’s einer User Story

Was gibt es bei der Erstellung von User Stories zu beachten? Drei C’s können dabei helfen: Card, Conversation, Confirmation. Die drei C’s gehen auf Ron Jeffries zurück, der sie schon 2001 in einem Blogpost beschrieb: Essential XP: Card, Conversation, Confirmation.
Noch heute gelten sie neben den INVEST-Kriterien als wichtige Grundregel bei der Erstellung von User Stories.

Card
User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Team vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten. Es sollte damit nicht mehr Platz als der auf der Karte verfügbare benötigt werden, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Reicht der Platz nicht aus, ist die Story in der Regel zu groß oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über den Wunsch in Form der Konversation mit dem Team abgestimmt.

Conversation
Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story wird als sehr wichtig erachtet. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und dem Team “durch einen Türschlitz” zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während einem Anforderungsworkshop, in einer Schätzklausur und während der Sprint-Planung. Die mündlichen Absprachen werden manchmal begleitet durch zusätzliche Dokumente, wie etwa Vorlagen in einem Projektwiki oder Mockups.

Confirmation
Um einen Nachweis zu haben, ob die Stories in der gewünschten Form implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Der Kunde hält dafür vor Beginn der Umsetzung einer Story die zentralen Kriterien fest, nach denen die Abnahme der Story später erfolgen soll. Durch die Implementierung von Akzeptanztests kann die Erfüllung der Akzeptanzkriterien sichergestellt werden.

Mit den drei C hat uns Ron Jeffries eine gute Merkhilfe für die Grundregeln einer User Story an die Hand gegeben.

Weitere gute Lektüre zu User Stories:

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: Von jakuza

Gastbeitrag bei deutsche-startups: Wie Start-ups Nutzer zu aktivem Feedback motivieren können

NutzerintegrationFür Startups ist das Feedback der Nutzer unheimlich wichtig für die Produktentwicklung. Aber wie motiviert man die Nutzer dazu, auch wirklich Feedback zu geben? Zu dieser Fragestellung ist heute ein Gastbeitrag von mir bei deutsche-startups erschienen. Er basiert (wie auch mein letzter Gastbeitrag bei Gründerszene) auf unseren Erfahrungen aus der Entwicklung von TwentyFeet.

Zum Artikel bei deutsche-startups

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: Von hikingartist

Wie können Personas das Produktmanagement unterstützen?

Personas sind eine verhältnismäßig einfache Möglichkeit, um die Nutzer einer Internetanwendung im Entwicklungsprozess der Software im Fokus zu halten. Sie helfen dabei, die heterogene Zielgruppe gedanklich zu strukturieren. Für die verschiedenen Nutzergruppen werden Prototypen gebildet, deren Einstellungen, Fähigkeiten und Ziele in Entscheidungen einfließen kann.

Die brainmates aus Australien haben jetzt eine Präsentation und ein Whitepaper herausgegeben, die auf die Frage eingehen, wie Personas das Produktmanagement unterstützen können.

Mehr von diesem Beitrag lesen

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 1.269 Followern an

%d Bloggern gefällt das: