Vorausschauend ist besser als rückblickend. Wie wir die MVP-Projektierung durchführen.

Und jetzt kommt der knifflige Teil. Nachdem wir das Was und das Wie durch Product discovery und Technische Schätzungen geklärt haben, ist es an der Zeit, die Dinge ins rechte Licht zu rücken. Das Ziel der Projektplanung ist es, eine verlässliche Roadmap zu erstellen, von der Priorisierung der Funktionen und der Einteilung in Aufgaben und Sprints bis hin zu den tatsächlichen Meilensteinen und dem Projektzeitplan.

Genau wie Karma, beginnt alles mit einem Backlog.

Betrachten Sie das Backlog als die ultimative To-Do-Liste. Es enthält alles, was Sie während des Projekts tun sollten. Oder, anders ausgedrückt, alles, was die App können sollte, wie in User Stories und Wireframes dokumentiert und in der technischen Lösung vereinbart.

Wir betrachten das Backlog gerne als die einzige Quelle der Wahrheit, wenn es um die Dinge geht, mit denen das Team Zeit verbringen wird. Und da die Wahrheit nie veraltet, sollte das Backlog auch nicht veraltet sein. Wir widmen einen großen Teil der Projektplanungszeit nicht nur der Erstellung des Backlogs, sondern auch der Pflege desselben. Dieser Prozess wird "Backlog Grooming" genannt und findet in der Regel kontinuierlich im Hintergrund statt, da Aufgaben herausgezogen und in Sprints und Sprint Backlogs organisiert werden. Das Ziel ist es, am Anfang des Backlogs immer mindestens eine Arbeit im Wert eines Sprints zu haben, die klar umrissen und in kleinen, überschaubaren Teilen organisiert ist.

Vom Product Backlog zu häppchenweisen Aufgaben und Sprints

Ein Sprint ist ein festgelegter Zeitrahmen, irgendwo zwischen einer und vier Wochen - wir entscheiden die Länge eines Sprints basierend auf der Komplexität des Projekts. Am Ende eines Sprints sollten wir ein Ergebnis haben, das wir in zukünftigen Sprints testen und verbessern können.

Vor jedem Sprint trifft sich das Team, um die Sprintplanung durchzuführen. Dies beinhaltet das Durchgehen der riesigen, anfänglichen To-Do-Liste (auch bekannt als Product Backlog) und deren Priorisierung. Es gibt eine Menge Dinge, die beeinflussen können, wie Funktionen und folglich Aufgaben priorisiert werden, aber einige der häufigsten sind:

Implementierungsschwierigkeiten
Zeit- und Kostenüberlegungen
Dringlichkeit, Feedback zu erhalten
Abhängigkeiten (B braucht A, um zu funktionieren; B ist einfacher, wenn wir zuerst A machen usw.)

Wir verwenden die MoSCoW-Methode, um die Funktionen und, darauf basierend, die Aufgaben zu priorisieren.

Neben der Priorisierung von Funktionen und Aufgaben bedeutet Sprint-Planung auch sicherzustellen, dass die Aufgaben an der Spitze des Backlogs immer klar definiert und von allen verstanden werden. Das kann bedeuten, große Aufgaben in kleinere Teilaufgaben aufzuteilen oder neue Aufgaben hinzuzufügen, wenn Sie Lücken im Ablauf entdecken. Während der Sprintplanung werden Aufgaben aus dem Product Backlog herausgezogen und das Team verpflichtet sich, sie bis zum Ende des Sprints zu erledigen.

Der Fortschritt steht in den Karten. Buchstäblich.

Die meisten Projektverfolgungsprogramme ermöglichen die Organisation von Projekten in Form von Sprint Boards. Wir haben im Laufe der Jahre mit einigen gearbeitet, von Asana über Jira bis hin zu ClickUp. Ein Sprint Board ist eine visuelle Möglichkeit, den Fortschritt mit Hilfe von Spalten und Karten zu verfolgen.

Im einfachsten Fall kann ein Sprint Board mit vier Spalten dargestellt werden:

To Do - im Grunde das Gleiche wie das Sprint Backlog
In Arbeit - Aufgaben, an denen das Team derzeit arbeitet
QA - Aufgaben, die Tests beinhalten. Testkarten geben an, wie die Aufgabe getestet wird
Erledigt - Erledigte Aufgaben, die am Ende des Sprints vom Board entfernt werden

Wenn den Teammitgliedern Aufgaben aus dem Sprint-Backlog zugewiesen werden und sie daran arbeiten, bewegen sich die Karten durch die Spalten, um den Fortschritt bei jeder Aufgabe anzuzeigen. Während der täglichen Stand-up-Meetings berichtet jeder, woran er arbeitet, woran er arbeiten wird und was ihm bei der Erledigung einer bestimmten Aufgabe im Weg steht. Die Teammitglieder aktualisieren das Board kontinuierlich während des Sprints.

Eine Karte sollte eine einfache Frage beantworten und Entwicklern so viele Ressourcen wie möglich zur Verfügung stellen, um sie zu beantworten: "Weiß ich und habe ich alles, was ich brauche, um diese Aufgabe zu erledigen?". Diese Ressourcen umfassen in der Regel Erkenntnisse aus den beiden vorangegangenen Phasen des Entwicklungslebenszyklus (Produktentwicklung und Technische Schätzungen & Lösung) und können der Karte hinzugefügt werden, um eine vollständige Perspektive zu erhalten:

User Stories (liefern den Kontext: für wen bauen wir das? Was ist das Endziel aus einem nicht-technischen Blickwinkel?). Manchmal können die Backlog-Aufgaben selbst als Benutzererfahrungen mit dem Produkt geschrieben werden: "Als < Benutzertyp > möchte ich < Ziel >, erreichen".
Wireframes oder das aktuelle Design der Screens, die das Feature enthalten (nützliche visuelle Erinnerung für Entwickler).
Code-Schnipsel, technische Spezifikationen und andere Ressourcen.
Eine Zeitschätzung, wie viel Arbeit die Implementierung der Funktionalität erfordert.

Einen Sprint zu Ende bringen. Und sich darauf vorbereiten, alles noch einmal zu machen.

Am Ende eines jeden Sprints werden üblicherweise zwei Meetings einberufen. Eines mit dem Entwicklungsteam und den Stakeholdern (das Sprint-Review) und eines mit dem Entwicklungsteam allein (die Sprint-Retrospektive).

Der Sinn des Sprint-Reviews ist es, dem Kunden zu zeigen, woran das Entwicklungsteam gearbeitet hat, und ihm nützliches Feedback zu geben. Der Kunde bekommt die Chance zu sehen, was seit dem letzten Sprint-Review neu ist, mit der App zu interagieren und zu sehen, ob irgendwelche Funktionen falsch oder gar nicht kommuniziert worden sind.

Während UAT-Tests (User Acceptance Tests) in der Regel erst durchgeführt werden, wenn alle Funktionen implementiert sind, verwenden wir Sprint-Reviews als eine vorläufige Form von UAT-Tests. Oder zumindest das, was einem Praxistest am nächsten kommt. Das Team nutzt dann das Feedback des Kunden, um neue Aufgaben hinzuzufügen, Fehler zu beheben und das Backlog für den nächsten Sprint neu zu priorisieren.

Das zweite Meeting, die Sprint-Retrospektive, wird intern mit dem Entwicklungsteam abgehalten. Wir nutzen dieses Meeting, um zu sehen, welche Anpassungen am Prozess vorgenommen werden müssen und ob es etwas gibt, das wir in die nächsten Sprints einbauen müssen. Zu diesem Zweck haben wir eine super hilfreiche Liste mit Fragen erstellt:

Projektmanagement (Wie gut waren die Aufgaben verteilt? Wie gut wurden die Dailys und Scrum-Meetings geplant und durchgeführt?)
Spezifikationen (Sind alle Funktionalitäten klar definiert?)
Testen (Wie wurde in jedem Sprint getestet?)
Schätzungen und Fristen (Wie genau war die ursprüngliche Schätzung?)

Dieser Zyklus wird wiederholt, bis das MVP bereit ist, auf Live-Servern eingesetzt zu werden. Idealerweise sollten nach dem Launch regelmäßig kleine inkrementelle Verbesserungen nach ein oder zwei Sprints gepusht werden.

Gantt wurde gerade agil

Gantt-Diagramme sind eine großartige Möglichkeit zur Visualisierung von Projektzeitplänen. Wir bringen Gantt-Diagramme in unsere agile Projektplanung ein, um den Status von wichtigen Meilensteinen zu verfolgen und Aufgaben zu bemerken, die Fristen verlängern.

Nur ein unerfahrener Projektmanager handelt in absoluten Zahlen. Anstatt sich also auf Waterfall versus Agile oder Big Launch versus Continuous Development zu konzentrieren, träumen wir groß und gehen dann in kleinen Schritten vor. Wir fanden diesen Ansatz besonders nützlich für MVPs und Start-ups. Zum Beispiel brauchen Gründer normalerweise ein hohes Maß an Vorhersagbarkeit, wenn sie sich mit Investoren treffen. Für sie ist es entscheidend, innerhalb eines klar definierten Zeitrahmens ein funktionsfähiges Produkt auf den Markt zu bringen, vor allem wenn ihr Start-up eine kurze Anlaufzeit hat. Aber es ist ebenso wahr, dass Gründer viel von der Flexibilität der Sprint-Planung profitieren können, während sie Erkenntnisse sammeln und ihr MVP reift. Warum also nicht früh mit beidem beginnen?

Bereit anzufangen?

Wenn Sie ein Start-up sind, das einen technischen Partner für die Fahrt sucht, suchen Sie nicht weiter. Wir sind darauf spezialisiert, Start-ups bei der Validierung, Einführung und Skalierung ihres MVP zu unterstützen. Kontaktieren Sie uns jetzt, um Ihr Projekt auf den Weg zu bringen.