Verwaltung eines Multi-Produkt-Backlogs

Wie lässt sich die Verwaltung eines Backlogs mit mehreren Produkten übersichtlich darstellen, so dass der Product Owner die Backlog-Verwaltung und die Release-Planung mit mehreren Stakeholdern komfortabel und effizient vornehmen kann? Wir haben uns hier zur Strukturierung eines Backlogs mit mehreren hundert Tickets dafür entschieden, einmal den Canvas for JIRA von Comalatech auszuprobieren, der eine Erweiterung von Atlassians JIRA darstellt.

In einem Workshop haben wir eine Matrix aufgespannt, die wir anschließend digital abgebildet haben. Besonders wichtig für die Release-Planung ist dabei die Aufgliederung des Backlogs nach dem MoSCoW-Prinzip. Die Backlogs der einzelnen Produkte werden nach diesem Prinzip eingeteilt in diese Kategorien:

  • Must-have-Anforderungen (sie sind essenziell für die Anwendung und unbedingt umzusetzen)
  • Should-have-Anforderungen (Anforderungen, die nicht zwangsläufig umgesetzt werden müssen, aber dennoch einen hohen Nutzen haben)
  • Could-have-Anforderungen (falls noch Zeit und Budget vorhanden ist)
  • Won’t-have-Anforderungen (Sie sind sinnvoll, aber nicht jetzt)
Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Unterstützung bei der Planung von Releases

Diese MoSCoW-Kategorien sind recht leicht verständlich und machen auch deutlich, auf welchen Teil sich für die Planung der nächsten Releases zunächst fokussiert werden kann. Diese Ansicht hilft also dabei, in einer Release-Planung für die Produkte schnell zu prüfen, was Berücksichtigung finden sollte.

Tickets der Kategorie „Won’t have“ entfernen wir aus dem Backlog, um diesen übersichtlich zu halten. Wir haben aber noch zusätzlich eine Ebene „High Business Value“ zum Einsatz gebracht, mit der zum Ausdruck gebracht werden kann, dass bestimmte Funktionalität (die in Must, Should oder Could liegen kann) ein gutes Verkaufsargument liefern würde.

Visualisierung der Arbeit für den Product Owner

Durch diese Art der Visualisierung wird auch einfach deutlich, wenn Tickets bestehen, die noch keiner Komponente/keinem Produkt zugeordnet wurden oder die noch nicht mit einer Priorität versehen wurden. Dadurch kann der Product Owner einfach sehen, wo er noch aktiv werden muss. In der ersten Spalte befinden sich dazu die „unlabelled“ Tickets, die dann per Drag&Drop einfach in die passende Spalte gezogen werden können.

Sind neue Tickets noch nicht dem richtigen Produkt zugeordnet worden, wird ganz oben eine erste Zeile angezeigt. Hier kann der Product Owner dann ebenfalls tätig werden und die Tickets dem entsprechend passenden Produkt zuordnen.

——–
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 in Wiesbaden

Scrum und Agile Softwareentwicklung – Praxisorientierte Einführung am 24. und 25. Februar 2014

Am 24. und 25. Februar 2014 findet in den Räumen der //SEIBERT/MEDIA GmbH in Wiesbaden eine zwei-tägige, praxisorientierte Einführung zu Scrum & agiler Softwareentwicklung an.

Neben den interaktiven Workshop-Teilen bieten wir auch Einblicke in die konkrete Anwendung agiler Vorgehensweisen im Projekt- und Produktgeschäft bei //SEIBERT/MEDIA.

Inhalte des Workshops

Einführung in Scrum & Agile Softwareentwicklung

  • Was ist agil? – Agile Werte und Prinzipien
  • Unterschiede zum klassischen Projektmanagement
  • Scrum: Konzepte und Funktionsweisen

Das Scrum-Framework

  • Die Rollen in Scrum: Team, Scrum MasterProduct Owner
  • Iteratives Vorgehen: Die Scrum-Sprints
  • Anforderungen planen, priorisieren und umsetzen: User-Stories
  • Wartungsaufgaben und Neuentwicklung unter einen Hut bekommen
  • Das TaskboardProduct Backlog, Todo, Doing, Done
  • Die Scrum-Meetings und ihre Bedeutung
  • Papier vs. Tool-gestützt oder Papier und Tool-gestützt?
  • Der visuelle Teamraum

Strategie

  • Politische Argumente für Agile
  • Einführungsstrategien: Best Practices
  • Stolperfallen und Probleme
Scrum-Prozess

Einführung in das agile Framework „Scrum“

Die Trainer

Joachim Seibert

Überzeugter Verfechter agiler Softwareentwicklung, zertifizierter Scrum Master (CSM) und Scrum Developer (CSD) und Scrum Professional (CSP). Leitet seit 1996 die Entwicklungsabteilung bei //SEIBERT/MEDIA und ist maßgeblich dafür verantwortlich, dass dort agile Methoden eingeführt worden sind. Er hat es sich zur Hauptaufgabe gemacht, Entwicklungsteams und Unternehmen agiler zu machen.

Paul Herwarth von Bittenfeld

Paul Herwarth von Bittenfeld arbeitet seit 2003 bei //SEIBERT/MEDIA mit und in Software-Entwicklungsteams, zunächst als Projektleiter, später als Product Owner und aktuell als ScrumMaster. In den letzten Jahren begleitete er die Einführung von Scrum und Kanban in mehreren Teams und die Einführung agiler Methoden und Vorgehensweisen auf Unternehmensebene sowohl bei //SEIBERT/MEDIA selbst als auch als Agile-Coach in Kundenprojekten.

Location

//SEIBERT/MEDIA GmbH
Kirchgasse 6
65185 Wiesbaden

Anmeldung

Die Anmeldung kann über die XING-Eventseite erfolgen. Die Teilnahme für die zweitägige Schulung inklusive Verpflegung kostet 799 Euro zzgl. MwSt.

——–
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 in Wiesbaden

Lean Startup Day in Hamburg – Vortrag zu „Lean Startup vs. Fat Scrum-Team – ein Erfahrungsbericht“

enterprise-lean-startup-day
Am 14. Februar richten unsere Freunde von it-agile einen Enterprise Lean Startup Day in Hamburg aus. Die Konferenz richtet sich an Projektleiter und Product Owner, die in komplexen Situationen bei Unsicherheit Produkt- oder Projektentscheidungen treffen müssen. Zielgruppe sind explizit bestehende Organisationen und nicht Neugründungen.

Mittlerweile ist das Konferenzprogramm auf der Website einsehbar und ich werde einen Beitrag „Lean Startup vs. Fat Scrum-Team – ein Erfahrungsbericht“ beisteuern. Ein Auszug aus meinem Abstract:

Vor wenigen Jahren als Scrum-Projekt gestartet, hat sich die Entwicklung des Produkts TwentyFeet für den IT-Dienstleister //SEIBERT/MEDIA aus Wiesbaden als teure Erfahrung herausgestellt. Kontinuierlich neue Features mit guter Qualität liefern? Ja, klappt mit einem Scrum-Team super. Treffen die entwickelten Funktionalitäten auch die Bedürfnisse und Zahlungsbereitschaft der Kunden? Nicht immer. Seit dem Sommer 2012 hat ein Lean Startup-Team die Entwicklung übernommen. Lessons Learned aus einem realen (und teuren) Projekt.

Alle Informationen zur Konferenz gibt es auf der Konferenzwebsite. Es würde mich freuen, wenn wir uns in Hamburg sehen.

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

Commitment gerissen! Na und?

Sprint-Review. Das Scrum-Team hat sich für den Sprint einiges vorgenommen. Schnell stellt sich heraus: ein großer Teil davon konnte nicht erreicht werden. Doch scheinbar stört sich das Team nicht daran. – Wie sollte ein Product Owner darauf reagieren?

Dieses Szenario wurde vor kurzem bei einem OpenSpace besprochen und es sind einige Anregungen zusammen gekommen, wie darauf reagiert werden könnte. Im Kern steht dabei unsere Annahme, dass das Team vor allem deshalb relativ gleichgültig auf das Verfehlen ihres Sprintziels reagiert hat, weil sie nicht mehr erkennen konnten, dass es irgendjemanden interessiert. Die Geschäftsführung hatte sich schon seit Monaten in keinem Review mehr blicken lassen, die Ergebnisse wurden nicht nach außen kommuniziert und die Reviews wurden nur noch pro forma Team-intern durchgeführt.

  • In das Review für regelmäßige Beteiligung von Kunden und anderen Stakeholdern sorgen: Die Beteiligung der Kunden, Geschäftsführung oder anderer Stakeholder könnte dem Team aufzeigen, dass es diesen Teilnehmern wichtig ist, was an Software ausgeliefert wird.
  • Kosten eines Delays aufzeigen: Es könnte dem Team aufgezeigt werden, wie sich die Verzögerung über mehrere Sprints hinweg derart auswirkt, dass das kommende Release über deutlich weniger Funktionalität verfügt und damit auch die Zufriedenheit der Kunden klar gefährdet wird.
  • Gemeinsames Review mit mehreren Teams, wenn vorhanden: Sofern mehrere Teams im Unternehmen arbeiten, könnte ein Review mit mehreren Teams gemeinsam durchgeführt werden. Dies könnte es auch der bereits genannten Geschäftsführung ermöglichen, wieder an Review-Terminen teilzunehmen, wenn nicht jedes Team einen eigenen Termin hat.
  • Die Art des Reviews variieren, z.B. im Stil einer „Messe“: Damit das Review interessant bleibt, könnte das Setting von Zeit zu Zeit variiert werden. Einmal im Besprechungsraum mit allen gemeinsam an einem Tisch, mal im Büro des Scrum-Teams mit verschiedenen Stationen, an denen die einzelnen Arbeitsergebnisse präsentiert werden, … .
  • Kundenbeirat zum Review einladen: Wenn das Unternehmen über einen Kundenbeirat verfügt, könnte dieser einmal zu einem Review eingeladen werden, damit Kunden und Entwickler sich einander annähern und dem Team präsent wird, für wen sie das Produkt entwickeln.

Wie würdet Ihr in so einer Situation verfahren?

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

Open Space der Agile Usergroup Rhein-Main am 18. Oktober

Das Oktober-Treffen der Agile User Group Rhein-Main steht kurz bevor. An diesem Donnerstag, 18. Oktober 2012, treffen wir uns im //SEIBERT/MEDIA-Office. Dieses Mal ist das Treffen als kleines Open Space konzipiert: Jeder kann seine Fragen und Themen einbringen und gemeinsam mit anderen Agile-Interessierten diskutieren und Lösungen erarbeiten.

Open Space: Eure Themen sind gefragt

Open Space – das heißt, dass keine Themen vorgegeben sind, sondern jeder selbst Themen einreichen und sie mit anderen Teilnehmern besprechen kann. Dabei sind alle Themen erlaubt. Sie sollten möglichst irgendetwas mit agiler Softwareentwicklung im weiteren Sinne zu tun haben und es sollte sich mindestens eine weitere Person finden, die Lust darauf hat, über das Thema zu sprechen.

Aber von konkreten Fragen zur Arbeit als ScrumMaster, ProductOwner oder Teammitglied über Herausforderungen bei der Einführung von Agile bis hin zur Ausweitung agiler Organisationsformen über die Software-Entwicklung hinaus kann eine breite Themenvielfalt erwartet werden. Damit werden an einem Abend in kompakter Form viele ganz unterschiedliche Agile-Aspekte gewinnbringend vertieft.

Einführung um 19 Uhr, Themensammlung um 19:30 Uhr

Auch wer noch nicht mit dem Open-Space-Konzept vertraut ist, ist herzlich willkommen. Ab 19 Uhr werde ich für Unerfahrene eine kurze Einführung in das Format geben. Wer sich vorab etwas einlesen möchte, der sei auf diese Artikel im Blog von //SEIBERT/MEDIA verwiesen: Das Open-Space-Konzept: Prinzipien, Regeln, Besonderheiten und Open Space bei //SEIBERT/MEDIA: Rückblick auf die jüngste Konferenz. Auch die Wikipedia-Seite gibt einen Einblick in das Konzept.

Wer Open Space bereits kennt, sollte dann zur Themensammlung ab 19:30 Uhr vor Ort sein. Gerne können auch vorab bereits Ideen für das Open Space im XING-Forum der User Group oder per E-Mail an pherwarth@seibert-media.net vorschlagen werden.

Jetzt kostenlos anmelden!

Interessant? Die Teilnahme ist kostenlos! Veranstaltungsort ist das Hauptquartier von //SEIBERT/MEDIA im zentralen Wiesbadener LuisenForum, das Sie mit allen Verkehrsmitteln und auch zu Fuß zum Beispiel vom Hauptbahnhof aus prima erreichen. Hier findet Ihr eine detaillierte Wegbeschreibung.

Getränke und Knabberzeug werden bereitgestellt. Um eine Anmeldung über die XING-Eventseite oder per E-Mail an pherwarth@seibert-media.net wird gebeten.

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

Produktmanagement Lesetipps: Product Owner-Rolle, Kunden- und Anwenderbefragungen, Bereitschaft zu Fehlern, Pretotyping

Nach längerer Pause gibt es wieder einige Leseempfehlungen aus meinem RSS-Reader zu verschiedenen Themen, die für Produktmanager von Bedeutung sind.

Die Rolle des Product Owners

Roman Pichler stellt zwei typische Varianten gegenüber, wie die Product Owner-Rolle besetzt wird: Die Besetzung durch den Kunden selbst sowie eine Besetzung mit einem Proxy. Er schlägt aber auch vor, bei einem größeren Projektportfolio die beiden Varianten zu nutzen, je nachdem, ob nur für einen Kunden oder für eine Vielzahl von Kunden entwickelt wird: „Two common ways to apply the product owner role„.

Hilfreiche Tipps für Kunden- und Anwenderbefragungen

Egal ob Customer Development, Lean Startup oder agile Softwareentwicklung – sie alle empfehlen die aktive Einbeziehung von Kunden und Anwendern. Ein Mittel hierfür ist die Durchführung von Kunden- und Anwenderbefragungen. Zur Durchführung solcher Befragungen gibt es hier zahlreiche Tipps von einem erfahrenen Produktmanager: „How do I set up customer interviews?

Keine Angst vor Fehlern

Im hervorragenden Blog von HackFwd, dem Pre-Seed Investor von Lars Hinrichs, wird die Bedeutung des Scheiterns und des Fehler machen betont. Für die Realisierung von neuen Produkten ist es wichtig, die Bereitschaft aufzubringen, Fehler zu machen und aus ihnen zu lernen: „Fail better„.

Minimale Feedbackschleifen – Pretotyping

Wie kann so schnell wie möglich Feedback vom Markt eingeholt werden, um sicherzustellen, dass nur wirklich Nutzen schaffende Produkte und Features realisiert werden? Der Begriff des Prototyping ist bekannt. Doch auch für so manchen Prototypen wird noch Wochen und Monate gearbeitet.
Alberto Savoia empfielt: „Pretotype it!„. Und stellt auch gleich ein kostenfreies E-Book bereit, in dem er erklärt, wie hierfür vorzugehen ist.

Weitere Ausgaben der Produktmanagement Lesetipps:

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

Fröhliche Weihnachten

Weihnachten 2011

Die besten Wünsche für ein paar schöne, geruhsame, erholsame, fröhliche, familiäre und besinnliche Weihnachtsfeiertage. Das Jahr neigt sich dem Ende und die etwas ruhigere Zeit eignet sich hervorragend, über die letzten Monate zu reflektieren und Pläne für die Zukunft zu schmieden. Eine lohnenswerte Aktivität mit einem hohen ROI, den wir als Product Owner und Produktmanager zu maximieren gewohnt sind.

Vielen Dank an alle treuen Leser, die in den vergangenen Jahren mit Tweets, Likes, Shares, Anregungen, Fragen, Weiterempfehlungen oder auf andere Weise dazu beigetragen haben, dass sich dieses Blog weiterentwickelt und mir großen Spaß bereitet.

Foto: von jcoterhals

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

Hyperproduktive Teams mit Scrum: „From Good to Great“

Wie können gute Teams mit Hilfe von Scrum zu großartigen Teams werden? Damit beschäftigt sich Scrum Co-Founder Jeff Sutherland schon seit vielen Jahren. Vor einiger Zeit hat er hierzu in seinem Blog geschrieben.

Jeff Sutherland macht allen motivierten Teams Hoffung, dieses Ziel erreichen zu können. Nach dem aktuellen Forschungsstand soll jedes Team in der Lage sein, hyperproduktiv zusammenzuarbeiten, auch wenn das Unternehmen, in dem das Team arbeitet, nicht die optimalen Bedingungen bietet.

Auf welche Punkte sollten Teams unbedingt achten, wenn sie hyperproduktiv zusammenarbeiten möchten?

  • Alle Teammitglieder müssen in Scrum geschult sein.
  • Der Backlog muss READY seine, bevor er in einen Sprint übernommen wird.
  • Das Software-Inkrement muss am Ende jedes Sprints DONE sein.
  • Immer wenn nur eine Person eine Aufgabe erledigt werden kann, sollte sofort mit Pair Programming gearbeitet werden.
  • Volle Fokussierung – kein Multitasking.
  • Das Team nutzt ein physisches Scrum Board / Taskboard.
  • Kurze Sprints, häufig von nur einer Woche.
  • Der Burndown erfolgt auf Story Point-Ebene (nicht Tasks oder Stunden)
  • Alles (inklusive Support) wird durch den Product Owner priorisiert.
  • Die höchstpriorisierten Hindernisse müssen aus dem Weg geräumt werden.
  • Die Führung des Teams erfolgt nach dem „Servant leadership“–Gedanken.

Eine Verdopplung der Produktivität ist laut einer Untersuchung bereits dann möglich, wenn darauf geachtet wird, dass alle Arbeiten am Ende des Sprints auch wirklich DONE sind. Die Fehlerquote konnte bei den betrachteten Scrum-Teams damit um ganze 40 Prozent reduziert werden. Wenn die Teams konsequent daran arbeiten, Hindernisse aus dem Weg zu räumen und ihre Arbeiten wirklich DONE abzuschließen, können sie leicht ihre Produktivität drastisch erhöhen. Leider tun dies nur geschätzte 50 Prozent der Scrum-Teams auf der Welt.

Eine weitere Verdopplung der Performance des Teams kann erreicht werden, wenn der Backlog einen hohen Grad von READY erreicht. Dies wirkt sich direkt auf die Effizienz in der Story-Umsetzung aus. Wenn Teams es schaffen, ihre Arbeiten jeweils entsprechend der Definition of DONE abzuschließen und auch einen sauberen Backlog pflegen, der hochgradig READY ist, können sie den Untersuchungsergebnissen nach durchaus mit der vierfachen Produktivität eines Durchschnittsteams erreichen.

Ein weiteres Level der Produktivität kann erreicht werden, wenn es sich um selbstorganisierende Teams handelt, die an der Maximierung ihrer (nachhaltigen) Team Velocity arbeiten und gemeinsame Ziele verfolgen. Dies erfordert flache Organisationsstrukturen und enge Zusammenarbeit.

Auch wenn es einfach klingt, ist es mit Sicherheit herausfordernd in der Umsetzung. Auch hier zeigt sich, dass eine gute Anwendung von agiler Softwareentwicklung viel Disziplin erfordert. Angesicht der starken Produktivitätsverbesserungen, die möglich sind, lohnt es sich denke ich dennoch, sich weiter in diese Richtung zu entwickeln. Dabei hilft diese Präsentation von Jeff Sutherland:
A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity (PDF)

Foto: drewgstephens

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

%d Bloggern gefällt das: