Archiv des Autors: Bärbel de Bouvier

Projekt-Praktikum: Story-Cards

Veröffentlicht am von

Bärbel de BouvierIch stecke mitten in meinem ersten Projekt, bei dem wir mit Hilfe von Scrum eine Community-Website entwickeln. Im letzten Blog-Posting habe ich beschrieben, wie wir zu unserem ersten Product Backlog gekommen sind. Dieser Prozess war wegen der Überschaubarkeit des Projektes und dem winzigen Team von nur drei Leuten einfach zu handlen: Wir haben uns an meinen Schreibtisch gesetzt, ein wenig diskutiert und die User-Stories in ein Merlin-Dokument eingetragen.

Der Normalfall in größeren Projekten und mit größeren Teams sieht allerdings anders aus. Zumeist wird hier mit so genannten Story-Cards und einer Pinnwand bzw. einem Whitboard und Magneten gearbeitet. Dazu erhält jeder Teilnehmer des Backlog-Meetings einen Stapel Karteikarten und einen Filzstift oder Kugelschreiber. Optimal sind linierte, nicht zu kleine Karteikarten. Postkartengröße ist optimal.

Im einfachsten Fall schreiben die Teilnehmer auf jede Karte ihre User-Story, sowie die Priorität und eine Zeiteinschätzung. Es gibt allerdings auch Fälle, in denen man auch mehr auf der Karte eintragen kann. Vor allem dann, wenn im Verlauf des Projektes mit den Karten gearbeitet wird, statt deren Inhalte in den Computer zu übertragen, so wie wir das hier tun.

Der Vorteil der Story-Cards ist, dass man damit an der Pinnwand „herumspielen“ kann. Beispielsweise, wenn sich deren Priorität ändert. Und das tut sie im Verlauf des Meetings, denn Scrum ist ja auch eine kollaborative Projektmanagement-Methode. Vor allem ist aber das gemeinsame Schreiben der User-Stories und das Diskutieren ein kreativer und damit gewollter Prozess innerhalb von Scrum.

Projekt-Praktikum: Product-Backlog-Meeting

Veröffentlicht am von

Bärbel de BouvierNach dem die CeBIT-Woche endlich rum ist und alle an meinem Projekt beteiligten Mitarbeiter wieder verfügbar sind, konnte ich letztens mein erstes Product Backlog Meeting abhalten. Zuvor hatte ich einen initialen Backlog mit den Anforderungen des Kunden zusammengestellt, der als Arbeitsgrundlage gedient hat. Die Aufgabe in diesem Meeting: Zusammen mit den Entwicklern eine erste Zeiteinschätzung, sowie generell eine Präzisierung der notwendigen Arbeitsschritte auszuarbeiten.

Da mein Projekt relativ überschaubar und das Team  recht klein ist, haben wir das Meeting an meinem Schreibtisch abgehalten. Den Input des Teams habe ich gleich in ein Merlin-Dokument eingetragen (siehe Bild). Bei größeren Projekten und Teams sind unter Umständen ausgefeiltere Techniken ratsam, etwas das Brainstorming mit Ideenkarten und einem Whiteboard. Doch dazu werde ich später ein eigenes Posting machen.

Wichtig ist, dass ich jetzt eine Grundlage für meine Arbeit habe. Ich habe schon während des Meetings eine Priorisierung durchgeführt und die Aufgaben entsprechend geordnet. Damit ist die Grundlage für das erste Sprint-Planning-Meeting schon mal geschafft.

Product Backlog

Projekt-Praktikum: Mein erster Product Backlog

Veröffentlicht am von

Bärbel de BouvierHeute habe ich mein erstes initiales Product Backlog zusammengestellt. Und darum geht es: Auf einer Kunden-Website mit Support-Forum soll ein einfaches soziales Netzwerk implementiert werden. So sollen die registrierten Anwender eine Profilseite anlegen und sich untereinander vernetzen können.

Wir erinnern uns: Das Product Backlog besteht aus so genannten User Stories. Das sind kurze, prägnante Beschreibungen der zu entwickelnden Funktionen. Und so sieht das bei mir aus:

Product Backlog „Soziales Netzwerk“ Version 1

  • Registrierte Anwender können eine Profilseite anlegen.
  • Anwender können Profilseiten anderer Anwender aufrufen.
  • Anwender können nach anderen Anwendern suchen.
  • Anwender können untereinander „Freunde“ werden.
  • Anwender sollen die Freunde ihrer Freunde sehen können.
  • Auf der Profilseite können die Anwender einen Statusmeldung posten.
  • Anzeige der Statusmeldungen von Freunden auf der Profilseite.
  • Anwender können sich untereinander private Nachrichten senden.

Manche Puristen könnten ob meines Product Backlogs eventuell die Nase rümpfen, denn es heißt, dass User Stories eigentlich folgendes Format haben sollen:

Als [Anwender Rolle] möchte ich [Ziel], damit ich [Grund] kann.

Demnach würde mein erster Product Backlog so aussehen:

Product Backlog „Soziales Netzwerk“ Version 2

  • Als registrierter Anwender möchte ich eine Profilseite anlegen können, damit ich mich optimal präsentieren kann.
  • Als registrierter Anwender möchte ich die Profilseiten anderer Anwender aufrufen können, damit ich interessante Menschen finden kann.
  • Als registrierter Anwender möchte ich nach anderen, mir bekannten Anwendern suchen können, damit ich mich mit ihnen vernetzen kann.
  • Als registrierter Anwender möchte ich mich mit anderen Anwendern „anfreunden“ (vernetzen) können, damit ich mit ihnen in Kontakt bleibe.
  • Als registrierter Anwender möchte ich die Freunde meiner Freunde sehen können, damit ich meinen Freundeskreis erweitern kann.
  • Als registrierter Anwender möchte ich auf meiner Profilseite eine Statusmeldung posten können, damit meine Freunde sehen können, was ich mache.
  • Als registrierter Anwender möchte ich auf meiner Profilseite die Statusmeldungen meiner Freunde angezeigt bekomme, damit ich weiß, was sie gerade machen.

Damit stehen die Rahmenbedingungen fest und ich kann jetzt ein Product Backlog Meeting mit dem Team einberufen. Ich bin schon gespannt, wie sich dabei die User-Stories verändern, erweitern und präzisieren werden, wenn die Entwickler ihren Input dazu geben werden.

Projekt-Praktikum: Rollenverständnis

Veröffentlicht am von

Bärbel de BouvierNach dem wir die Theorie des Product Backlogs soweit durchhaben, wird es Zeit in die Praxis einzusteigen. Ich habe auch schon einen entsprechenden Auftrag bekommen und sollte eigentlich jetzt das initiale Product Backlog zusammenstellen. Allerdings tauchte jetzt bei mir die – quasi existentielle – Frage auf, ob ich nun der Scrum Master, der Product Owner oder beides bin und in wie weit meine Rolle dem klassischen Projektmanager oder gar dem Produktmanager entspricht.

Ganz klar, der Scrum Master bin ich schon mal nicht. Ist ja schließlich mein erstes Scrum-Projekt. Der Scrum Master ist mein Chef, denn er ist derjenige, der den Scrum-Prozess kennt, moderiert und dafür sorgt dass alles Scrum-konform läuft. Mit anderen Worten, der Scrum Master ist eher Anleiter und Vermittler, denn Macher.

Da ich diejenige bin, die das Projekt am Hals hat, bin ich also der Product Owner (oder sollte ich sagen Ownerin?). Aber bin ich damit nach herkömmlichen Verständnis die Projekt- oder Produktmanagerin? Nach der reinen Scrum- bzw. Agil-Lehre definitiv nicht. Agiles Projektmanagement setzt auf die Selbstorganisation des Teams und verzichtet damit bewusst auf jeglichen „Manager“. Ich frage mich jetzt nur, wie ich meinen Eltern erklären soll, was ich mache. „Hallo Mama, ich bin jetzt Product Ownerin“?

Spass beiseite, die Sache ist ernster als es zunächst wirkt. Denn in der Regel gibt es in den meisten Unternehmen festgelegte Rollen, über die man eine agile Struktur nicht so ohne weiteres darüber stulpen kann, häufig aber muss. So streiten sich die Experten darüber, ob der Product Owner so etwas wie agile Produktmanager sind oder nicht.

Für mich stellen sich jetzt also folgende Fragen:

  1. Wie passt der „herkömmliche“ Projektmanager in das Scrum Rollen-Modell?
  2. Ist der Projektmanager der Product Owner oder vielleicht sogar der Scrum Master (eine entsprechende Zertifizierung vorausgesetzt)?

Wenn jemand eine Idee dazu hat, dann bitte ich um einen entsprechenden Kommentar zu diesem Beitrag.