Ein Sprintkalender wirkt professionell: feste Zusagen, regelmäßige Reviews, ein ordentliches Board. Für Solo-Freelancer ohne eigene Infrastruktur ist er meist der falsche Standard, weil Kundenfeedback und verfügbare Arbeitszeit selten im selben Takt eintreffen. Ich würde stattdessen Arbeit einzeln ziehen und jede Zusage an eine prüfbare Abnahme knüpfen. Das ist weniger zeremoniell, aber gegenüber dem Auftraggeber verbindlicher.
Ein Sprint verspricht Planbarkeit, die du allein nicht herstellen kannst
Scrum ist nicht bloß ein Kalender mit kürzeren Fristen. Der offiziell veröffentlichte Scrum Guide in der Ausgabe 2020 beschreibt einen Sprint als festen Rahmen für ein gemeinsames Ziel und benennt dafür Verantwortlichkeiten im Scrum Team. Wer allein entwickelt und auf Antworten eines Kunden wartet, kann diese Rollen nicht durch umbenannte Kalendereinträge ersetzen, weil Entscheidungen außerhalb der eigenen Kontrolle bleiben. Der Guide erlaubt Sprints von höchstens einem Monat; diese dokumentierte Obergrenze macht den Rahmen aber noch nicht passend für einen Einzelauftrag.
Die eigentliche Frage lautet: Was passiert mit einer Zusage, sobald der Kunde einen Text nicht freigibt, einen Testzugang verspätet schickt oder eine Anforderung ändert? In einem fest geplanten Sprint bleibt die Arbeit auf dem Board stehen oder wird stillschweigend ersetzt. Beides verdeckt den Grund der Verzögerung, weil „nicht fertig“ unterschiedliche Ursachen zusammenfasst. Ein Freelancer braucht vor allem eine sichtbare Grenze zwischen eigener Arbeit und ausstehender Kundenentscheidung.
Der direkte Vergleich ist deshalb Scrum-Sprint gegen Pull-Kanban. Ein Scrum-Sprint gewinnt, wenn mehrere Beteiligte verlässlich zu einem gemeinsamen Ziel beitragen, Entscheidungen innerhalb des Takts treffen und die regelmäßige Planung tatsächlich Abstimmung spart. Er kostet Vorbereitung, Review und die Pflege eines Sprintziels; bei einem Einzelauftrag fällt dieser Aufwand auf dieselbe Person, die auch liefert. Pull-Kanban gewinnt, wenn Aufgaben unabhängig abgenommen werden können und Rückmeldungen unregelmäßig eintreffen. Es kostet Disziplin bei der Priorisierung, weil kein Sprintende automatisch dazu zwingt, offene Entscheidungen anzusprechen.
Ich würde keine Zweiwochen-Sprints als Voreinstellung einführen, weil ihre feste Länge eine Verfügbarkeit des Kunden suggeriert, die ein Freelancer nicht steuern kann. Stattdessen wäre mein veränderbarer Startwert 1 aktive Lieferaufgabe. „Aktiv“ heißt dabei: Ich kann ohne neue Entscheidung weiterarbeiten. Wartet die Aufgabe auf eine Freigabe, bekommt sie den Status „wartet auf Kunde“ und einen konkreten nächsten Kontakttermin. Dieser kleine WIP-Grenzwert ist keine allgemeine Leistungsregel, sondern eine Einstellung, die du nach deinen eigenen Aufträgen anpasst.
Pull bedeutet nicht, jeden Wunsch sofort anzunehmen. Die nächste Aufgabe wird erst gewählt, wenn klar ist, was geliefert werden soll, wer das Ergebnis prüft und woran die Prüfung gelingt. Ohne diese drei Angaben würde auch ein noch so sauber gepflegtes Trello-Board nur Unklarheit sortieren. Der Vorteil des einfachen Flusses liegt darin, dass du die Unklarheit vor Arbeitsbeginn bemerkst, statt sie am Sprintende als überraschenden „Blocker“ zu melden.
Eine prüfbare Zusage schützt den Auftrag besser als eine Sprintzusage
Agiles Projektmanagement fuer erfolgreiche IT-Prozesse beschreibt ein Ziel, dem ich zustimme: Arbeit soll steuerbar bleiben; für einen Solo-Auftrag würde ich Steuerbarkeit aber an Abnahmen statt an Sprinttermine binden, weil nur die Abnahme zeigt, ob der Kunde den konkreten Stand verwenden kann.
Schreibe deshalb vor Beginn einer Aufgabe einen Liefergegenstand und eine beobachtbare Prüfung auf. „Login verbessern“ ist zu offen, weil daraus Design, Fehlermeldungen oder ein neuer Anmeldeweg werden können. „Bei einem abgelaufenen Link erscheint eine verständliche Meldung, und der Kunde bestätigt den Text auf der Testseite“ begrenzt dagegen die Arbeit. Die Formulierung ist kein Ersatz für einen Vertrag: Sie ist eine kleine, gemeinsam lesbare Entscheidung innerhalb des vereinbarten Umfangs.
Auch der Zeitpunkt einer Zusage muss präzise sein. „Freitag fertig“ vermischt Entwicklung, Bereitstellung und Kundenprüfung, obwohl dafür unterschiedliche Personen zuständig sein können. Sage lieber, welcher Stand bis Freitag auf welcher URL oder als welches Artefakt bereitliegt und wann du um Rückmeldung bittest. Kommt die Rückmeldung später, verschiebt sich die Abnahme, aber nicht rückwirkend die Tatsache, dass du geliefert hast. Diese Trennung macht spätere Gespräche über Fristen sachlicher, weil beide Seiten denselben Ablauf sehen.
Für neue Wünsche braucht es eine einfache Tauschregel: Der Kunde entscheidet, ob ein Wunsch die nächste Aufgabe ersetzt oder als zusätzliche, separat geschätzte Arbeit hinzukommt. Ohne diesen Satz wächst der Umfang nebenbei, weil ein Kommentar zu einer Lieferung leicht wie eine kostenlose Korrektur wirkt. Eine Korrektur an einem vereinbarten Abnahmekriterium bleibt selbstverständlich Teil der ursprünglichen Aufgabe; ein neues Kriterium ist dagegen eine neue Entscheidung. Der Unterschied hängt am schriftlich festgehaltenen Ergebnis, nicht an der Laune des Entwicklers.
Setze auch einen Zeitpunkt für unbeantwortete Fragen. Als anpassbaren Richtwert würde ich nach 48 Stunden ohne notwendige Freigabe den Status ausdrücklich auf „wartet auf Kunde“ setzen und die nächste bearbeitbare Aufgabe vorschlagen. Das ist keine Behauptung über übliche Reaktionszeiten: Bei einem Auftrag mit langsamen Freigabewegen kann der Wert größer sein. Entscheidend ist, dass eine Wartezeit sichtbar wird, bevor sie als angeblicher Entwicklungsverzug in einer Rechnung oder Statusmail auftaucht.
Eine kurze Nachricht reicht: „Die Testseite steht bereit. Bitte bestätige den Text oder markiere eine Abweichung vom vereinbarten Kriterium. Bis dahin arbeite ich an der Exportfunktion; eine Änderung am Textplanen wir danach neu ein.“ So bekommt der Kunde eine konkrete Handlung, und du behältst eine begründete Reihenfolge. Ein Sprint-Review wäre dafür nur dann besser, wenn beide Seiten ohnehin zu diesem Termin entscheiden können.
Ein einfaches Protokoll schlägt ein großes Board, solange Entscheidungen fehlen
Agiles Projektmanagement in der Softwareentwicklung rückt die Entwicklungsarbeit in den Mittelpunkt; bei Einzelaufträgen würde ich zuerst die Entscheidungsspur sichern, weil Codeänderungen in Git nachvollziehbar sind, mündliche Freigaben aber nicht. Dafür brauchst du weder Jira noch eine selbst betriebene Instanz. Eine Datei im Projektverzeichnis genügt, sofern du keine vertraulichen Kundendaten hineinschreibst.
Das folgende Bash-Skript läuft lokal und hängt eine Entscheidung an eine TSV-Datei an. Es fragt nur nach Liefergegenstand, Abnahme und nächstem Schritt; gerade diese Beschränkung verhindert, dass aus dem Protokoll ein zweites Pflegesystem wird.
#!/usr/bin/env bash set -eu mkdir -p .planung printf 'Liefergegenstand: '; read -r ziel printf 'Abnahme durch Kunde: '; read -r test printf 'Naechster Schritt: '; read -r schritt printf '%s | %s | %s | %s\n' "$(date -u +%F)" "$ziel" "$test" "$schritt" >> .planung/entscheidungen.tsv tail -n 1 .planung/entscheidungen.tsv
Prüfe vor dem Einchecken mit git diff, ob die Datei ins Repository gehört; Kundennamen, Zugangsdaten und interne URLs gehören nicht versehentlich in eine öffentliche Git-Historie. Falls die Datei nur lokal bleiben soll, trage .planung/ in .gitignore ein. Git ist hier ein Änderungsprotokoll, kein Freigabeverfahren: Eine Abnahme bleibt eine ausdrückliche Antwort des Kunden.
GitHub Issues lohnt sich, wenn der Kunde bereits auf GitHub mitarbeitet und dort auf eine konkrete Frage antwortet. Trello lohnt sich, wenn eine visuelle Liste die gemeinsame Abstimmung erleichtert. Jira lohnt sich erst, wenn der Auftrag in eine bestehende Kundenorganisation eingebettet ist und deren Entscheidungen dort ohnehin fallen. Ein zusätzliches Tool verursacht dagegen ein zweites Postfach, wenn der Kunde weiter per E-Mail antwortet und du den Status anschließend von Hand überträgst. Wähle daher den Ort der Entscheidung, nicht den Ort mit den meisten Board-Funktionen.
Automatisiere lieber eine Prüfung, deren Ergebnis eindeutig ist. Für ein Python-Projekt kann pytest -q lokal denselben Testlauf ausführen, den GitHub Actions bei on: push startet; das reduziert vergessene Tests, weil der Auslöser an den Code gebunden ist. Für eine Weboberfläche kann npx playwright test einen festgelegten Bedienweg prüfen, sofern die Testumgebung zuverlässig erreichbar ist. Beide Prüfungen beantworten jedoch nicht, ob dem Kunden ein Text oder Ablauf gefällt. Wer diese Entscheidung als grünen CI-Status ausgibt, erzeugt scheinbare Sicherheit, weil technische Tests nur ihre ausdrücklich formulierten Erwartungen prüfen.
Miss Wartezeit getrennt von Arbeitszeit, sonst optimierst du am falschen Punkt
Viele Boards zeigen „offen“ und „erledigt“, aber diese beiden Zustände reichen für einen Solo-Auftrag nicht aus, weil sie Wartezeit und Bearbeitung zusammenwerfen. Halte mindestens fest, wann du eine Aufgabe begonnen hast, wann du um Abnahme gebeten hast und wann die Antwort kam. Daraus kannst du die Bearbeitungszeit bis zur Lieferung und die anschließende Wartezeit getrennt betrachten. Die üblichen Begriffe Cycle Time und Lead Time sind nur hilfreich, wenn du ihre Start- und Endpunkte für deinen Auftrag ausdrücklich festlegst; sonst vergleichen zwei Zahlen unterschiedliche Abläufe.
Ein Beispiel für eine tatsächlich zu ermittelnde Einzelmessung: Wenn dein Protokoll für einen Auftrag 6 Kalendertage zwischen Bereitstellung und Abnahme zeigt, ist das die gemessene Wartezeit dieses Auftrags, keine Aussage über andere Kunden. Sieh anschließend in die Nachrichten: Fehlte eine klare Frage, brauchst du eine bessere Abnahmebitte; fehlte dem Kunden Zeit, hilft dir ein kürzerer Sprint nicht. Die Zahl ist erst zusammen mit dem Grund nützlich.
Betrachte solche Daten über einen frei wählbaren Beobachtungszeitraum von 4 Wochen, bevor du deinen Ablauf änderst. Bei nur einem Auftrag kann eine einzelne Reise oder Freigabe die Werte stark verschieben; mehrere abgeschlossene Aufgaben zeigen eher, ob ein Muster vorliegt. Zähle dabei nicht bloß erledigte Tickets als Throughput, weil sich ein großes Ergebnis beliebig in kleine Tickets zerlegen lässt. Frage stattdessen, welche vereinbarten Ergebnisse abgenommen wurden und welche Entscheidungen wiederholt hängen blieben.
Für die eigene Woche würde ich zusätzlich höchstens 20 Minuten als verstellbares Zeitbudget für die Durchsicht reservieren. Reicht es nicht, weil du viele offene Abstimmungen hast, ist eine längere Sitzung selten die erste Lösung: Formuliere zuerst die ausstehenden Fragen einzeln und schicke sie ab. Reicht es dauerhaft nicht, weil mehrere Personen Prioritäten setzen, kann ein gemeinsames Review sinnvoll werden. Der Aufwand für Abstimmung sollte aus einem erkennbaren Engpass entstehen, nicht aus der Erwartung, dass ein agiles Projekt einen bestimmten Terminplan haben müsse.
Die Entscheidung für Pull-Kanban ist damit überprüfbar, nicht ideologisch. Wenn der Kunde zuverlässig an einem gemeinsamen Sprintziel arbeitet und ein fester Review-Termin offene Fragen schneller klärt, darfst du zu Scrum wechseln. Wenn dagegen die meisten Unterbrechungen von einzelnen Freigaben abhängen, behalte den Aufgabenfluss bei und verbessere die Abnahmefragen. In beiden Fällen sollte eine Änderung am Prozess ein beobachtetes Problem lösen; sonst bezahlst du mit deiner Arbeitszeit für ein Ritual ohne Empfänger.
Dein erster Schritt ist eine einzelne Abnahmefrage
Nimm die nächste noch nicht begonnene Aufgabe und schreibe auf, welches Ergebnis du liefern wirst und welche konkrete Antwort du dafür vom Kunden brauchst. Schicke diese Frage ab, bevor du ein Board umbaust oder einen Sprint ansetzt. Bleibt die Antwort offen, notiere den Wartezustand und arbeite an der nächsten freigegebenen Aufgabe. Erst diese kleine Spur zeigt dir, ob überhaupt ein größeres Planungsritual fehlt.
