Projektschneidung und Backlog (MVP)

Vorbereitung und Zuarbeit zum Umsetzungsprojekts und Übertrag der in der Visionsphase erarbeiteten Konzepte in Ticketform hin zu einem ersten belastbaren Projektbacklog.

Beschreibung der Methode

Worum geht es?

Generell arbeiten wir in allen Projekten auf Ticketbasis in Jira. Und selbst wenn nicht jedes Projekt in agilen Sprints organisiert wird, besteht seitens Kreation oft die Anforderung aus den in der Visionsphase oder anderen kreativen Vorarbeiten die sich ergebenden Projektaufgaben zumindest anteilig (also in Ergänzung durch die anderen Fachbereiche FE/BE/PM) sinnvolle Umsetzungstodos zu formulieren.

Diese Arbeit ist unterstützend für den (Proxy-) Product Owner zu sehen, in der Projektpraxis erstellt die Kreation jedoch oft einen maßgeblichen Anteil des konkreten Projekt Backlogs und wird auch im späteren Projektprozess dazu konsultiert.

Worin liegt der Nutzen für das Projekt?

Als Kreation erarbeiten wir oft die ersten frühen Projektkonzepte und kennen durch die verschiedenen Workshops und Kreationsarbeiten im Rahmen der Visionsphase die Projektidee am besten.

Deshalb kann seitens Kreation zumindest im Sinne von “Welche Discoveries brauchen wir, welche Basics, Globals, Module etc. brauchen wir” am besten zuarbeiten. Für eine schrittweise Konkretisierung der Vision hin zum echten Projekt werden diese in Tickethülsen im Jira-Backlog gesammelt und in Epics vororganisiert.

Gemeinsam mit dem (Proxy-) PO und den jeweiligen Verantwortlichen aus Front- und Backend kann so ein belastbares Projektbacklog erstellt werden. Dieses wird dann mit dem Kunden durchgesprochen und im Rahmen eines MVP/Planings-Workshops priorisiert und in Sprints verteilt.

Gibt es Abhängigkeiten?

Die gesamte Vorarbeit in der Visions- oder verkürzt Vorphase liefert die notwendigen Vordefinitionen, die in diesem Schritt “nur noch” zu einem greifbaren Backlog zusammengeführt werden. Somit sind alle Vorarbeiten hier relevant.

Natürlich ist die Vollständigkeit eines Projekt-Backlogs auch maßgeblich von der Zuarbeit aller beteiligter Fachbereiche abhängig…:

  • Kreation (Visionsergebnisse, kreative Discoveries, Content Konzepte, Basics, Globals, Modulshapings…)

  • Frontend Development / Setup (PatternLab, Umsetzung Atomic Design Elemente…)

  • Backend Development / SetupCMS Aufsetzen, Übertrag Design System in’s CMS, Pflege & Schnittstellen etc…)

  • SEO / Online Marketing (Technisches SEO, Metadaten, auch Trackingkonzepte & GAnalytics…)

  • Product Ownership / Projekt Management (Controlling, Termine, Planungsmeetings, Retrospektiven…)

  • Content / Contentpflege (Pflegeassets, Daten-Schnittstellen, Contentkonzepte, Übersetzungen…)

  • Hosting / Livegang (Server & Wartung, Dev/Live Systeme, Livegangchecklisten…)

Achtung, diese Liste ist beispielhaft und weder vollständig noch zwingend trennscharf korrekt. Die Verantwortung zur Vollständigkeit des Backlogs liegt letzten Endes beim Product Owner, mit fachlicher Unterstützung durch die Fachbereiche/Leads.

Zielbeschreibung

Was soll an Erkenntnis erarbeitet werden?

Ziel ist ein möglichst früh schon vollständiges Projekt-Backlog, das unter Zuarbeit aller Fachbereiche einen Ausblick auf die insgesamt umzusetzenden Teilaufgaben liefert und damit eine Projektplanung (MVP, Sprints) durch den Product Owner ermöglicht.Die erstellten Tickets müssen noch nicht inhaltlich geshapet sein, dies kann sukszssive in den jeweiligen Sprints geschehen. Zum Start der Umsetzungsphase sollten nur die Tickets für den ersten Sprint bereits definiert und mit Anweisungen/User Stories geshapet sein.

Dieser Projektschritt ist erledigt sobald ein erfolgreiches MVP-/ Sprintplanning durchgeführt wurde und der Vor-Sprint (oder auch “Sprint 0”) starten kann (bedeutet hier: die Tickets des ersten Sprints können geshapet werden).

Wofür ist das wichtig?

Ein vollständiges Projektbacklog ist nicht nur bei agilen Projekten wichtig, in dieser Form evaluieren wir generell Projekte die über mehrere Teilaufgaben in den unterschiedlichsten Fachbereichen bearbeitet werden. Da selbst bei agilen Projekten immer auch Scope, Budget und Timing in gewissem Rahmen einzuhalten sind (reelle Erwartungshaltung Kunden) muß auch in agilen Projekten der Projektscope (das Backlog) früh beurteilt und geplant werden können.Bei der Sprintplanung sollte gemäß Budget und Projektinhalte planbar sein, in welchen Sprints welche Fachlichkeiten involviert sind und dadurch absehbar sein, wie viele Sprints benötigt werden.All das kann nur gelingen wenn das Backlog zumindest in grob identifizierten Teilaufgaben / Tickethülsen umschrieben ist. Im späteren Projektverlauf liefert die Visionsphase immer wieder konkrete Handlungsimpulse und Vorkonzepte für die Umsetzung.

Vorgehensweise

Welche Vorarbeiten sind notwendig?

Die Visionsphase an sich muß abgeschlossen sein und darauf basierend für alle Beteiligten ein gemeinsames Gefühl für das konkrete Projekt entstanden sein. Die Visionsphase wurde in den relevanten Ergebnissen dokumentiert und seitens PO/Kunde freigegeben. Für die nun folgende Umsetzungsphase können hieraus konkrete Tickets / User Stories / Discoveries abgeleitet werden.

Der praktisch gleichzeitige Planungsprozess mit MVP Workshop konkretisiert dazu passend Timings und First-Steps.

Wie wird der Inhalt erarbeitet?

Die Fachbereiche erstellen ihre Tickethülsen im vom PM erstellten leeren Jira Board (oder i nein bestehendes hinein, was aber nur bei kleinen Projekten so sinnvoll ist).

Dabei sollten in den zunächst noch leeren Tickethülsen zumindest folgende Informationen definiert werden:

  • Ticketname - sprechend und idealerweise gemäß unserer bestehenden Bezeichnungsregel, z.B. “DISCOVERY | [name der Discovery]” oder “BASICS | Typografie” etc.

  • Übergeordnetes EPIC – auch hier haben wir bereits Standardbezeichnungen, die aber je Projekt variieren und ergänzt werden können, z.B. “SETUP”, “BASICS”, “GLOBALS”, “MODULE” etc. Tickets sollten Epics zugewiesen werden

  • IDEAL: Ticketbeschreibungs-Hülse, z.B. für Discoveries, Module und Content Konzepte. Diese werden im Projekt durch echte User Stories bzw. Konzeptdokumentationen/Shapings ersetzt.

  • Optional: Vorverteilung in Sprints bzw. sinnvolle Vorsortierung. Konkrete Planung erfolgt später in den jeweiligen Plannings bzw. grob schon im MVP Workshop.

Wann macht ein Kundenworkshop Sinn? 

Spätestens der MVP Workshop ist der abschließende Termin zur gemeinsamen Sammlung, Vervollständigung, Priorisierung und Freigabe des Backlog. Dieser Workshop sollte mit Kunde sowie den Projektinvolvierten Fachbereichen gemeinsam stattfinden. Hier werden alle Tickets gemeinsam durchbesprochen und zusätzliche Anpassungen für den Start Richtung Sprint 1 vorgenommen. Auch wenn im agilen Mindset der Projektscope variabel ist, sollte das MVP gemeinsam im Backlog behandelt und geplant werden.

Ist diese Methode ein Pflichtinhalt für Projekt-Visionsphasen?

In dieser oder vereinfachter Form ja. Im Grunde ist dieser Projektschritt die gemeinsame Definition der Umsetzungsaufgaben für ein zuvor konzipiertes / gebrieftes Projekt in Ticketform. hier sollte so weit wie möglich auf Vollständigkeit und eine korrekte Priorisierung geachtet werden – Nachzügleraufgaben sind im agilen Kontext möglich, bedeuten aber auch immer Umplanungen und nicht zuletzt auch, dass andere Aufgaben aus dem MVP fallen könnten.