Sprint-Planung für ein Mensch-Agent-Team funktioniert, wenn du um die Review-Kapazität herum planst und nicht um die Ausführungsgeschwindigkeit. Agenten können mehr Tasks beanspruchen und abschließen, als deine Reviewer abnehmen können. Die eigentliche Grenze eines Zyklus ist also nicht, wie viel Code geschrieben wird, sondern wie viele fertige Änderungen eine Person prüfen und mergen kann. Dieser Leitfaden führt Schritt für Schritt durch die Planungsmethode, benennt bei jedem Schritt das Fehlerbild und endet mit einer Checkliste, die du vor deinem nächsten Sprint durchgehen kannst.
Klassische Sprint-Planung geht davon aus, dass die knappe Ressource die Stunden sind, die Entwickler zum Schreiben von Code haben. Kommen Coding-Agenten dazu, bricht diese Annahme zusammen. Claude Code, Codex und Gemini CLI können jeweils einen Task übernehmen und einen funktionierenden Diff zurückliefern, während du noch den letzten liest. Die Ausführung ist nicht mehr der Engpass. Die Abnahme wird es.
Dieser Wandel bringt einen normalen Plan still und leise durcheinander. Du dimensionierst einen Zwei-Wochen-Zyklus in Entwicklertagen, die Agenten arbeiten das Backlog in drei Tagen ab, und hinter ein oder zwei Personen, die den Merge abnehmen können, türmt sich eine Warteschlange fertiger, aber ungeprüfter Änderungen auf. Der Sprint sieht schnell aus und endet langsam.
Sharkly ist der Workspace, in dem dieser Leitfaden plant. Coding-Agenten hast du bereits; Sharkly macht aus ihnen ein Team, indem jeder Task, sein Fortschritt, seine Blocker, Ergebnisse und die menschliche Prüfung an einem gemeinsamen Ort bleiben, statt über Terminals verstreut zu sein. Ein Sprint in Sharkly ist eine zeitlich begrenzte Menge von Tasks, die zu einem Space gehören. Die folgende Methode ist dieselbe, egal ob du sie auf einem Whiteboard oder im Produkt durchführst – die Fehlerbilder lassen sich jedoch leichter erkennen, sobald die Arbeit auf einem gemeinsamen Board landet.
Was sich ändert, wenn Agenten die Ausführung übernehmen
Sprint-Planung für ein Mensch-Agent-Team bedeutet, einen Zyklus danach zuzuschneiden, wie viel fertige Agenten-Arbeit ein Mensch prüfen und abnehmen kann – und nicht danach, wie viel Code das Team produzieren kann.
Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen die Befugnis und nehmen das Ergebnis ab. Diese Aufteilung ist das eigentliche Planungsproblem. Der Durchsatz deiner Agenten ist elastisch: Du kannst drei laufen lassen oder zehn. Dein Review-Durchsatz ist dagegen durch die Zahl der Personen begrenzt, die einen Diff lesen, die Änderung ausführen und entscheiden können, dass sie ausgeliefert wird. Warum ein 5-facher Sprung beim Agenten-Output selten 5-mal mehr ausgelieferte Arbeit bedeutet, erklärt die Rechnung zur Review-Kapazität.
Die erste Zahl, mit der du planst, sind also nicht Story Points. Es sind Review-Slots: Wie viele abgeschlossene Tasks kann jeder Reviewer pro Tag abnehmen, multipliziert mit der Zahl der Reviewer und den Tagen im Zyklus. Alles andere muss unter diese Obergrenze passen.
Den Sprint Schritt für Schritt planen
1. Lege zuerst die Review-Obergrenze fest. Schätze, wie viele abgeschlossene Tasks ein Reviewer pro Tag wirklich abnehmen kann; eine echte Prüfung einer nicht trivialen Änderung dauert 30 bis 60 Minuten. Multipliziere das mit der Zahl der Reviewer und den Sprint-Tagen. Fehlerbild: Du überspringst diesen Schritt, planst nach Agenten-Kapazität, übernimmst zu viel und beendest den Zyklus mit einer Review-Warteschlange, die länger ist als der Sprint selbst.
2. Dimensioniere Tasks für das Review, nicht für die Ausführung. Zerlege die Arbeit so, dass jeder Task einen Diff erzeugt, den eine Person im Kopf behalten kann. Fehlerbild: Ein Agent liefert fröhlich eine Änderung über 2.000 Zeilen in neun Dateien zurück, niemand kann sie in einem einzigen Slot abnehmen, und sie verrottet am unteren Ende des Boards.
3. Formuliere Akzeptanzkriterien, bevor du zuweist. Jeder Task braucht eine testbare Definition of Done: was gebaut werden soll, wie „korrekt" aussieht und was nicht angefasst werden darf. Fehlerbild: Bei vage umrissenem Umfang rät der Agent, der Reviewer schickt die Arbeit zurück, und ein Task verbraucht zwei Review-Slots.
4. Weise bewusst einem einzelnen Agenten oder einer Crew zu. Nutze einen Agenten für kleine, klar umrissene Arbeit. Nutze eine Crew, wenn ein leitender Agent das Ziel interpretieren, weitere Mitglieder hinzuziehen und ihre Ergebnisse in einem Task zusammenführen muss. Fehlerbild: Wer für triviale Arbeit zu einer Crew greift, schafft zusätzliche bewegliche Teile, die du anschließend prüfen musst.
5. Begrenze die laufende Arbeit. Lege eine Obergrenze fest, wie viele Tasks in der Spalte „In Review" stehen dürfen – so wie WIP-Limits im Kanban funktionieren. Fehlerbild: Ohne Obergrenze fluten die Agenten die Review-Spalte schneller, als Menschen sie leeren können; der Engpass bleibt bis zum letzten Tag unsichtbar.
6. Plane einen Puffer ein. Halte Review-Slots für Nacharbeit und für die Änderungswünsche frei, die du zurückschickst. Fehlerbild: Du planst bis auf 100 % und die erste Runde „bitte korrigieren" hat keinen Platz mehr.
Wo eine Tabellenkalkulation oder ein reines Ticket-Setup nicht mehr skaliert
Den ersten Sprint kannst du in einer Tabellenkalkulation fahren. Ein Tab mit Tasks, eine Spalte für den Owner, eine für den Status. Das hält zusammen, solange eine Person zwei Agenten in einem Repo laufen lässt.
Es funktioniert nicht mehr, sobald Ausführung und Tracking auseinanderlaufen. Der Lauf des Agenten, der Diff, die Testausgabe und die Diskussion leben in einem Terminal; die Tabelle enthält ein veraltetes „in Bearbeitung". Jemand aktualisiert die Zeile von Hand – oder niemand. Kommt ein dritter Agent über ein zweites Repo dazu, weicht das Board innerhalb eines Tages von der Realität ab. Dann kannst du die eine Frage nicht mehr beantworten, von der die Planung abhängt: Was ist fertig, und was wartet auf mich?
Ein Task-Board, das dafür gebaut ist, hält Ausführung und Aufzeichnung zusammen. Arbeit, Fortschritt, Blocker und Ergebnisse kehren zum Task zurück, statt in privaten Sessions zu verschwinden. In Sharkly beansprucht ein Agent einen bereiten Task, läuft in einem isolierten Worktree, damit parallel laufende Änderungen nicht kollidieren, und seine Änderungszusammenfassung, die Verifikationsergebnisse und bekannte Einschränkungen landen in der Task-Timeline, damit eine Person sie abnehmen oder zurückschicken kann. Das ist der Unterschied zwischen einem Status, den du pflegst, und einem Status, der sich selbst pflegt. Außerdem liefert es deiner nächsten Planungssitzung echte Daten: welche Arbeit die Agenten abgeschlossen haben im letzten Zyklus und wohin die Review-Zeit geflossen ist.
Ehrliche Grenze: Wenn du einen Agenten in einem Repo laufen lässt und währenddessen prüfst, brauchst du dafür kein Task-Board und kein Sharkly. Ein einzelnes Terminal und eine Checkliste reichen. Die Gleichung ändert sich, sobald du über mehrere Agenten, Tasks, Repositories oder Personen hinweg planst – genau an dem Punkt wird aus einer Tabellenkalkulation ein zweiter Job. Sharkly ist für diesen zweiten Fall gebaut; lade es herunter, wenn die Tabelle anfängt, dich anzulügen.
Eine Checkliste für die Zeit vor deinem nächsten Sprint
Geh das durch, bevor du den Plan festzurrst:
- [ ] Review-Obergrenze berechnet (Reviewer x Abnahmen pro Tag x Tage) und als echte Kapazität des Sprints behandelt.
- [ ] Jeder Task ist klein genug, um in einem einzigen Slot geprüft zu werden.
- [ ] Jeder Task hat testbare Akzeptanzkriterien und eine klare „Nicht anfassen"-Grenze.
- [ ] Jeder Task ist bewusst einem einzelnen Agenten oder einer Crew zugewiesen, nicht standardmäßig.
- [ ] Für die Spalte „In Review" gibt es eine WIP-Obergrenze.
- [ ] Puffer für Nacharbeit und Änderungswünsche ist eingeplant.
- [ ] Für jeden Task liegt die Merge- und Release-Entscheidung bei einem Menschen.
- [ ] Fortschritt, Blocker und Ergebnisse landen auf einem gemeinsamen Board, nicht in privaten Terminals.
Wenn du alle acht abhakst, bleibt die Agenten-Ausführung innerhalb eines Plans, den das Team abschließen kann. Verpasst du den ersten Punkt, retten dich die übrigen nicht.
FAQ
Ist Sprint-Planung noch sinnvoll, wenn Agenten den Großteil des Codes schreiben? Ja, aber die Einschränkung verschiebt sich. Ein Sprint ist kein Container für Engineering-Stunden mehr, sondern ein Container für Review und Abnahme. Plane den Zyklus danach, wie viel fertige Arbeit Menschen prüfen können, und die Agenten füllen ihn. Der Scrum Guide definiert die Zeremonie weiterhin; nur die Kapazitätsrechnung ändert sich.
Wie schätze ich die Kapazität für ein Mensch-Agent-Team? Geh von den Reviewern aus, nicht von den Agenten. Zähle die abgeschlossenen Tasks, die eine Person pro Tag ehrlich abnehmen kann, und multipliziere das mit der Zahl der Reviewer und den Sprint-Tagen. Die Zahl der Agenten spielt nur so lange eine Rolle, bis sie diese Obergrenze überschreitet; danach lassen mehr Agenten nur die Warteschlange wachsen.
Sollten Agenten ihre Tasks während des Sprints selbst auswählen? Lass sie bereite Tasks beanspruchen, die bereits Akzeptanzkriterien tragen, damit parallele Arbeit ohne Dispatcher vorankommt. Menschen bleiben bei Richtung, Befugnis und Merge. So bleibt der Human in the Loop dort, wo Urteilsvermögen gefragt ist, und alles andere läuft automatisch.
Worin unterscheidet sich das von normalem Projektmanagement? Die Zeremonien sehen gleich aus; der Engpass nicht. AI-Agent-Projektmanagement plant um Review-Durchsatz und Änderungsisolation herum statt um Entwicklerverfügbarkeit, weil die Ausführung nicht mehr die knappe Ressource ist.
Brauche ich ein neues Tool, oder kann ich Jira erweitern? Du kannst das System behalten, das dein Team schon versteht. Die Lücke ist, dass Ticket-Tools einen Status verfolgen, den ein Mensch eintippt, und nicht eine Ausführung, die eine Maschine durchführt. Wo diese Lücke anfängt wehzutun, zeigen Jira-Alternativen für Mensch-Agent-Teams.
