Sprint-Planung beruhte schon immer auf einer stillen Annahme: Die Kapazität ergibt sich aus der Anzahl der Personen multipliziert mit der Timebox. Man schätzt den Aufwand, vergleicht ihn mit dem, was das Team im letzten Zyklus geschafft hat, und verpflichtet sich auf einen Umfang, der hineinpasst.
Setzt man KI-Coding-Agents ins Team, beschreibt diese Gleichung die Realität nicht mehr. Ein Agent kann einen Task beanspruchen, sobald er bereit ist, parallel zu allen anderen Agents arbeiten und mit einem Diff und Testergebnissen zurückkommen, bevor das Standup beginnt, in dem man das eigentlich besprechen wollte. Die Ausführungskapazität steigt dramatisch. Die naheliegende Reaktion ist, mehr Umfang zuzusagen – und Teams, die das tun, entdecken den Fehlermodus meist schon am Ende des ersten Zyklus: Der Sprint schließt mit reichlich fertigem Code ab und mit einer Wand ungelesener Änderungen, für die niemand Zeit hatte, sie abzunehmen.
Das ist die These dieses Beitrags: Mit Agents im Team ist die Ausführung nicht länger der Engpass des Sprints – das menschliche Review wird zum Engpass. Plane nach dem Abnahme-Durchsatz, nicht danach, wie viel Code produziert werden kann. Wir nutzen Sprints in Sharkly als konkreten Mechanismus und halten die Planungsargumentation klar von den Produktfakten getrennt.
TL;DR
Ein Sprint in Sharkly ist eine zeitlich begrenzte Menge von Tasks, die einem Space gehören; Tasks bleiben die Quelle für Ausführung und Diskussion, während der Sprint Zeitplan, Umfang und Reporting ergänzt. Sprints sind optional und laufen in einem von zwei Modi: automatischer Rhythmus, bei dem Sharkly den Zeitplan pflegt und unerledigte Arbeit weiterträgt, oder manuell, bei dem Personen Sprints explizit anlegen, starten und abschließen. Das Reporting deckt Umfang, begonnene und abgeschlossene Arbeit, Abschlussrate, Kapazität und Burnup-Verlauf ab. Für hybride Mensch-Agent-Teams bedeutet das eine Verschiebung in der Planung: Agents blähen die Ausführungskapazität auf, doch die Abnahme bleibt bei den Menschen. Die ehrliche Sprint-Zusage orientiert sich deshalb daran, wie viel fertige Arbeit deine Reviewer abnehmen können – nicht daran, wie viel deine Agents produzieren können.
Was ein Sprint in Sharkly ist
Ein Sprint ist eine zeitlich begrenzte Menge von Tasks, die einem Space gehören. Er hilft einem Team, einen fokussierten Umfang zu planen, den Fortschritt zu verfolgen und zu entscheiden, was mit unerledigter Arbeit passiert, wenn die Timebox endet. Tasks bleiben die Quelle für Ausführung und Diskussion; ein Sprint ergänzt Zeitplan, Umfang und Reporting.
Die Doku verwendet den Begriff Sprint und meint damit dasselbe wie die Branche. Der Scrum Guide beschreibt Sprints als Container fester Länge, in denen aus Ideen Wert entsteht, und Sharklys Variante steht in dieser Tradition. Was Sharkly ändert, ist die Frage, wer innerhalb des Zeitfensters ausführt.
Drei Abgrenzungen halten das Konzept sauber:
- Ein Sprint gehört zu genau einem Space. Einen Task in einen Sprint zu legen, ändert nicht seine Zugehörigkeit.
- Sprints sind optional und werden pro Space aktiviert. Ein Space, der in kontinuierlichem Flow denkt, muss sie nie einschalten.
- Ein Sprint ist kein Project und kein View. Nutze einen Sprint, wenn die Frage lautet, was in einem bestimmten Zeitfenster abgeschlossen werden soll. Nutze ein Project für ein Ergebnis, das sich über mehrere Sprints oder Spaces erstrecken kann. Nutze einen View für eine gespeicherte Art, Tasks zu betrachten.
Diese letzte Unterscheidung leistet im Hybrid-Team echte Arbeit: Das Project hält das Ergebnis, der Sprint die kurzfristige Zusage und die Views die Ausschnitte, die jede Person im Alltag braucht.
Automatischer Rhythmus oder manueller Modus
Wenn du Sprints für einen Space aktivierst, wählst du einen von zwei Lebenszyklus-Modi. Die Wahl verändert das Verhalten des Lebenszyklus, nicht die Zuständigkeit für Tasks.
Beim automatischen Rhythmus übernimmt Sharkly den Kalender. Du konfigurierst die Sprint-Dauer, einen optionalen Cooldown, den Startwochentag, die Anzahl der künftigen Sprints, die vorgehalten werden sollen, die Zeitzone und Regeln, die Tasks automatisch hinzufügen, sobald sie in ausgewählte Statuskategorien wechseln. Sharkly legt dann künftige Sprints an, startet und beendet sie planmäßig und trägt unerledigte Arbeit weiter. Startest du einen bevorstehenden Sprint vorzeitig, wird zuerst der aktuelle abgeschlossen und dessen unerledigte Arbeit in den gerade gestarteten Sprint überführt.
Der manuelle Modus lässt die Kontrolle über den Lebenszyklus beim Team. Personen legen bei Bedarf geplante Sprints an, starten sie, ohne die konfigurierten Daten zu ändern, betreiben mehrere aktive Sprints parallel und entscheiden beim Abschluss, wohin unerledigte Tasks wandern. Automatisches Anlegen, Rollover, Cooldown und statusbasierte Hinzufügen-Regeln bleiben im manuellen Modus inaktiv.
| Automatischer Rhythmus | Manueller Modus | |
|---|---|---|
| Zeitplan | Sharkly legt Sprints in einem konfigurierten Rhythmus an, startet und beendet sie | Personen legen Sprints explizit an, starten und beenden sie |
| Unerledigte Arbeit | Wird automatisch in den nächsten Sprint weitergetragen | Wird beim Abschluss gesteuert: kein Sprint, ein anderer Sprint oder ein neuer |
| Parallel aktive Sprints | Ein aktueller Sprint pro Rhythmus | Mehr als ein aktiver Sprint möglich |
| Task-Eingang | Regeln für Statuskategorien können während des Zeitfensters Tasks hinzufügen | Tasks werden von Personen über die Planung, Listen oder das Sprint-Feld hinzugefügt |
| Am besten geeignet für | Einen gleichmäßigen Rhythmus, den das Team ohne Zeremonie gepflegt haben möchte | Unregelmäßige Zyklen, release-getriebene Zeitfenster oder überlappende Vorhaben |
Die ehrliche Entscheidungshilfe: Nutze den automatischen Rhythmus, wenn dein Team einen gleichmäßigen Takt hat und die Mechanik gepflegt haben möchte. Nutze den manuellen Modus, wenn deine Zyklen unregelmäßig sind, wenn Releases statt Kalender deine Zeitfenster bestimmen oder wenn du zwei aktive Sprints gleichzeitig brauchst. Der Wechsel zum manuellen Modus behält bestehende Sprints bei, stoppt aber die automatische Planung. Deaktivierst du Sprints ganz, werden die aktiven abgeschlossen, künftige entfernt und abgeschlossene Daten für das Reporting behalten.
Wie Tasks in Sprints gelangen, sie verlassen oder überspringen
Sprints erscheinen in fünf Anzeigezuständen: Current, Upcoming, Planned, Completed und Canceled. Abgeschlossene und abgebrochene Sprints wandern ins Space-Archiv, statt die aktive Planungsliste zu verstopfen.
Du fügst einen Task über sein Sprint-Feld, aus einer Task-Liste oder während der Sprint-Planung hinzu bzw. verschiebst ihn dort. Zwei Regeln sind wichtiger, als sie aussehen.
Erstens: Ein Task kann gar keinen Sprint haben. Das ist der normale Ort für Backlog-Arbeit und für Tasks, die keinem Zeitfenster zugesagt sind.
Zweitens: Einen Task zu einem Sprint hinzuzufügen, ändert seinen Status nicht. Diese Regel müssen Hybrid-Teams verinnerlichen, denn in Sharkly ist die Statuskategorie Backlog ein Parkzustand: Einen Task anzulegen oder einen Agent zuzuweisen, während der Task im Backlog liegt, startet keine Ausführung. Erst wenn der Task aus dem Backlog in einen bereiten Status verschoben wird, kann der zugewiesene Agent loslegen. Sprint-Planung und Freigabe der Ausführung sind also zwei getrennte Hebel. Du kannst den ganzen Sprint am Montag planen, mit bereits zugewiesenen Agents, und es läuft nichts, bis jeder Task bewusst in einen bereiten Status verschoben wird. Statuswechsel-Automations können dann die Übergänge übernehmen, die du standardisieren möchtest.
Eine weitere Regel schützt deine Historie: Nur abgeschlossene Tasks können einem früheren Sprint hinzugefügt werden. Das erlaubt historische Korrekturen, ohne je unerledigte Arbeit in einen abgeschlossenen Zeitraum zu legen.
Zu den Daten: Bei einem geplanten Sprint sind Start und Ende bearbeitbar, bei einem aktiven Sprint ist der Start fix, das Ende kann aber geändert werden.
Was dir das Sprint-Reporting verrät
Das Sprint-Reporting umfasst Task-Anzahlen und – wenn im Space Schätzungen aktiviert sind – Summen von Schätzpunkten über sechs Kennzahlen: Umfang, begonnene Arbeit, abgeschlossene Arbeit, Abschlussrate, Kapazität und Burnup-Verlauf.
Die Kapazität verdient einen genaueren Blick, denn auf dieser Zahl verankern sich Planungsgespräche. Sharkly leitet sie aus der Velocity kürzlich abgeschlossener Sprints ab, sofern genügend Historie vorhanden ist, und weicht ansonsten auf eine Schätzung anhand der Space-Größe aus. Die Doku empfiehlt, sie als Planungsgrundlage und nicht als Garantie zu behandeln – und für ein Hybrid-Team ist dieser Vorbehalt kein Standardsatz: Eine Velocity, die auf einer rein menschlichen Gruppe gemessen wurde, sagt nichts mehr voraus, sobald du drei Agents hinzufügst. Der Burnup-Verlauf ist oft aufschlussreicher. Wird der Umfang in einem frühen Schub abgearbeitet und verläuft die Linie danach flach, haben deine Agents mit der Ausführung fertig, während deine Reviewer den Rest des Sprints mit Aufholen verbringen.
Die Einschränkung im Hybrid-Team: Plane das Review, nicht die Ausführung
Alles in diesem Abschnitt ist ein Planungsargument, kein Produktmerkmal. Sharkly liefert dir die oben beschriebene Sprint-Mechanik; wie du den Sprint belädst, ist eine Ermessensfrage.
Beginne bei der Arbeitsteilung. Agents recherchieren, führen aus, testen und berichten. Personen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Beim agentic Coding lässt sich alles zwischen Richtungsvorgabe und Abnahme delegieren – die Abnahme bleibt menschlich. Ein Agent, der einen Task abschließt, hat ihn in keinem Sinne fertiggestellt, den dein Sprint zählen sollte: Diff, Verifikationsergebnisse und bekannte Grenzen landen wieder am Task, und ein Mensch muss sie lesen und abnehmen, Änderungen anfordern oder über den Merge entscheiden.
Jetzt rechne nach. Angenommen, ein fünfköpfiges Team führt Agents ein und der Ausführungsdurchsatz verdreifacht sich. Der Review-Durchsatz hat sich nicht verdreifacht; dieselben fünf Personen tragen ihn, und jede abgenommene Änderung kostet echte Aufmerksamkeit. Planst du den Sprint an der Ausführungskapazität, wird der Überschuss nicht zu ausgeliefertem Wert. Er wird zu einer Warteschlange ungelesener Arbeit – und eine ungelesene Änderung ist Bestand, kein Fortschritt. Schlimmer noch: Ein zu Ende gehender Sprint drängt Reviewer genau zu der Abkürzung, die agentenlastige Entwicklung gefährlich macht: Output abnehmen, ohne ihn zu lesen.
Dreh also die Planungsfrage um. Statt zu fragen, wie viel Arbeit das Team in zwei Wochen ausführen kann, frage, wie viel fertige Agent-Arbeit deine Leute in zwei Wochen abnehmen können. In der Praxis ändert das vier Gewohnheiten:
- Schätze die Review-Kosten, nicht nur die Baukosten. Ein Task, den ein Agent mühelos ausführt, kann trotzdem teuer abzunehmen sein.
- Begrenze die parallel fertige, aber noch nicht abgenommene Arbeit. Entscheide, wie viele Tasks jede Reviewerin pro Sprint wirklich abnehmen kann, und plane nicht über diese Summe hinaus. Das ist eine Teamvereinbarung und keine Sharkly-Einstellung, aber die Abschlusskennzahlen zeigen dir, wenn du zu weit gegangen bist.
- Gib die Ausführung bewusst frei. Weil das Backlog die Ausführung parkt, kannst du Starts staffeln, sodass fertige Arbeit in einem Tempo eintrifft, das Reviewer verkraften – statt alles auf einmal an Tag zwei.
- Lies die Abschlussrate als Review-Kennzahl. Wenn das Burnup flach wird, während Agents untätig sind, hat sich der Engpass selbst gemeldet. Das ist ein Signal, mehr Reviewer einzubinden oder weniger zuzusagen – nicht, mehr Agents hinzuzufügen.
Nichts davon bremst die Agents. Es richtet sie aus. Ein Sprint, der um den Abnahme-Durchsatz herum geplant ist, liefert alles aus, was er zusagt, und verlangt nie, dass jemand Code freigibt, für dessen Lektüre keine Zeit war.
Einen hybriden Sprint planen – Schritt für Schritt
- Aktiviere Sprints für den Space und wähle einen Modus. Ein gleichmäßiger Team-Rhythmus spricht für den automatischen Rhythmus, release-getriebene Arbeit für den manuellen Modus.
- Form den Umfang. Zieh Kandidaten-Tasks über die Sprint-Planung oder das Sprint-Feld in den bevorstehenden Sprint. Arbeit, auf die du dich nicht festlegen willst, bleibt ohne Sprint.
- Besetze beide Hälften jedes Tasks. Sharkly trennt menschliche Verantwortung von der Agent-Ausführung: Personen kommen in die Gruppe der Zugewiesenen, ein Agent oder eine Crew in den einzelnen Ausführungsplatz. Eine Änderung an der einen Seite ändert nie die andere.
- Schreib Tasks, mit denen ein Agent etwas anfangen kann. Die Beschreibung sollte Ziel, Rahmenbedingungen und Abnahmekriterien enthalten, die eine neue Person oder ein Agent zum Weiterarbeiten braucht.
- Gib Arbeit im Review-Tempo frei. Verschiebe Tasks aus dem Backlog, sobald Reviewer-Kapazität frei wird.
- Schließ bewusst ab. Im manuellen Modus entscheidest du, wohin jeder unerledigte Task wandert. Im automatischen Rhythmus prüfst du, was weitergetragen wurde, und fragst dich, ob der Umfang zu groß war oder zu langsam reviewt wurde.
Die weitergehende Disziplin, Arbeit so zu steuern, behandelt unser Grundlagenartikel zu AI-Agent-Projektmanagement; der Sprint ist der zeitlich begrenzte Ausschnitt dieses Systems.
Wenn deine Sprints heute in Jira leben
Du musst deinen Prozess nicht neu aufbauen, um das alles auszuprobieren. Sharklys Jira-Integration kann Jira-Sprint-Daten importieren, und wenn der Sprint-Import aktiviert ist, lässt sich der Ziel-Space auf den Jira-Sprint-Modus umstellen, sodass der Rhythmus, den dein Team bereits fährt, übernommen wird statt bei null zu beginnen. Die Anleitung zum Zuweisen eines Jira-Tickets an einen AI Agent zeigt dieselbe Idee auf der Ebene eines einzelnen Tickets, und die Sharkly-Doku behandelt die Sprint-Konfiguration und die Jira-Integration ausführlich.
Fang kleiner an als mit einer Migration: Aktiviere Sprints in einem Space, plane ein Zwei-Wochen-Fenster entlang der tatsächlichen Abnahmekapazität deiner Reviewer und vergleiche das Burnup mit deinem letzten rein menschlichen Zyklus.
FAQ
Muss ich Sprints in Sharkly überhaupt nutzen?
Nein. Sprints sind optional und werden pro Space aktiviert. Ein Space, der kontinuierlichen Flow bevorzugt, kann sie komplett ausgeschaltet lassen, und selbst mit aktivierten Sprints kann ein Task gar keinen Sprint haben – der Normalzustand für Backlog-Arbeit.
Was passiert mit unerledigten Tasks am Ende eines Sprints?
Im automatischen Rhythmus schließt Sharkly den Sprint planmäßig ab und trägt unerledigte Arbeit in den nächsten weiter. Im manuellen Modus fragt dich der Abschlussablauf, wohin unerledigte Tasks gehen sollen: in keinen Sprint, in einen anderen aktiven oder bevorstehenden Sprint oder in einen neu angelegten Sprint.
Können Agents automatisch an Sprint-Tasks arbeiten?
Ein Agent oder eine Crew, die als Ausführungs-Zugewiesene eines Tasks festgelegt sind, können die Arbeit erledigen – aber die bloße Zugehörigkeit zu einem Sprint startet nie etwas. Backlog ist ein Parkzustand, das Zuweisen eines Agents zu einem Backlog-Task beginnt also keine Ausführung; erst das Verschieben des Tasks in einen bereiten Status kann den Lauf starten. Diese Trennung erlaubt es, zuerst einen kompletten Sprint zu planen und die Ausführung dann in dem Tempo freizugeben, das deine Reviewer verkraften.
Wie berechnet Sharkly die Sprint-Kapazität?
Die Kapazität nutzt die Velocity kürzlich abgeschlossener Sprints, sofern genügend Historie vorhanden ist, und weicht ansonsten auf eine Schätzung anhand der Space-Größe aus. Die Doku rät, sie als Planungsgrundlage und nicht als Garantie zu betrachten – was für Hybrid-Teams doppelt gilt, denn dort misst die Velocity das Gesamtsystem und nicht den Review-Engpass darin.
Kann ich einen Task zu einem bereits beendeten Sprint hinzufügen?
Nur abgeschlossene Tasks können einem früheren Sprint hinzugefügt werden. Das unterstützt historische Korrekturen, etwa das Nachtragen von Arbeit, die im Zeitfenster fertig wurde, aber nie erfasst wurde – ohne je unerledigte Arbeit in einen abgeschlossenen Zeitraum zu legen.
