Beispiele
Reale Implementierungen und Fallstudien des Velocity40 Frameworks.
Beispiel: FL3-Berechnung für 3 Änderungen
Wir haben drei Vorhaben:
- Einführung von Zwei-Faktor-Authentifizierung
- Neues Dashboard für Benutzer
- Migration der Datenbank auf neue Version
Schritt 1: Schätzungen EXI und EVI
Jedes Vorhaben wird im Planning Poker bewertet (z. B. Fibonacci-Reihe: 1–2–3–5–8–13…).
- EXI (Execution Index) = Komplexität, Risiko, Unsicherheit der Umsetzung
- EVI (Evolution Index) = Nutzen, Chance, Wert für die Zukunft
| Vorhaben | EXI (Komplexität) | EVI (Nutzen) |
|---|---|---|
| Zwei-Faktor-Authentifizierung | 8 | 13 |
| Dashboard für Benutzer | 5 | 8 |
| Datenbank-Migration | 13 | 8 |
Schritt 2: Berechnung des EXI/EVI-Verhältnisses
Formel:
Strategisches Verhältnis = EXI/EVI
Je niedriger das Verhältnis, desto besser die Rendite (geringe Komplexität × hoher Nutzen).
| Vorhaben | EXI | EVI | Verhältnis EXI/EVI |
|---|---|---|---|
| Zwei-Faktor-Authentifizierung | 8 | 13 | 0,62 |
| Dashboard für Benutzer | 5 | 8 | 0,63 |
| Datenbank-Migration | 13 | 8 | 1,63 |
Schritt 3: Interpretation der Ergebnisse
- Priorität 1: Zwei-Faktor-Authentifizierung (0,62) – hoher Nutzen, relativ geringe Komplexität.
- Priorität 2: Dashboard für Benutzer (0,63) – fast genauso vorteilhaft wie 2FA.
- Priorität 3: Datenbank-Migration (1,63) – komplexer als ihr Nutzen; eher aufschieben oder unterstützende Kapazitäten bereitstellen.
✅ FL3-Ausgabe: das Team hat eine klare Reihenfolge der Änderungen nach EXI/EVI-Verhältnis.
Auf FL2 werden sie dann weiter in Segmente (BVI/EFI) aufgeteilt, und auf FL1 in konkrete Aufgaben in Stunden.
FL2-Beispiel: „Dashboard für Benutzer"
Schritt 1: Aufteilung in kleinere Teile
Das große Vorhaben (Dashboard) teilen wir in 3 Segmente auf:
- UI-Komponenten (Widgets, Filter, Diagramme)
- Datenanbindung (API, Query, Performance)
- Benachrichtigungen und Personalisierung (Benutzerpräferenzen, Alerts)
Schritt 2: Schätzung BVI und EFI
- BVI (Business Value Index) = Nutzen für Benutzer/Business
- EFI (Effort Index) = Schätzung des Arbeitsaufwands
Wir verwenden wieder die Fibonacci-Reihe (1–2–3–5–8–13…).
| Segment | BVI (Wert) | EFI (Aufwand) |
|---|---|---|
| UI-Komponenten | 13 | 8 |
| Datenanbindung | 8 | 13 |
| Benachrichtigungen und Personalisierung | 5 | 5 |
Schritt 3: Berechnung des BVI/EFI-Verhältnisses
Formel:
Koordinationsverhältnis = BVI/EFI
| Segment | BVI | EFI | BVI/EFI | Notwendigkeit |
|---|---|---|---|---|
| UI-Komponenten | 13 | 8 | 1,63 | JA |
| Datenanbindung (minimal) | 8 | 8 | 1,00 | Ja |
| Benachrichtigungen | 5 | 5 | 1,00 | Nein |
| Report-Export nach PDF/Excel | 5 | 8 | 0,63 | Nein |
Schritt 4: Interpretation der Ergebnisse
- UI-Komponenten – JA + bestes Verhältnis
- Datenanbindung (minimal) – JA (must-have)
- Benachrichtigungen – ausgeglichen
- Report-Export – niedrigste Rendite, kann verschoben werden
✅ FL2-Ausgabe: wir wissen, welche Dashboard-Teile den größten Nutzen bringen.
Auf FL1 übersetzen wir diese Teile dann in konkrete Aufgaben in Stunden.
FL1-Beispiel: „UI-Komponenten" (aus Dashboard)
Schritt 1: Aufschlüsselung in Aufgaben
Das Segment teilen wir in konkrete Aufgaben von max. 8 Stunden (1 Arbeitstag).
Wir gehen davon aus, dass wir ein grundlegendes Dashboard mit 3 Haupt-Widgets bauen.
- Layout-Entwurf für Dashboard (Wireframe, grundlegende Anordnung)
- Implementierung Widget „Aktive Aufgaben" (Tabelle, Filter)
- Implementierung Widget „Fortschrittsdiagramm" (Burndown / Velocity)
- Implementierung Widget „Letzte Aktivitäten" (Log, Änderungsliste)
- Testing und UI-Feintuning (Cross-Browser, grundlegende UX)
Schritt 2: Schätzung in Stunden
Jede Aufgabe hat einen Verantwortlichen und eine Schätzung in Stunden (max. 8h).
| Aufgabe | Schätzung (h) |
|---|---|
| Layout-Entwurf für Dashboard | 4 h |
| Implementierung Widget „Aktive Aufgaben" | 8 h |
| Implementierung Widget „Fortschrittsdiagramm" | 8 h |
| Implementierung Widget „Letzte Aktivitäten" | 6 h |
| Testing und UI-Feintuning | 6 h |
Schritt 3: Summe und Kapazitätsprüfung
4+8+8+6+6=32 Stunden
Das entspricht etwa 1 Woche Kapazität einer Person (40 h).
Es bleiben 8h Reserve → können unerwartete Anpassungen oder Bugfixes abdecken.
Schritt 4: Interpretation der Ergebnisse
- Aufgaben sind ausreichend granular (jeweils max. 1 Tag).
- Die Schätzung ist realistisch, deckt ~1 Sprint tägliche Leistung einer Person ab.
- Das Team weiß genau, wer was macht und wann es fertig sein kann.
✅ FL1-Ausgabe: konkreter Arbeitsplan für UI-Komponenten des Dashboards – 32 Stunden / 1 Woche für eine Person.