Browse Tag

Product Backlog

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

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