Warum ein Sprint noch keinen Projektstart macht
Viele Softwareprojekte geraten nicht wegen fehlender Arbeitsleistung unter Druck, sondern weil Umsetzung beginnt, bevor Ziel, Scope, Verantwortung und technische Rahmenbedingungen zusammenpassen. Dann läuft zwar ein Sprint, aber Entscheidungen werden weiterhin im Tagesgeschäft nachgeholt.
Das zeigt sich später als Scope Creep, Budgetdruck, technische Schulden oder als dauernde Nachverhandlung: Was war eigentlich gemeint? Wer entscheidet? Welche Nutzergruppe zählt zuerst? Welche Bestandssoftware darf nicht gefährdet werden? Solche Fragen gehören vor den ersten Sprint, nicht erst in seine Mitte.
Ein Softwareprojekt beginnt deshalb nicht mit der ersten Zeile Code. Es beginnt mit einer strukturierten Klärung, die aus einer Idee ein Projekt macht. Genau dort liegen die wichtigsten Schritte.
Discovery-Ergebnisse und Startentscheidung
Eine Projektidee ist erst dann umsetzungsbereit, wenn die folgenden Ergebnisse für die erste Etappe greifbar sind. Fehlen mehrere davon, ist eine kurze Discovery die sinnvollere Vorstufe.
| Discovery-Ausgabe | Woran sie erkennbar wird | Entscheidung für den Start |
|---|---|---|
| Ziel und erster Nutzen | Betroffene Nutzer und die gewünschte Veränderung sind benannt. | Start nur, wenn die erste Wirkung verständlich ist. |
| Scope der ersten Etappe | In, out und offene Abhängigkeiten sind getrennt. | Erstes Release begrenzen statt Wunschliste übernehmen. |
| Verantwortung | Fachliche Entscheidung und technische Führung sind benannt. | Ohne Entscheider kein Sprintstart. |
| System- und Betriebsbild | Schnittstellen, Daten, Rechte und Ausfallgrenzen sind grob sichtbar. | Risiko prüfen, bevor es zum Sprintproblem wird. |
| Arbeitsmodus | Review, Priorisierung und Entscheidungsrhythmus stehen fest. | Umsetzung beginnt mit einem gemeinsamen Takt. |
Für kleinere Vorhaben reichen dafür oft wenige Workshops. Bei Bestandssoftware, Modernisierung oder mehreren Stakeholdern kann eine zwei- bis vierwöchige Discovery die belastbarere Entscheidung sein.
Ausgangslage: Warum, für wen und auf welcher Basis?
Bevor ein Softwareprojekt startet, sollte die Ausgangslage in einfachen Worten beschreibbar sein. Warum jetzt? Für wen wird gebaut? Und auf welcher technischen oder organisatorischen Basis beginnt das Projekt?
Bei einem neuen internen Tool kann der Anlass zum Beispiel sein, dass Excel, E-Mail und manuelle Übergaben zu viele Fehler erzeugen. Bei einem Kundenportal kann es darum gehen, wiederkehrende Anfragen in einen Self-Service-Prozess zu bringen. Bei einem Bestandssystem kann der eigentliche Auslöser sein, dass Releases riskant geworden sind oder Wissen nur noch bei einzelnen Personen liegt.
Hilfreiche Fragen für den Start sind:
- Welcher Prozess soll nach dem Projekt spürbar besser funktionieren?
- Welche Nutzergruppen sind betroffen: interne Teams, Kunden, Partner oder Admins?
- Welche bestehenden Systeme, Datenbanken, APIs oder Oberflächen müssen eingebunden werden?
- Wo entsteht heute der größte Aufwand, das größte Risiko oder die meiste Unsicherheit?
- Was darf während der Umsetzung auf keinen Fall ausfallen?
Diese Einordnung entscheidet auch darüber, welche Fähigkeiten die erste Etappe braucht. Ein neues Tool, eine Bestandsübernahme und eine Systemmodernisierung können ähnliche Nutzerfragen haben, verlangen aber unterschiedliche technische Zugänge. Die Lösungsform sollte aus dem Problem folgen, nicht vorab durch eine bevorzugte Technologie festgelegt werden.
Zielbild und Scope: Was gehört in dieses Projekt?
Ein Zielbild gibt Richtung. Scope entscheidet, was davon jetzt wirklich bearbeitet wird. Beides muss getrennt werden, weil sonst aus einer sinnvollen Vision sehr schnell ein zu großer erster Release wird.
Ein Zielbild kann lauten: “Alle manuellen Onboarding-Prozesse sollen bis 2027 digital unterstützt werden.” Der erste Scope kann trotzdem viel enger sein: nur Österreich, nur B2B-Kunden, nur Standardprodukte, nur die ersten drei Prozessschritte. Diese Begrenzung ist kein Verlust. Sie macht das Projekt lieferbar.
Gute Scope-Arbeit beantwortet mindestens drei Fragen:
- Welche Wirkung muss die erste Etappe unbedingt erzeugen?
- Welche Funktionen sind dafür notwendig, welche nur angenehm?
- Welche Abhängigkeiten würden den ersten Schritt unnötig riskant machen?
Genau hier schließt die Vertiefung Warum Scope vor der Featureliste kommt an. Eine Featureliste zeigt, was wichtig sein könnte. Scope entscheidet, was zusammen in eine tragfähige erste Etappe gehört.
Anforderungen: Von groben Zielen zu User Stories
Ein Softwareprojekt braucht keine 80-seitige Spezifikation, bevor es starten darf. Es braucht aber genug Struktur, damit Anforderungen nicht nur als Wünsche im Raum stehen. User Stories sind dafür oft ein guter Rahmen, weil sie Rolle, Funktion und Nutzen verbinden.
Eine brauchbare User Story folgt meistens diesem Muster:
Als Sachbearbeiter möchte ich Anträge direkt aus Outlook übernehmen, damit doppelte Erfassung entfällt.
Daraus wird erst dann eine umsetzbare Anforderung, wenn Akzeptanzkriterien, Business Value, Abhängigkeiten und offene Fragen sichtbar sind. Für den Start reicht es nicht, alle Anforderungen vollständig zu kennen. Sinnvoll ist ein grobes Backlog für drei bis sechs Monate und detaillierte Stories für die ersten zwei bis drei Sprints.
Wichtig ist die Validierung: Stimmen die Anforderungen mit dem tatsächlichen Bedarf der Nutzer überein? Wurde mit den Menschen gesprochen, die später im System arbeiten? Sind fachliche Sonderfälle verstanden oder nur vermutet? Ohne diese Prüfung entsteht leicht Software, die formal umgesetzt wurde, aber am Alltag vorbeigeht.
Priorisierung und Roadmap: Welche Funktionen kommen wann?
Nach Zielbild und Anforderungen braucht das Projekt eine erste Reihenfolge. Eine Roadmap ist dabei kein starrer Plan für jedes Detail. Sie zeigt, welche Etappen zusammengehören und wo Entscheidungen später mit besserem Wissen neu getroffen werden.
Eine einfache Priorisierung reicht oft aus:
| Stufe | Bedeutung | Beispiel Kundenportal |
|---|---|---|
| Must | Ohne diese Funktion trägt der erste Release nicht. | Login, Rollen, Rechnungsübersicht |
| Should | Wichtig, aber nicht zwingend für den ersten Nutzen. | Stammdaten im Self-Service ändern |
| Could | Nützlich, aber gut verschiebbar. | Dashboard mit Komfort-KPIs |
Bei Modernisierung gehören auch technische Meilensteine in die Roadmap: eine API entkoppeln, Tests für kritische Logik ergänzen, einen alten SOAP-Service ersetzen, ein Frontend schrittweise ablösen oder Release-Prozesse stabilisieren. Bei laufenden Systemen ist genau diese Mischung aus Fachlichkeit und Technik entscheidend.
Mehr dazu passt zu warum Priorisierung und Release-Sicherheit zusammengehören .
Arbeitsmodell: Wie wird konkret zusammengearbeitet?
Vor dem ersten Sprint sollte klar sein, wie Entscheidungen getroffen und Ergebnisse überprüft werden. Scrum, Kanban oder ein hybrides Modell sind nur dann hilfreich, wenn sie zur Projektsituation passen.
Ein typisches Setup kann so aussehen:
- ein Kickoff von einigen Stunden, um Ziele, Rollen, Risiken und erste Etappe zusammenzuführen
- zweiwöchige Sprints mit Review und Priorisierung
- ein benannter Product Owner auf Kundenseite
- ein technischer Lead für Architektur, Schnittstellen und Umsetzungsrisiken
- kurze regelmäßige Statuspunkte statt langer unklarer Abstimmungen
Bei laufendem Betrieb ist häufig ein hybrides Vorgehen sinnvoll. Kanban hilft bei Stabilisierung, Support und kleineren Eingriffen. Scrum oder sprintähnliche Etappen helfen bei neuen Features, Portalen oder Modernisierungsschritten. Die Seite Arbeitsweise beschreibt, wie aus dieser frühen Klärung ein tragfähiger Umsetzungsmodus wird.
Technische Risiken: Architektur, Schnittstellen und Betrieb
Viele Projekte geraten nicht wegen falscher Features unter Druck, sondern wegen unterschätzter technischer Rahmenbedingungen. Deshalb müssen Architektur, Schnittstellen, Daten, Sicherheit und Betrieb früh genug sichtbar werden.
Vor dem Start sollten mindestens diese Punkte geklärt sein:
- Hosting und Betriebsmodell: On-Premises, Cloud, Azure, bestehende Infrastruktur
- Sicherheitsanforderungen: Rollen, Berechtigungen, Logging, DSGVO, Zugriffskonzepte
- Daten und Schnittstellen: Datenqualität, Imports, Exports, APIs, ERP oder CRM
- technische Schulden: veraltete Frameworks, fehlende Tests, direkte Datenbankzugriffe
- Release-Risiken: Deployment, Rollback, Staging, Monitoring, Verantwortlichkeiten
Gerade bei gewachsenen .NET-Systemen, älteren Webanwendungen oder internen Tools ist ein begrenzter technischer Audit vor der Umsetzung oft sinnvoll. Drei bis fünf Tage reichen manchmal, um die wichtigsten Risiken sichtbar zu machen. Danach lässt sich verlässlicher entscheiden, ob Stabilisierung, API-Schnitt, neues Frontend oder ein kleiner erster Release der richtige Einstieg ist.
Empfehlung: Erst Discovery, wenn die Projektbasis noch unscharf ist
Discovery bringt Idee, Nutzerbedarf, Scope, technische Realität und wirtschaftlichen Rahmen in eine entscheidbare erste Etappe. Sie ist sinnvoll, wenn Ziele konkurrieren, der Bestand kaum dokumentiert ist oder niemand die fachliche Verantwortung bündeln kann. Ein kompakter One-Pager mit Ziel, Risiken, erstem Release und offenen Fragen reicht oft aus.
Nächster Schritt: Die erste Etappe entscheidbar machen
Wenn Ziel, Scope oder technische Basis noch unscharf sind, ist der beste nächste Schritt eine kurze Einordnung. Dafür braucht es kein fertiges Pflichtenheft, sondern ein gemeinsames Bild von Problem, betroffenen Abläufen, Risiken und der Entscheidung, die als Nächstes getroffen werden muss.
Wenn Sie vorher selbst sortieren möchten, helfen diese Anschlüsse:
- Arbeitsweise für den Projektmodus von Anfrage bis Go-live
- Warum Scope vor der Featureliste kommt für die Begrenzung der ersten Etappe
- Was eine gute Projektübergabe ausmacht für klare Verantwortung zwischen Fachseite und Umsetzung
Häufige Fragen
Wie lange sollte die Vorbereitung vor dem ersten Sprint dauern?
Für klar umrissene Vorhaben reichen oft ein bis zwei Wochen. Bei Bestandssoftware, Modernisierung, mehreren Stakeholdern oder unklarer Datenlage sind zwei bis vier Wochen realistischer. Die Vorbereitung ist keine Pause vor der Arbeit, sondern ein Teil der Projektarbeit.
Wie detailliert müssen Anforderungen vor dem Start sein?
Nicht jede Anforderung muss im Detail beschrieben sein. Sinnvoll ist ein grobes Backlog für drei bis sechs Monate und eine detaillierte Sicht auf die ersten zwei bis drei Sprints. Dazu gehören Akzeptanzkriterien, Priorität, fachlicher Nutzen und bekannte Abhängigkeiten.
Was kostet ein professioneller Projektstart?
Das hängt stark von Umfang, Bestand und Risiko ab. Ein kurzer Discovery-Workshop ist etwas anderes als eine mehrwöchige Analyse eines gewachsenen Systems. Entscheidend ist weniger ein pauschaler Betrag als die Frage, ob danach Scope, Risiken und erste Etappe belastbar genug sind.
Kann man ein laufendes, chaotisches Softwareprojekt stabilisieren?
Ja, aber selten durch noch mehr Geschwindigkeit. Ein Projekt-Reset braucht einen ehrlichen Blick auf Code, Architektur, Backlog, Rollen und Zusammenarbeit. Oft ist zuerst Stabilisierung nötig, bevor neue Features wieder sinnvoll geplant werden.
Welche Rolle spielt das interne Team beim Projektstart?
Das interne Team ist entscheidend. Es bringt Prozesswissen, Systemzugänge, Nutzerperspektive und Entscheidungskontext ein. Ein externer Partner kann Struktur, technische Führung und Umsetzung ergänzen, ersetzt aber keine interne Verantwortung.
Fazit
Ein Softwareprojekt startet nicht mit dem ersten Sprint, sondern mit einer entscheidbaren ersten Etappe. Nicht jede Frage muss beantwortet sein. Ziel, Verantwortung, Risiken und die Grenze des ersten Schritts müssen jedoch so klar sein, dass Umsetzung nicht auf stillen Annahmen aufbaut.