Erstellen von Produkt-Backlogs

Erstellen Sie Ihr Produkt-Backlog mithilfe der Best Practices von Pega, einschließlich Direct Capture of Objectives (DCO).

Die Pega-Lösung beruht auf zwei Grundkonzepten: der Journey und der Microjourney.

• Die Journey beschreibt die Interaktion des Kunden mit dem Unternehmen, um ein bestimmtes Ziel zu verfolgen.
• Die Microjourney beschreibt die Interaktionen eines bestimmten Kundentyps über einen bestimmten Kommunikationskanal, um dieses Ziel zu erreichen.

Sie beginnen den Prozess der Lösungsdefinition, indem Sie Ihr „Minimum Loveable Product“ identifizieren …

… die einfachste Methode, um Ihren Kunden zu begeistern.

Dieses MLP besteht aus einer oder mehreren Microjourneys.

Der erste Schritt bei der Lösungsentwicklung besteht darin, die von der Lösung unterstützten Microjourneys zu identifizieren.

Für jede Journey besteht die Lösung aus einem einfachen Entwicklungsprozess:

• Identifizierung des Kundenziels der Journey
• Identifizierung der Personas, die das Ziel wünschen
• Identifizierung der Channels, über die die Personas das Ziel erreichen
• Erstellung einer Matrix mit den gültigen Kombinationen dieser Informationen

Wenn Sie mit dem Case-Typ „Backlog“ arbeiten, finden Sie diese Informationen auf dem Tab „Work Backlog“ (hier abgebildet).

Wenn Sie mit Pega Infinity arbeiten, sind die Microjourneys und die zugehörigen Informationen möglicherweise bereits im Tool gespeichert.

Im folgenden Beispiel wollen wir zwei Journeys in Microjourneys aufgliedern.

Ihr Kunde teilt Ihnen mit, dass er nach einer Lösung sucht, um seinen Endkunden die folgende Möglichkeit zu bieten:

• Aufnahme einer Ersthypothek
  und
• Refinanzierung des Hypothekendarlehens

Im Gespräch mit Ihrem Kunden erfahren Sie, welche Personas und Channels für die einzelnen Journeys definiert sind.

Durch Gespräche mit dem Produkt-Owner – und ggf. weiteren Fachgebietsexperten aus dem Unternehmen – finden Sie heraus, welche Personas welche Channels bei einer bestimmten Journey nutzen.

Erstellen Sie anhand der Informationen eine Matrix wie die hier abgebildete. Jede Zeile definiert eine Microjourney.

Der zweite Schritt bei der Lösungsentwicklung besteht darin, die identifizierten Microjourneys zu priorisieren.

Die Priorität einer Microjourney spiegelt drei Attribute wider:

• Business Value der Microjourney
  • Hierbei geht es um den geschäftlichen Nutzen, der mit der Bereitstellung des Kundenziels über einen bestimmten Channel an eine Persona verbunden ist.
  • Diesen Wert werden Sie wahrscheinlich durch Gespräche mit dem Produkt-Owner ermitteln.
• Voraussichtliche Schwierigkeiten bei der Implementierung der Microjourney
  • Diesen Wert werden Sie wahrscheinlich durch Gespräche mit dem Lead System Architect (LSA) oder einem anderen leitenden technischen Mitarbeiter Ihres Projekts ermitteln.
• Abschätzung des Aufwands für die Implementierung der Microjourney
  • Diesen Wert werden Sie wahrscheinlich ebenfalls durch Gespräche mit dem LSA oder einem anderen leitenden technischen Mitarbeiter ermitteln.

Anhand des geschäftlichen Nutzen einer Microjourney und der erwarteten Implementierungsfreundlichkeit – der Kombination aus Schwierigkeit und Aufwand – bestimmen Sie die Priorität einer Microjourney.

Bei der Zuweisung von Prioritäten werden die Microjourneys einer von vier Gruppen zugeordnet:

• Die erste Gruppe umfasst die Microjourneys mit einem höheren geschäftlichen Nutzen und einer höheren Implementierungsfreundlichkeit.
  • Diese Komponenten haben die höchste Priorität, da sie in der Regel den größten Nutzen innerhalb der kürzesten Zeit liefern.
  • Somit sind diese Komponenten die Hauptkandidaten für das erste MLP-Release.
• In die zweite Gruppe werden Microjourneys mit einem höheren geschäftlichen Nutzen und einer geringeren Implementierungsfreundlichkeit eingeordnet.
  • Diese Komponenten sind von mittlerer Priorität, da sie trotz ihrer im Vergleich zur ersten Gruppe schwierigeren Implementierung einen hohen geschäftlichen Nutzen liefern.
  • Auch wenn sie gewöhnlich nicht Teil des ersten MLP-Release sind, so werden doch viele dieser Microjourneys in die unmittelbar nachfolgenden Releases aufgenommen.
• Die dritte Gruppe bilden Microjourneys mit einem geringeren geschäftlichen Nutzen und einer höheren Implementierungsfreundlichkeit.
  • Diese Microjourneys sind von niedriger Priorität, da sie nur einen geringen geschäftlichen Nutzen bieten.
  • Da der geringere Nutzen aber durch die Tatsache ausgeglichen werden kann, dass für die Implementierung weniger Ressourcen benötigt werden, kommt es dennoch häufig vor, dass diese Microjourneys implementiert werden.
• Die letzte Gruppe besteht aus den Microjourneys mit einem geringeren geschäftlichen Nutzen und einer geringeren Implementierungsfreundlichkeit.
  • Diese Microjourneys werden praktisch nie implementiert, weil der geschäftliche Nutzen nicht groß genug ist, um ihre hohen Implementierungskosten zu rechtfertigen.

Der letzte Schritt bei der Definition Ihrer Lösung mit Microjourneys besteht darin, die Microjourneys in MLP-Releases einzugruppieren.

Das erste MLP-Release besteht in der Regel aus Microjourneys mit einem höheren geschäftlichen Nutzen und einer höheren Implementierungsfreundlichkeit.

Kann diese Microjourney-Gruppe vor dem angestrebtem Release-Termin implementiert werden, empfiehlt es sich, das Release früher bereitzustellen anstatt es weiter zu verbessern. Das Ziel ist es, baldmöglichst einen echten Mehrwert zu schaffen, und das geschieht durch Microjourneys, die sich durch einen hohen geschäftlichen Nutzen und eine einfache Implementierung auszeichnen.

Falls nicht damit zu rechnen ist, dass alle Microjourneys hoher Priorität bis zum vorgesehenen Release-Termin implementiert werden können, gehen Sie bei der Definition des Inhalts für MLP1 so vor, dass Sie oben in der Liste mit den priorisierten Microjourneys beginnen und so viele Microjourneys aufnehmen, wie in der verfügbaren Zeit implementiert werden können.

Die übrigen Microjourneys hoher Priorität, die in MLP1 nicht berücksichtigt wurden, können Sie – vielleicht schon kurz nach dem ersten Release – in eines der nächsten Releases aufnehmen.

Für einfache Lösungen können Microjourneys in der Regel direkt in Pega implementiert werden. Bei kleinem Projektumfang kann oft auf ein Produkt-Backlog verzichtet werden.

Bei anderen Projekten ist es wiederum erforderlich, die Microjourneys für das Bereitstellungsteam in ein Projekt-Backlog zu übertragen.

Im Allgemeinen ist ein Produkt-Backlog erforderlich, wenn das Projekt eine der folgenden Eigenschaften aufweist:

• Die Bereitstellung erfolgt in mehreren Releases.
• Das Projekt bezieht sich auf ein stark reguliertes Unternehmen.

Für Projekte wie diese muss ein Backlog angelegt werden, weil die Organisation recht aufwendig ist. Das Dokumentieren und Priorisieren der Geschäftsanforderungen, das Verwalten der Arbeitsschritte über mehrere Releases und Teams hinweg, das Bereitstellen unterstützender Artefakte zur Erfüllung der Auditvorgaben … dies alles erfordert mehr Organisation als der prototypenbasierte Ansatz leisten kann, der zur Implementierung einfacher Lösungen verwendet wird. Der Produkt-Backlog ist die Scrum-Antwort auf die Anforderungen dieser komplexeren Projekte.

Der erste Schritt beim Anlegen eines Produkt-Backlog besteht darin, im Agile Studio ein Produkt und ein Release für MLP1 zu erstellen.

Hierbei wird automatisch ein Standard-Backlog für das Release angelegt.

In den folgenden Beispielen verwenden wir zwar das Agile Studio, aber Pega kann auch mit anderen Tools für das agile Projektmanagement wie JIRA oder Team Foundation Server kommunizieren, um Ihre Lösung bereitzustellen.

Nachdem Sie nun Ihr Produkt-Backlog erstellt haben, besteht der nächste Schritt darin, Ihre Journeys in der Agile Workbench und im Agile Studio zu speichern.

In der Agile Workbench wird eine Journey als Top-Level-Feature gespeichert – „Top-Level“ deshalb, weil Sie Features einbetten können. Eine Journey bildet die oberste Ebene der Hierarchie.

Im Agile Studio speichern Sie die Journey als Ziel innerhalb des Produkts, das Sie soeben erstellt haben.

Nachdem Sie Ihre Journeys in beiden Tools gespeichert haben, ist es an der Zeit, Ihre Microjourneys zu speichern.

In der Agile Workbench wird eine Microjourney als Feature der zweiten Ebene gespeichert und damit dem Top-Level-Feature – der übergeordneten Journey – untergeordnet.

Im Agile Studio wird jede Microjourney als „Epic“ unter dem Ziel gespeichert, das die übergeordnete Journey darstellt.

Als letzten Schritt in diesem Prozess erstellen Sie die User Storys für die Implementierung der Microjourneys, die Sie bislang identifiziert haben.

Diese Storys werden üblicherweise in der Agile Workbench erstellt.

Eine mit der Agile Workbench erstellte User Story wird automatisch in Echtzeit mit dem Agile Studio synchronisiert. Umgekehrt gilt das Gleiche. Somit sind die Agile Workbench und das Agile Studio bei den User Storys immer synchron.

Nun haben Sie alle Vorbereitungen getroffen und können User Storys erfassen. Wie gehen Sie dazu vor?

Bei der journeybasierten Bereitstellungsmethode von Pega ist DCO (Direct Capture of Objectives) die bevorzugte Methode zur Erfassung und Ausarbeitung von User Storys.

Mit DCO können Geschäftsergebnisse direkt und visuell erfasst werden. Gleichzeitig wird die Zusammenarbeit zwischen Business und IT verbessert, um diese Ergebnisse zu erreichen.

Features oder User Storys werden gemeinsam von Business- und IT-Experten erörtert und noch während des Gesprächs oder unmittelbar danach wird direkt in Pega eine erste Version der Funktion erstellt.

DCO bedeutet nicht, dass Sie einfach Anforderungen in der Pega-Anwendung speichern.

DCO ist eine Technik zur Ausarbeitung von Storys, die es Ihnen ermöglicht, innerhalb kürzerer Zeit bessere Lösungen zu liefern.

Es ist ein modellbasierter Ansatz, bei dem Sie in der Pega-Plattform iterativ und schrittweise Lösungen entwickeln.

DCO ist auch ein Mindset, dessen Fokus darauf liegt, mit jeder Microjourney einen geschäftlichen Vorteil zu generieren, ohne die Roadmap des Unternehmens aus dem Auge zu verlieren.

DCO ist ein ausgesprochen kollaborativer Prozess, an dem viele Rollen mitwirken können.

Vom Projektteam:

• Der Produkt-Owner ist hauptsächlich dafür verantwortlich, Informationen zu den einzelnen Storys zu liefern und ihre Priorität festzulegen.
• Der Business Architect hat die Aufgabe, jede Story zu dokumentieren. Er moderiert normalerweise die DCO-Sitzungen.
• Der System Architect muss die geschäftlichen Anforderungen hinter jeder Story verstehen, damit die Story angemessen implementiert werden kann.

Vom Rest des Unternehmens:

• Fachgebietsexperten liefern Zusatzinformationen zu einigen Storys – oft in Form von bestimmten Details über Geschäftsprozesse, die sie besonders gut kennen.
• Der Test Lead muss die geschäftlichen und technischen Aspekte jeder Story verstehen, damit er das Testteam beim Entwickeln der entsprechenden Testszenarios unterstützen kann.
• Der IT Architect liefert Hintergrundinformationen und Risikoanalysen bezüglich der Integration der einzelnen Storys in das IT-Ökosystem des Unternehmens.

DCO ist keine Momentaufnahme. Es ist eine Technik, die Sie zwischen dem Projektstart und dem Release Ihrer Lösung häufig nutzen werden.

Während der Prepare-Phase (den vor Projektstart zu erledigenden Vorbereitungen) verwenden Sie DCO, um zwei Sprints mit User Storys zu erarbeiten. Dadurch wird sichergestellt, dass das Bereitstellungsteam genug Arbeit hat und direkt vom Projektstart an beschäftigt ist.

Während der Build-Phase setzen Sie DCO ein, um User Storys auszuarbeiten, die in die nachfolgenden Sprints implementiert werden.

Außerdem verwenden Sie DCO, um Feedback zum aktuellen Release einzuholen.

DCO ist kein Tool. Das DCO-Konzept wird aber von zahlreichen Tools im Pega-Ökosystem unterstützt.

Im App Studio können Sie die Vision einer Lösung als ausführbares Modell entwickeln. Ab der ersten DCO-Sitzung können Ihre Kunden das Gerüst der Lösung sehen. Sie können mitverfolgen, wie die Lösung immer mehr Gestalt annimmt und eine Anwendung entsteht, mit der sie von Anfang an interagieren können.

Im Integration Designer können Sie den Datenbedarf und den Status der Integrationspunkte für die Daten ermitteln. Außerdem können Sie in diesem Tool Datentypen von Geschäftseinheiten definieren, die Datenansichten, in denen sie angezeigt werden, und die zugehörigen Aufzeichnungssysteme festlegen sowie die entsprechenden Berichte erstellen.

Mit der Agile Workbench können Sie bei Überprüfungen und Demonstrationen direkt in den Pega-Studios Storys, Fehler und Feedback erfassen. Neue Storys werden automatisch mit den Tools für das agile Projektmanagement wie Agile Studio synchronisiert.

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.