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

Produktentwicklung auf die schlanke Art

Wie viele von den Funktionalitäten, die wir in Software einbauen, bringt unseren Anwendern wirklich einen Nutzen? Zu häufig wird diese Frage gar nicht gestellt. Woran liegt das?
Häufig scheint die Überzeugung zu sein, das viel auch viel hilft. Eine endlose Feature-Liste erscheint attraktiv. Genauer betrachtet stellen Features, die den Anwendern keinen echten Mehrwert liefern, eher einen Kostenpunkt dar. Sie müssen gewartet werden und erhöhen die Komplexität einer Software-Anwendung sowohl für die Anwender, als auch die Betreiber.

Der überzeugte Lean Startup-Anwender und Buchautor Ash Maurya berichtet in einem Blogpost darüber, wie er selbst vorgeht, um nur Features in seiner Software bereitzustellen, die auch wirklich einen Nutzen für einen Großteil der Anwender erzielen.

Sein „Framework“ hierfür besteht aus mehreren Elementen. Zu jeder Zeit wählt er einen zentralen Zielwert, der angestrebt werden soll. Beispielsweise die Quote von Neu-Anwendern, die für eine dauerhafte Nutzung der Software aktiviert werden kann. Zu jeder Zeit gibt es nur eine zentrale Zielsetzung, die mit den Feature-Entwicklungsbemühungen erreicht werden soll.

Auf dem Weg von Entwicklung bis dauerhafter Aufnahme einer Funktionalität in den Produktumfang durchläuft sie vier zentrale Schritte.
Die erste Stufe beginnt mit der Priorisierung des Backlogs. Da es einen zentralen Zielwert gibt, kann die Priorisierung nach dem Beitrag für diesen Zielwert, im Verhältnis zu den für die Realisierung anfallenden Kosten, erstellt werden.
Wenn die Priorisierung geklärt ist, wird als nächstes das Top-Item genommen und durch Kunden-Interviews abgeklärt, wo genau das dahinter liegende Problem liegt. Es geht an dieser Stelle nicht darum, was die Kunden wünschen. Vielmehr geht es darum, warum sie etwas wünschen. Ausgehend von den Rückmeldungen der Kunden wird dann entschieden, ob etwas gemacht wird oder der Feature-Wunsch verworfen wird.

In der zweiten Stufe wird dann entschieden, wie das Feature umgesetzt werden soll. Es werfen hierfür erste Screens gestaltet und dann mit den Kunden, die auch interviewed wurden, dazu befragt. Es werden dann üblicherweise mehrere Iterationen durchlaufen, bevor eine Umsetzung angedacht wird.

Die Funktionalität wird dann in einem Continous Deployment-Prozess realisiert. Mit Hilfe eines Feature Flipper Systems kann dafür gesorgt werden, dass die Features auf das Live-System eingespielt werden, ohne dass sie den Anwendern zugänglich sind, bis sie fertig sind. Nach Fertigstellung wird die Funktionalität einer selektierten Kundengruppe zur Verfügung gestellt und von denen ein qualitatives Feedback eingeholt. Wenn dabei Fehler auftreten oder das Feedback negativ ausfällt, können noch vor einem größeren Roll-out Korrekturen vorgenommen werden.

Es folgt die vierte Stufe, wenn das qualitative Feedback zufriedenstellend war bzw. Nachbesserungen erfolgt sind. Die Funktionalität wird allen Anwendern zur Verfügung gestellt und quantitative Metriken gesammelt. Während die Messungen laufen, wird mit der Arbeit an der nächsten Funktionalität gestartet, denn meist dauert die Erhebung der metriken etwas. Dann folgt eine Auswertung der Zahlen.
Die Kombination von qualitativem Feedback und quantitativen Metriken sorgt für eine gute Entscheidungsgrundlage. Nur, wenn die Funktionalität sich als förderlich für den zentralen Zielwert herausstellt, wird es dauerhaft in der Anwendung belassen. Ansonsten fliegt es konsequent raus.

Die folgende Präsentation stellt das Vorgehen von Ash Maurya dar:

How We Build Features

View more presentations from ashmaurya

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

Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

  • Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
  • Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
  • Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
  • Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

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

Englische Version des Artikels

Tipps zur Priorisierung des Product Backlogs von Mike Cohn

Product Backlog PriorisierungEine echte Perle zum Thema Priorisierung des Product Backlogs habe ich kürzlich bei Axel Heinz gefunden. Es handelt sich dabei um einen Vortrag von Mike Cohn (ich habe hier schon über sein Buch „User Stories Applied“ geschrieben). In diesem Vortrag stellt er nach einer Einführung in das Thema und dessen Bedeutung die vier Ansätze für die Priorisierung des Backlogs vor: Kano-Analyse, Theme-Screening, Theme-Scoring und relative Gewichtung.

Die Bedeutung guter Backlog-Pflege

Mike Cohn betont zunächst noch einmal die Bedeutung der Pflege des Backlogs. Er konnte in der Praxis zahlreiche Teams beobachten und die richtig guten Teams zeichneten sich alle dadurch aus, dass sie rund 10% ihrer Zeit in die Pflege des Product Backlogs stecken und diesen aktiv pflegen.
Das Stichwort lautet hier Backlog Grooming und kann zum Beispiel in Form von Workshops mit dem ganzen Team erfolgen.
Mike Cohn betont, dass es für Entscheidungen in der Backlog Priorisierung immer eine solide Grundlage geben sollte, wie etwa die Ergebnisse von Umfragen, aus Statistiken oder ähnliches. Statistisch signifikant braucht es für ihn nicht zu sein, aber z.B. das Feedback von 20-30 Anwendern im Rahmen einer Umfrage kann schon viel aussagen.
Nun aber zu den vier Maßnahmen, die er im folgenden vorstellt.

Kano-Analyse

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten in verschiedene Kategorien möglich ist:

  • Basisfaktoren: Basisfaktoren werden von den Anwendern als selbstverständlich vorausgesetzt. Werden sie erfüllt, entsteht keine Zufriedenheit, bei Nichterfüllung entsteht jedoch Unzufriedenheit.
  • Leistungsfaktoren: Diese wirken linear und ein mehr von dieser Funktionalität führt zu mehr Zufriedenheit der Anwender.
  • Begeisterungsfaktoren: Begeisterungsfaktoren werden vom Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, den seine Frau spitze fand, der 1993 noch keineswegs selbstverständlich war. So etwas kann sogar das „Zünglein an der Waage“ für eine Kaufentscheidung sein.

Manchmal ist es gerechtfertigt, darüber Schätzungen abzugeben, in welche Kategorie eine Funktionalität fällt. Noch sinnvoller ist meist jedoch die Befragung einer kleinen Gruppe von Anwendern, etwa 20-30 Stück.
Als Tipp für die Einplanung in das Produkt schlägt er vor, dass alle Basisfaktoren integriert werden, da sonst mit Unzufriedenheit gerechnet werden muss. Darüber hinaus sollten einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren eingeplant werden.

Weitere Informationsquellen für das Kano-Modell:

Theme-Screening

Das Vorgehen beim Theme-Screening erfolgt mit den folgenden Schritten:

  1. Identifiziere als erstes die Faktoren, die für die Priorisierung als Kriterien für das nächste Release herangezogen werden sollen. Zum Beispiel die Bedeutung für die bestehenden Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa 5-9 Kriterien sein.
  2. Nach der Festlegung der Priorisierungskriterien wird ein „baseline theme“ gewählt. Eine Story oder ein Theme, die im weiteren Vergleich als Basis für die relative Bewertung genutzt wird. Dafür eignen sich solche, die wahrscheinlich in das nächste Release aufgenommen werden und das allen Teammitgliedern vertraut und verständlich ist. Es sollte aber nicht das wichtigste Theme sein, da in diesem Fall alle weiteren Themes im Verhältnis schlechter abschneiden würden. Das gilt also analog zu Referenz-Stories beim relativen Beschätzen des Product Backlogs, wo meist eine mittelgroße oder eine eher kleinere Story als Vergleich genutzt wird.
  3. Alle Themes oder Stories, die zur Auswahl stehen, werden nun im Vergleich zum „baseline theme“ nach allen Kriterien bewertet. Für die schlechter abschneidenden Themes wird jeweils ein – eingetragen, für die besser abschneidenden ein + und für die gleich zu bewertenden Themes eine Null.

Mike Cohn stellt auf seiner Website sogar ein kleines Tool zum Theme-Screening bereit, das auch schnell das Vorgehen beim Theme-Screening verdeutlicht.

Weitere Informationsquellen für das Theme-Screening:

Theme-Scoring

Theme-Scoring ist dem Theme-Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Als erstes werden auch hier die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie einen Prozentwert, der sich zu 100% aufsummiert.

Als nächstes werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes bewertet auf einer Skala von 1-5, wobei 1 für eine schlechte Erfüllung des Kriteriums und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, als erstes für alle Kriterien ein Basis-Theme festzulegen, dass eine Bewertung von 3 erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.

Mike Cohn stellt auf seiner Website auch ein kleines Tool zum Theme-Scoring bereit.

relative Gewichtung

Die relative Gewichtung („relative weighting“) ist ein Priorisierungsansatz, bei dem sowohl die positive Auswirkung der Präsenz eines Features als auch die negative Auswirkung der Abwesenheit eines Features in die Beurteilung einbezogen wird. Für jede Funktionalität wird eine bewertung von 0 (gering) bis 9 (hoch) vorgenommen.

Die Themes werden dabei in die Reihen einer Tabelle eingetragen. Dann wird jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und der Strafe bei Abwesenheit hinterlegt. Zusätzlich wird noch ein Wert für den geschätzten Aufwand, etwa in Story Points oder auch einem Euro-Betrag, hinterlegt. Es werden also in diesem Fall die Kosten einer Funktionalität explizit mit berücksichtigt.
Es wird dann geschaut, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden durcheinander geteilt und es ergibt sich eine Priorisierungskennzahl.

Anteil am Gesamtnutzen Anteil an den Gesamtkosten Priorisierung
57% 67% 0.85
43% 33% 1.30

Das als zweites in diesem Fall aufgeführte Feature bringt zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger. Dadurch ist der Return on Investment (ROI) von letzterem größer.

Auf der Website Mike Cohn gibt es auch zur relativen Gewichtung ein kleines Tool.

Links zum Vortrag von Mike Cohn

Der Vortrag von Mike Cohn
Folien von Mike Cohn (PDF)

An dieser Stelle möchte ich auch noch auf eine Excel-Vorlage für die Product Backlog Priorisierung von Michael Romer hinweisen.

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

Englische Version des Artikels

Das Product Backlog Board

Diese Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, so dass sich jederzeit jedes Teammitglied und auch die Stakeholder darüber informieren können.
Wir haben seit einiger Zeit eine Grundversion eines Backlog Boards im Büro gehabt, nach einer Schulung von Roman in München wurden mir jedoch noch einige Punkte deutlich, die ich mit dem Team abgestimmt habe.

Der Aufbau eines Backlog Boards

Den grundlegenden Aufbau eines Backlog Boards erklärt Roman in seinem Artikel „The Product Backlog Board„. Die folgende Darstellung zeigt ein reduziertes Product Backlog Board, an dem wir uns bei unserem Board orientiert haben:

product-backlog-board

Das Product Backlog Board

Die zentralen Bereiche des Product Backlog Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird der Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte Userstories, auch Fehlermeldungen können dort vorgehalten werden.
Von den Stories sind dort drei verschiedene Granularitäten vorzufinden: Stories, Epics und Themes.

Fein zerteilte Stories, die fertig für eine Umsetzung sind, befinden sich oben im „ready items“-Bereich. Die feine Zergliederung und Fertigstellung von Stories werden dabei auf diejenigen fokussiert, die im nächsten Sprint für eine Umsetzung vorgesehen werden.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen der ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics stellen eine grobe Formulierung von Features dar, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung nahe rückt.
Im Bereich der „ready items“ ist eine Priorisierung durch den Product Owner Pflicht, während im Bereich der Themes & Epics nach Roman eine Priorisierung nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an das User Interface sowie operative Eigenschaften der Software festgehalten.
Das Produkt- und User Interface-Design kann in Form von Screens/Wireframes/Skribbles mit Anmerkungen zu den wichtigsten Vorgaben Vereinbarungen dargestellt werden.
Die operativen Eigenschaften können durch „Constraint Cards“ abgebildet werden, wobei pro Karte eine bestimmte operative Eigenschaft festgehalten wird. Das kann u.a. die Browser, für die optimiert werden soll, die Performance oder die Skalierbarkeit eines Softwareprodukts betreffen.
Die Constraints sollten mit der Definition of Done verknüpft werden, damit deren Einhaltung zum Bestandteil der Abnahme von jeder einzelnen Userstory wird. Das lässt sich gut am Beispiel der Browseroptimierung verdeutlichen. Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story somit nicht als „Done“.

[Anmerkung: Roman weist in seinem Beitrag über das Product Backlog Board noch eine „Model Area“ aus. Diese wurde im Rahmen der Schulung nicht behandelt und eignet sich auch für eine spätere Ergänzung.]

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog Grooming Workshops oder Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie. Für Teams mit 2-wöchigen Sprints schlägt Roman vor, wöchentlich 2 Stunden mit Backlog Grooming Workshops zu verbringen.
Wir hatten bisher weniger Zeit mit dem Grooming verbracht und haben die Workshops auch nicht zu einem festen Termin durchgeführt. Dies werden wir in Zukunft tun. Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich höher, wodurch auch sichergestellt wird, dass alle relevanten Aspekte einer Story besprochen werden.
In dem Workshop kann das Backlog Board auch direkt aktualisiert werden.

Mit diesem Setting werden wir in den nächsten Wochen erst einmal Erfahrungen sammeln. „Inspect and Adapt“. Die Reise mit Scrum bleibt spannend.

Weitere Artikel zur Product Backlog-Pflege:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

25 Blogs zu Scrum und agiler Softwareentwicklung

Welche Blogs zu Scrum und agile Softwareentwicklung solltet ihr nicht verpassen? Vor einiger Zeit habe ich meine persönlichen Top 5 Scrum-Blogs vorgestellt. Agile Office fragte in einem Kommentar, welche weiteren Blogs ich zu dem Thema lese.
Nachfolgend daher eine umfangreichere Liste von 25 Blogs zu Scrum und agiler Softwareentwicklung:

  1. „Scrum Log“ von Jeff Sutherland: Der „Vater von Scrum“ schreibt seit 2002 über alles rund um Scrum, von „Dealing with Bugs in a Sprint“ bis zu „Hackathons – How it’s done at Facebook“
  2. „Telling It Like It Is“ von Ken Schwaber: Der Mitbegründer von Scrum und Gründer von Scrum.org schreibt regelmäßig über seine Sicht auf die Entwicklungen in der Scrum Community.
  3. ScrumAlliance Articles: Hier gibt es Artikel von vielen erfahrenen Scrum Trainern und Professionals.
  4. „bor!sgloger — leading Scrum with passion“ von Boris Gloger: Einer der bekanntesten Scrum-Trainer aus Deutschland versorgt uns regelmäßig mit aktuellen Tipps und Tricks rund um agile Softwareentwicklung.
  5. „All Things Product Owner“ von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board.
  6. „Lean und Kanban“ von Arne Roock: Der Prokurist bei it-agile und Träger eines schwarzen Gürtels in Karate schreibt einen der wenigen deutschen Blogs über Kanban in der Softwareentwicklung.
  7. „Dayley Agile“ von Alan Dayley: Ein Softwareentwickler, der seit vielen Jahren auf agile Softwareentwicklung schwört und seine Erfahrungen mit uns teilt.
  8. Implementing Scrum von Michael Vizdos: Der Scrum-Trainer berichtet von seinen Erlebnissen, Tony Clark liefert ihm herausragende Illustrationen dazu. Sehr sehenswert.
  9. „inside-scrum“ von Jean-Pierre: Ein Anwenderbericht vom Start und der Durchführung eines Scrum-Projekts.
  10. Agile Product Design: Agile Softwareentwicklung betrachtet aus dem Blickwinkel des Product Designs, eine längere Zeit schon still, aber mit sehr interessanten Artikeln.
  11. Peter Beck: Scrum-Trainer von DasScrumTeam. Zuletzt leider etwas ruhig geworden.
  12. „scrum breakfast“: Die Selbstbeschreibung drückt es am besten aus: „Blog about Scrum: getting started, crisis project management and transforming into a lean organization.“
  13. ScrumEdge: Ein weiteres Scrum-Blog, das durch eine hohe Frequenz von guten Artikeln überzeugt.
  14. „Agile Product Owner“ von Jennifer: Die Eigenbeschreibung „Sharing the Art of Agile Product Ownership“ trifft es auf den Punkt. Zuletzt ist es in dem Blog leider eher ruhig geworden.
  15. ScrumCenter: Der Corporate Blog eines agilen Beratungsunternehmens. Viele Inhalte von Präsentationen werden behandelt, aber auch auf interessante Artikel verwiesen.
  16. Scrumology von David Bland: Entgegen dem Namen geht es nicht nur um Scrum, sondern auch um Kanban und „schlanke“ Softwareentwicklung. David teilt seine Erfahrungen aus der Praxis.
  17. Stefan Roock: Der Trainer für agile Softwareentwicklung berichtet über seine Erlebnisse und Erfahrungen aus seiner Beratungstätigkeit.
  18. The Agile Executive von Israel Gat: Dieser Blog beschäftigt sich mit dem Rollout von „Agile“ auf Unternehmensebene, also über einzelne Teams hinweg.
  19. The Agilista PM von Donna Reed: Mit Fachartikeln, Webinaren und Webcasts werden hier Aspekte des agilen Projektmanagements behandelt.
  20. Scaling software agility: Wie lässt sich agile Softwareentwicklung in großen Projekten einsetzen? Hier gibt es Antworten.
  21. PM-Blog von Stefan Hagen: Obwohl sein Blog nicht ausdrücklich auf agile und schlanke Vorgehensweisen fokussiert, ist ihm dieses Faible von Stefan anzumerken.
  22. „ScrumTools – agiles Projektmanagement“: Neben einer Liste von Scrum-Tools gibt es von Zeit zu Zeit Artikel im zugehörigen Blog.
  23. agileoffice: Agile, Lean und Scrum sind die Themen, mit denen sich dieses Blog beschäftigt.
  24. „Systems Thinking, Lean and Kanban“ von David Joyce: David teilt seine langjährigen Erfahrungen als Coach und Teammember und verweist regelmäßig auf spannende Artikel.
  25. „Lean Software Engineering“ von Corey Ladas und Bernie Thompson: Die beiden teilen ihre Erfahrungen aus Teams von u.a. Microsoft und IBM. Ihre Artikel bekommen hohe Aufmerksamkeit und sorgen regelmäßig für umfangreiche Diskussionen.
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 Rafa[EU]

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

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.
%d Bloggern gefällt das: