Browse Tag

Backlog

People vector designed by Freepik

Product Owner im Portrait: Interview Björn Waide

Im heutigen Interview steht Björn Waide (@waide) meinen Fragen Rede und Antwort. Björn bekleidet die Rolle als Product Owner seit geraumer Zeit und blickt auf einen reichen Erfahrungsschatz in der Arbeit mit diversen Scrum Teams zurück. Nach dem Studium der Informatik startet Björn als Software-Entwickler in das Berufsleben und ist mittlerweile sechs Jahre als Produktmanager tätig. Durch die Arbeit in einem agilen Arbeitsumfeld verantwortete er in den letzten drei Jahren verschiedene Produkt-Initiativen in der Rolle des Product Owners. Erfahren sie im Interview mehr über seine Erfahrungen, Herausforderungen und Tipps.

Steckbrief

  • Name: Björn Waide
  • Alter: 32
  • Angestellt als: Director Product Management
  • Product Owner Rolle seit: 2009
  • Berufserfahrung gesamt: 6 Jahre
  • Branche: Internet, Dienstleistung
  • Produkt Thema: Social Network

Was ist deines Erachtens das Schwierigste bei der Erfüllung der Product Owner Rolle?

Die Product Owner Rolle stellt hohe Anforderungen aus allen möglichen Teilgebieten an den, der sie ausfüllen soll. Man muss sich in Details auskennen und doch immer das große Ganze sehen. Muss mit Entwicklern über technische Machbarkeit diskutieren oder mit dem Marketing über Produkteinführungsstrategien. Es gibt wohl kaum jemanden, der alle Anforderungen aus allen Teilgebieten gleich gut abdeckt. Für jeden wird also die Schwierigkeit an einer anderen Stelle liegen. Es ist wichtig, sich selbst zu reflektieren und an den Punkten, an denen Wissen oder Erfahrung fehlt, Hilfe von Kollegen oder Fachspezialisten einzuholen. Weiterlesen

Paper vector designed by Freepik

Wer schreibt eigentlich die User Stories?

Der Einsatz von User Stories in der Agilen Softwareentwicklung wird immer populärer. Viele sehen das Verfassen von Benutzergeschichten als Aufgabe des Product Owners – aber wieso eigentlich?

Ich bin der Meinung, dass jeder User Stories erstellen kann. Mike Cohn plädiert sogar dafür, dass alle Projektzugehörigen mindestens eine User Story verfasst haben sollten. Ich verfolge diesen Ansatz auch in meinen Projekten und habe gute Erfahrungen damit machen können. Zwei Anwendungsfälle aus der Praxis möchte ich heute kurz vorstellen.

Im ersten Fall mussten wir bei Start eines Projektes zügig zu ersten User Stories gelangen. Da das Projekt sehr technisch ausgelegt war, waren die Entwickler aus dem Team prädestiniert für das Schreiben der initialen Stories. Also veranstaltete ich mit dem Team und Product Owner einen User Story Workshop. Dieser startete mit den Grundlagen. Daraufhin ging es schnell an das Eingemachte und wir definierten die User Rollen und bestimmten die Ziele.

Weiterlesen

Hat vector designed by Freepik

Gastbeitrag: Die magische Schätzmethode

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Neben dem von Sven kürzlich vorgestellten Team Estimation Game, möchte ich heute noch eine weitere Herangehensweise vorstellen, die mir zu Ohren gekommen ist und eine zügige initiale Schätzung des gesamten Product Backlogs möglich machen soll: Magic Estimation.

Gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den Zeitaufwand für die zu entwickelnden Funktionalitäten zu kommen. Vor dem ersten Sprint sollten daher ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und priorisiert sein, um diese vom Team schätzen zu lassen. Weiterlesen

Light vector designed by Freepik

Gastbeitrag: Team Estimation Game

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Es wurde 2002 von James Grenning erstmalig beschrieben und später durch Mike Cohn’s Buch Agile Estimating and Planning sehr populär. Die Regeln sind sehr einfach und das Schätzen kann nach wenigen einführenden Worten starten. Die größte Schwierigkeit bei der Einführung liegt meines Erachtens darin, dem Team den Sinn einer Schätzung von relativer Komplexität anstelle von Aufwand in Arbeitsstunden zu vermitteln.

Wenn diese erste Hürde genommen ist, steht man vor der nächsten Herausforderung: Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument dient oft „Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man diese Diskussionen als Scrum Master nicht in den Griff bekommt, dauert die initiale Schätzung des Product Backlog viel länger als geplant (falls man überhaupt durchkommt und die weitere Schätzung nicht in die Estimation Meetings während der Sprints verschiebt).

Auf dem Scrum Gathering 2009 habe ich nun eine Methode kennengelernt, die sehr vielversprechend klingt und schnell gute Ergebnisse liefert: Das Team Estimation Game nach Steve Bockman. Die Regeln für das Spiel sind simpel:

Weiterlesen