Neue Produktideen austesten, ohne den Überblick zu verlieren – Lean Startup-Workshop mit Lukas Fittl (Spark59) am 8. April

Lean Startup ist das neue Buzzword – aber was bedeutet es wirklich? Wie kann man neuartige Produktentwicklung am effektivsten durchführen?

In einem Workshop am 8. April in Wiesbaden wird von Lukas Fittl eine praktische Umsetzung von Lean Startup erklärt – der Lean Stack, wie in folgenden Artikeln beschrieben: Teil 1Teil 2 & Teil 3.

Der Inhalt des Workshops

Lean Stack ist ein Ansatz der sich an existierenden Kan-Ban/SCRUM Konzepten orientiert, und das Konzept der A3 Reports aus dem Toyota Production System aufgreift um neue Produktideen zu dokumentieren und Resultate mit dem Team zu teilen.

leanstack

Im Workshop bearbeitet werden Themen wie das Build-Measure-Learn Konzept, die Definition von User Hypothesen (vs User Stories) und wie man den richtigen Rahmen für neue Produktideen setzen kann.

Ausserdem behandelt wird die Frage “Wann soll ich neue Funktionalität wirklich implementieren?”, und wie man qualitiative Interview und Beobachtungs-Techniken anwenden kann um unnötige Features und Entwicklungszeit zu vermeiden.

Aus diesem Workshop nimmt man mit:

  • Was Lean Startup für den klassischen Kan-Ban/SCRUM Ansatz bedeutet
  • Wie kontinuierliche Produktinnovation ermöglicht werden kann
  • Wie man im Team gemeinsam neue Produktideen und Hypothesen bearbeitet
  • Wie qualititative und quantitative Daten neue Produkt Ideen beeinflussen
  • Wie Vision, Business Modell und wirtschaftliche Ziele zusammenspielen

Der Workshopleiter: Lukas Fittl

Lukas Fittl von Spark59

Lukas Fittl von Spark59

Lukas Fittl arbeitet seit 2006 an seinen Startup Unternehmen – gründete unter anderem das Blogging Netzwerk Soup.io, und arbeitet mit Ash Maurya (Autor von Running Lean) gemeinsam an Spark59 und USERcycle.

Er hat zum Thema Lean Startup bereits in vielen Städten Europa’s referiert, unter anderem als Gastvortragender an der London Business School und als Keynote Speaker bei der Smidig Konferenz in Oslo.

Die Teilnehmer

Dieser 4-stündige Workshop ist praktisch orientiert, und richtet sich an Unternehmer, Produkt Manager und deren Team Mitglieder.

Es wird erwartet das die Teilnehmer aktiv an einem Produkt arbeiten und ihre eigenen Fragestellungen daraus mitbringen.

Austragungsort

Der Workshop findet statt in den Büroräumen von //SEIBERT/MEDIA GmbH in der Kirchgasse 6, 65185 Wiesbaden.

Anmeldung

Die Anmeldung ist ab sofort über diese Eventbrite-Seite möglich.

——–
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 am 7. November 2013 in Wiesbaden

Über diese Anzeigen

Die besten Ressourcen zu User Stories

Userstories sind eine besondere Form der Anforderungsbeschreibung, die sowohl Kunden, Anwender, Projektmanager als auch Softwareentwickler verstehen können. Besonders gerne werden sie in der agilen Softwareentwicklung eingesetzt. Dieser Beitrag gibt einen Überblick über die besten Artikel und Bücher zum Thema User Stories:

Deutschsprachige Artikel

Englischsprachige Artikel

Buchtipps:

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

Englische Version des Artikels

Produktmanagement Lesetipps: Überblick agiler und schlanker Methoden, die Rolle des Product Owners, 10 Tipps zur Backlogpflege, Sprint-Retrospektiven, Usertests

Diesmal mit einem Überblick über agile und “schlanke” Methoden, Ken Schwabers Forderung nach “richtigen” Product Owner, 10 Tipps für die Product Backlog-Pflege, kurzweilige Sprint-Retrospektiven, erfolgreiche Usertests und die 3Cs von Userstories.

  • Was hat es mit XP, Scrum und Kanban auf sich, wie unterscheiden sie sich voneinander? Bei The Agilista PM gibt es einen Überblick über agile und “schlanke” Methoden.
  • Ken Schwaber macht sich Gedanken über die Art, wie derzeit die Rolle des Product Owners gelebt wird. Viele Produktmanager nehmen sich von der Rolle aus und lassen einen Business Analyst die entsprechenden Aufgaben erfüllen. Er sieht die Ursache darin, dass die Entwickler sich einen Product Owner wünschen, der ihnen gut vorbereitete User Stories liefert. Viel wichtiger erscheint ihm jedoch jemanden zu haben, der den Business Value richtig vorantreiben kann. Dies kann auch als Warnung an alle Product Owner gelten, die sich zu stark darauf fokussieren, den Entwicklern die richtigen Häppchen vorzuwerfen und dabei das Produkt und den Nutzen der User aus dem Auge verlieren.
  • Roman Pichler bietet in seinem Blog 10 Tipps für die Pflege von Product Backlogs, die insbesondere Scrum Product Owner lesen sollten.
  • Wenn sich nach vielen gemeinsamen Sprints Routine im Team breit macht, ist es förderlich, für Variationen im Ablauf der Sprint-Meetings zu sorgen. Eine Idee, wie sich Sprint-Retrospektiven interessanter und kurzweiliger gestalten lassen, gibt es im Projekt-Log.
  • Auf vier vergessene Prinzipien von Usertests verweist Userfocus. Bei der Beobachtung mehrerer Usertests ist David Travis auf einige Dinge gestoßen, die sich negativ auf das Ergebnis des Tests auswirken. Ein kleiner Reminder für alle, die sich mit Usertests beschäftigen.
  • Was gilt es beim Schreiben von Userstories zu beachten? Weiterhin gelten die 3Cs für Userstories von Ron Jeffries aus dem Jahr 2001: Card, Conversation und Confirmation. Ein Einstieg für Produktmanager, die sich neu mit User Stories beschäftigen.

Produktmanagement Lesetipps: Definition of Ready, Geschäftsmodelle validieren, “Running Lean” zum kostenlosen Download

Die Weihnachtstage liegen hinter uns und es geht mit großen Schritten auf das neue Jahr zu. Dennoch bleibt mein RSS-Reader mit zahlreichen interessanten Blogs zum Produktmanagement und zu agiler Softwareentwicklung auch in dieser Zeit nicht leer. Ein paar besonders interessante Posts möchte ich gerne mit euch teilen.

Roman Pichler muss gewusst haben, was uns derzeit umtreibt. Gerade, wo ich mit meinem Team über eine Definition of Ready gesprochen habe, also eine Festlegung, wann eine User Story und andere Aufgaben bereit für eine Umsetzung sind, veröffentlicht er einen Blogpost über The Definition of Ready. Vielen Dank dafür! ;-) Der Artikel wird in Kürze unseren Teamraum zieren.

Jason Cohen ist ein Großer. Vor einigen Jahren hat er SmartBear Software, ein Unternehmen, das Tools für die Softwareentwicklung und für Softwaretests entwickelt, aufgebaut und verkauft. In der Zwischenzeit hat er sich weiteren Projekten gewidmet und baut derzeit WPEngine auf. Zufällig kommt er auch noch aus einer meiner Lieblingsstädte in den USA, Austin. Jason schreibt ein hervorragendes Blog, dass jedem Produktmanager wärmstens zu empfehlen ist: A Smart Bear. Ein Teil seiner Blogposts wird zusätzlich bei Building43 veröffentlicht, ein Blog, das kein geringerer als Robert Scoble verantwortet. Vor kurzem ist wieder ein sehr wertvoller Artikel erschienen, in dem Jason empfiehlt, mindestens 10 Leute zu suchen, die die bestätigen, dass sie dein Produkt kaufen würden, bevor du mit dessen Umsetzung startest: Yes, but who said they’d actually BUY the damn thing?

Ebenfalls aus Austin kommt Ash Maurya. Er schreibt ein Blog über Lean Startups. Eine erste Version eines Buches, das er bald unter dem Namen “Running Lean” veröffentlichen möchte, hat er jetzt für seine Leser kostenlos zum Download bereitstellt: Grab your copy of “Running Lean” (roughcut).

Dir hat dieser Beitrag gefallen? Dann hinterlasse doch einen Kommentar. Wenn du über das Produktmanagement und die Vermarktung von Internetanwendungen auf dem Laufenden gehalten werden möchtest, kannst du auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

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

User Stories: Anforderungen aus Nutzersicht dokumentieren

User Stories Für das Blog von //SEIBERT/MEDIA habe ich einen Artikel über User Stories geschrieben: User Stories: Anforderungen aus Nutzersicht dokumentieren.
Der Artikel erklärt, warum User Stories als Werkzeug zur Beschreibung von Anforderungen sinnvoll sind, mit welchem Gerüst sich User Stories einfach schreiben lassen, welche Kriterien eine gute User Story erfüllen muss und auch, was eine Story Card ist.

Zum Artikel im //SEIBERT/MEDIA Blog

 

 

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 psd

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

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 1.265 Followern an

%d Bloggern gefällt das: