Open Space der Usergroup „Agile Rhein-Main“ am 21.4.2012

27. Januar 2012 Hinterlasse einen Kommentar

Es war auf dem Rückweg vom „Community Day“ einer Konferenz im vergangenen Jahr. Mit meinen Kollegen von //SEIBERT/MEDIA komme ich zu dem Schluss, dass das Open-Space-Format des „Community Day“ mindestens so wertvoll war wie die Vorträge von den Vortagen. Die Vielfalt der Themen und die Interaktion der Sessions haben den Tag unglaublich kurzweilig und lehrreich gemacht.
Keine Frage, so etwas brauchen wir auch im Rhein-Main-Gebiet.

Gemeinsam mit Benjamin Reitzammer, Reto Kiefer und Joachim Seibert von der Agile Usergroup Rhein-Main haben wir in den letzten Wochen die Rahmenbedingungen abgestimmt und laden nun am 21.4.2012 zum 1. Agile Open Space Rhein-Main nach Wiesbaden in die Räumlichkeiten von //SEIBERT/MEDIA ein.

Was ist ein Open Space?

Um es auf den Punkt zu bringen: Wir bieten den Rahmen, Ihr sorgt für die Inhalte.

Bei einem Open Space gibt es keine vorab festgelegte Agenda. Jeder Teilnehmer bekommt die Möglichkeit, eigene Sessions zu seinen Wunschthemen einzubringen. Dies können vorbereitete Sessions sein, die eher den Charakter eines Kurz-Workshops haben, z.B. auch Dojos oder Katas. Aber auch Diskussionsrunden, bei denen der “Session-Host” nur das Thema einbringt und die Moderation der Session übernimmt, die Inhalte aber von allen Teilnehmern gemeinsam erarbeitet werden, sind üblich. Es gibt keine Verpflichtung, selbst Themen einzubringen, es kann sich auch einfach Sessions von anderen Personen angeschlossen werden.

Wir erhoffen uns ein breites Themenspektrum über Scrum, Lean, Kanban, XP, Agile, … in den unterschiedlichsten Ausprägungen.

Nicht zu kurz kommen soll dabei auch der lockere Austausch zwischen den Teilnehmern, etwa beim Mittagessen, so dass wir uns untereinander noch besser kennen- und voneinander lernen.

Anmeldung

Die Anmeldung zu diesem Event erfolgt über XING. Es wird bei Anmeldung eine Kostenbeteiligung in Höhe von 29 Euro für Verpflegung, Materialien und Organisation berechnet.

Hier geht es zur Eventseite bei XING.

Foto: von logicalrealist

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

Werbeanzeigen

Filed under Kanban, Methoden, Scrum Tagged with , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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

14. März 2011 2 Kommentare

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.

Filed under Kanban, Links, Literatur, Methoden, Scrum Tagged with , , , , , , , , , , , , , , , , , , , , ,

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

10. Dezember 2010 9 Kommentare

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

Filed under Management, Methoden Tagged with , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

%d Bloggern gefällt das: