Die Sprint-Planung (Sprint Planning) gehört zu den zeitaufwändigsten Zeremonien in der agilen Softwareentwicklung. Projektleiter, Scrum Master und technische Führungskräfte verbringen regelmäßig Stunden damit, vage Anforderungen in ein sauberes, sofort umsetzbares Sprint-Backlog zu überführen. Der manuelle Aufwand ist beträchtlich: technische Machbarkeiten und Wettbewerbslösungen recherchieren, User Stories nach dem INVEST-Prinzip verfassen, formale Akzeptanzkriterien in Gherkin-Syntax (Gegeben / Wenn / Dann) formulieren, Stories in technische Entwicklungsaufgaben zerlegen und jede Karte mitsamt Schätzungen händisch auf einem Kanban-Board anlegen.
Viele Teams versuchen, diesen Ablauf durch einfache Prompts in universellen KI-Chatbots zu beschleunigen. In der Praxis stoßen Ein-Prompt-Lösungen jedoch rasch an ihre Grenzen: Es fehlt an organisationsspezifischem Kontext wie Architekturrichtlinien oder bisheriger Team-Velocity, der Kontextraum wird schnell überlastet, und am Ende bleibt unstrukturierter Fließtext, der dennoch manuell in Projektmanagement-Tools übertragen werden muss.
Taskade löst dieses Problem durch die nahtlose Bündelung von benutzerdefinierten autonomen Agenten, wissensbasierten Datenbanken (Knowledge Base), koordinierter Multi-Agenten-Zusammenarbeit (AI Agent Teams) und nativen Kanban-Ansichten in einem einzigen Workspace. Diese Anleitung erläutert Schritt für Schritt, wie Sie in Taskade ein spezialisiertes KI-Agenten-Team aufbauen, das selbstständig Recherchen anstellt, Anforderungen präzisiert, technische Teilaufgaben ableitet und Kanban-Karten automatisch befüllt.
Die Multi-Agenten-Sprint-Architektur: Rollen und Aufgabenverteilung
Ein praxistaugliches Multi-Agenten-System versucht nicht, alle Aufgaben einem einzelnen Allround-Bot aufzubürden. Stattdessen bildet es die Arbeitsteilung eines eingespielten Entwicklerteams ab und trennt Aufgaben entlang klarer Kontextgrenzen. In Taskade richten Sie hierfür ein vierköpfiges Agenten-Team ein:
[ Agiles Epic / Sprint-Ziel ]
│
▼
┌───────────────────────┐
│ Sprint-Lead-Agent │ ◄─── Agile Vereinbarungen, Velocity & DoD
│ (Orchestrator) │
└──────────┬────────────┘
│ Plant und delegiert
▼
┌───────────────────────┐
│ Recherche-Agent │ ◄─── Websuche, API-Dokumentation, Machbarkeit
│ (Spezialist) │
└──────────┬────────────┘
│ Strukturierte Rechercheergebnisse
▼
┌───────────────────────┐
│ Story-Architekt │ ◄─── INVEST-Standard, Personas, PRDs
│ (Spezialist) │
└──────────┬────────────┘
│ INVEST-Stories & Gherkin-Kriterien
▼
┌───────────────────────┐
│ Aufgaben- & QA-Agent │ ◄─── Architekturrichtlinien, Testkriterien
│ (Spezialist) │
└──────────┬────────────┘
│ Entwicklungsaufgaben, Story Points, Tags
▼
┌───────────────────────┐
│ Taskade-Kanban-Board │ ─── Backlog-Spalte (Karten, Fälligkeiten, Checklisten)
└───────────────────────┘
1. Sprint-Lead-Agent (Der Orchestrator)
- Aufgabe: Fungiert als Koordinator des Teams. Er analysiert die Geschäftsziele, verteilt Teilaufgaben an die spezialisierten Agenten, gleicht Zwischenstände mit der Definition of Ready (DoR) und der Definition of Done (DoD) ab und bringt das Endergebnis in das gewünschte Kanban-Format.
- Wissensbasis: Bisherige Velocity-Metriken, agile Vereinbarungen, Regeln zur Sprint-Dauer, DoR- und DoD-Vorgaben.
- Werkzeuge: Team-Orchestrierung und Projektverwaltung in Taskade.
2. Technik- und Marktrecherche-Agent (Der Spezialist)
- Aufgabe: Untersucht technische Restriktionen, evaluiert Open-Source-Bibliotheken, analysiert Implementierungen von Mitbewerbern und sichtet offizielle API-Dokumentationen.
- Wissensbasis: Architekturdiagramme, Tech-Stack-Spezifikationen, Verzeichnis technischer Schulden.
- Werkzeuge: Websuche (Web Search), Web-Scraping und Dokumentenanalyse.
3. User-Story-Architekt (Der Spezialist)
- Aufgabe: Überführt Rohideen und technische Recherchen in standardisierte INVEST-User-Stories (
Als... möchte ich... um...) und formuliert präzise Akzeptanzkriterien nach Gherkin (Gegeben sei... Wenn... Dann...). - Wissensbasis: PRD-Vorlagen, Zielgruppen-Personas, historische Feature-Spezifikationen.
- Werkzeuge: Abfrage interner Workspace-Wissensbestände.
4. Aufgabenzerlegungs- und QA-Agent (Der Spezialist)
- Aufgabe: Spaltet geprüfte User Stories in modulare Entwicklungsaufgaben (Frontend, Backend, DevOps, QA) auf, schätzt Story Points anhand der Fibonacci-Folge, dokumentiert Abhängigkeiten und definiert Kriterien für Regressionstests.
- Wissensbasis: Repository-Strukturen, Code-Konventionen, Test-Checklisten.
- Werkzeuge: Verwaltung von Projektlisten.
Schritt-für-Schritt-Anleitung zur Konfiguration in Taskade
Die Einrichtung erfolgt direkt in Ihrem Taskade-Workspace und gliedert sich in fünf aufeinander aufbauende Schritte.
Schritt 1: Erstellung und Schärfung der einzelnen KI-Agenten
Um Instruktionskonflikte zu vermeiden, wird jeder Agent mit einem klar umrissenen Profil angelegt:
- Öffnen Sie Ihren Taskade-Workspace und klicken Sie in der oberen Menüleiste auf den Reiter Agents.
- Klicken Sie auf Create Agent.
- Definieren Sie Identität und Persona:
- Vergeben Sie aussagekräftige Namen und Symbole (z. B.
Sprint Orchestrator,Tech Researcher,User Story Architect,Engineering QA Estimator). - Legen Sie die Rolle fest (z. B. Senior Agile Delivery Lead).
- Vergeben Sie aussagekräftige Namen und Symbole (z. B.
- Hinterlegen Sie präzise Systemanweisungen (System Instructions):
- Beispiel für den User-Story-Architekten:
Du bist Principal Agile Analyst. Deine einzige Aufgabe besteht darin, Anforderungen und technische Recherchen in INVEST-konforme User Stories zu übertragen. Formuliere alle Akzeptanzkriterien ausnahmslos in strikter Gherkin-Syntax (Gegeben sei / Wenn / Dann). Identifiziere Grenzfälle, Fehlerpfade und nicht-funktionale Anforderungen. Erstelle keinen Code und keine detaillierten Entwicklungsaufgaben; überlasse dies dem QA- und Schätz-Agenten. - Beispiel für den Aufgabenzerlegungs- und QA-Agenten:
Du bist Lead Software Architect und QA Lead. Du nimmst freigegebene User Stories entgegen und zerlegst sie in unabhängige Entwicklungsaufgaben. Kategorisiere jede Aufgabe nach Frontend, Backend, DevOps oder QA. Verwende für Story Points die Fibonacci-Reihe (1, 2, 3, 5, 8). Weist eine Aufgabe mehr als 8 Punkte auf, fordere eine weitere Aufspaltung. Definiere für jeden Posten explizite Vorbedingungen und Kriterien für Regressionstests.
- Beispiel für den User-Story-Architekten:
Schritt 2: Verknüpfung der internen Wissensdatenbanken (Knowledge)
Ohne Zugriff auf unternehmensinterne Daten kann ein Agent lediglich allgemeine Empfehlungen geben. Mit der Knowledge-Funktion von Taskade verankern Sie reales Projektwissen:
- Wechseln Sie in den Agenten-Einstellungen auf den Reiter Knowledge.
- Laden Sie die passenden Dokumente hoch:
- Sprint-Lead: Agile Richtlinien des Teams, DoR/DoD-Kriterienkataloge, Maßnahmen aus vorangegangenen Retrospektiven.
- Recherche-Agent: Aktuelle Architekturübersichten, Tech-Stack-Vorgaben, Links zu relevanten API-Quellen.
- Story-Architekt: Produkt-Roadmaps, Nutzerinterviews und freigegebene PRDs.
- Taskade unterstützt PDF-, DOCX-, Markdown- und Textdateien sowie Web-URLs und bestehende Taskade-Projekte. Über die Aktion Add Project to Agent Knowledge in Taskade Automations lässt sich neues Projektwissen bei Fertigstellung automatisch in die Agenten-Wissensbasis übernehmen.
Schritt 3: Werkzeugzuweisung und Sicherheitsberechtigungen
Agenten in Taskade können externe Werkzeuge nutzen. Diese sollten jedoch sparsam und gezielt vergeben werden:
- Öffnen Sie den Reiter Tools im Editor des jeweiligen Agenten.
- Aktivieren Sie für den Recherche-Agenten die Optionen Web Search und Web Scraping, damit dieser eigenständig Bibliotheken und Dokumentationen prüfen kann.
- Bei Aktionen mit externen Schreibzugriffen (z. B. Benachrichtigungen via Slack oder Webhook-Ausführungen über MCP-Konnektoren) sollte Human-in-the-Loop aktiviert bleiben. Der Agent erarbeitet dann zunächst einen Vorschlag, der erst nach menschlicher Bestätigung ausgeführt wird.
- Für rein textbasierte Analyse-Agenten (wie den Story-Architekten) bleiben externe Werkzeuge deaktiviert, um Kontext zu sparen und Latenzen zu minimieren.
Schritt 4: Zusammenstellung des Teams und Wahl des Orchestrierungsmodus
Führen Sie die vier Spezialisten zu einem funktionierenden Team zusammen:
- Klicken Sie in der linken Seitenleiste auf AI Teams und wählen Sie Create Team.
- Fügen Sie die vier konfigurierten Agenten hinzu.
- Wählen Sie den passenden Orchestrierungsmodus (Orchestration Mode):
- Orchestrate-Modus (Empfohlen für Sprints): Der Sprint-Lead nimmt das Vorhaben entgegen, strukturiert die Teilziele, delegiert die Recherche, reicht die Fakten an den Story-Architekten weiter, leitet den Entwurf an den QA-Schätzer und führt alle Ergebnisse zusammen.
- Sequential-Modus: Eine feste Kette (Recherche -> Stories -> Aufgaben -> Review), ideal für bereits weitgehend definierte Anforderungen.
- Auto-Modus: Die Plattform wählt dynamisch einen einzelnen passenden Agenten für eine Frage aus.
- Everyone-Modus: Alle Agenten antworten parallel; hilfreich für initiale Risikoanalysen, jedoch zu unübersichtlich für ein sauberes Backlog.
Schritt 5: Direkte Übernahme in Taskade-Kanban-Boards
Die strukturierten Ergebnisse müssen nahtlos in ausführbare Aufgaben auf dem Kanban-Board überführt werden:
- Erstellen Sie ein neues Projekt in Taskade und wählen Sie die Ansicht Board (Kanban).
- Richten Sie die typischen Arbeitsspalten ein:
Sprint Backlog,Bereit für Dev,In Bearbeitung,QA / ReviewundErledigt. - Rufen Sie das Team im Projekt-Chat über
@AI Teamauf oder nutzen Sie den Automatisierungsschritt Ask Agent Team. - Weisen Sie das Team an, die Ausgabe im nativen, hierarchischen Taskade-Markdown-Format zu liefern:
- [ ] [FEAT-201] PDF- und CSV-Export für das Analyse-Dashboard implementieren - Beschreibung: Ermöglicht Nutzern den tabellarischen und grafischen Export von Kennzahlen nach Zeitraum. - Akzeptanzkriterien: Gegeben sei ein geladenes Dashboard, Wenn der Nutzer auf "CSV exportieren" klickt, Dann startet der Browser einen Streaming-Download ohne Zeichensatzfehler. - Teilaufgaben: - [ ] Backend: Streaming-CSV-Endpunkt mittels PostgreSQL-Cursor entwickeln #backend #estimate:3 - [ ] Frontend: Export-Modal und Ladebalken integrieren #frontend #estimate:2 - [ ] QA: Last- und Timeout-Tests bei Datensätzen mit mehr als 100.000 Zeilen durchführen #qa #estimate:2 - In Taskade verwandelt sich dieser eingerückte Block mit wenigen Klicks in Kanban-Karten: Die Hauptebene wird zur Karte, eingerückte Unterpunkte werden zu internen Checklisten, und Tags (
#backend) sowie Schätzwerte werden automatisch in benutzerdefinierte Felder übernommen.
Praxisbeispiel: Vom vagen Epic zur fertigen Kanban-Karte
Folgender Ablauf veranschaulicht das Zusammenspiel in der Praxis:
Der Eingabeprompt des Projektleiters
Projektleiter:
„@Sprint Orchestrator Team: Bitte plant Sprint 24 für das Epic 'Export von Analysedaten als PDF und CSV'.
Technischer Kontext: React im Frontend, Node.js im Backend, PostgreSQL-Datenbank. Sowohl Sofort-Downloads als auch asynchrone Hintergrundverarbeitung für große Berichte werden benötigt.
Führt eine Recherche zu Speicherbegrenzungen bei großen Exporten durch, formuliert User Stories mit Gherkin-Kriterien, zerlegt die Aufgaben inklusive Story Points und liefert die fertige Struktur für unser Kanban-Board.“
Autonome Multi-Agenten-Zusammenarbeit
- Phase 1 (Lead strukturiert): Der
Sprint Orchestratorprüft die Anforderungen gegen die Definition of Ready und beauftragt denTech Researchermit der Analyse von Node.js-Exportbibliotheken und Speicherengpässen. - Phase 2 (Recherche liefert Fakten): Der
Tech Researcherstellt fest:- Clientseitiger Export eignet sich nur für Tabellen unter 50 Zeilen.
- Serverseitige PDF-Erzeugung mit Headless-Browsern erfordert aufgrund des hohen Arbeitsspeicherbedarfs eine asynchrone Job-Queue (z. B. BullMQ).
- CSV-Exporte müssen per PostgreSQL-Cursor gestreamt werden, um Out-of-Memory-Abstürze zu verhindern.
- Phase 3 (Story-Architekt formuliert): Der
User Story Architectnutzt diese Erkenntnisse und erstellt zwei Kern-Stories:- US-1: Direkter Streaming-CSV-Export aus der Dashboard-Tabelle.
- US-2: Asynchrone PDF-Erstellung mit Bereitstellung eines Download-Links.
- Er ergänzt vollständige Given-When-Then-Kriterien inklusive Netzwerkabbrüchen und Leerdaten-Zuständen.
- Phase 4 (QA-Agent zerlegt und schätzt): Der
Engineering QA Estimatorspaltet die Stories in 7 unabhängige Entwicklungs- und Testaufgaben auf, vergibt insgesamt 13 Story Points und benennt Kriterien für Regressionstests. - Phase 5 (Lead konsolidiert): Der
Sprint Orchestratorgleicht das Gesamtpaket mit den Qualitätskriterien ab und liefert den hierarchischen Markdown-Block an den Projektleiter aus.
Der Projektleiter prüft die Aufstellung kurz und schiebt die Karten mit einem Klick in die Spalte Sprint Backlog.
Architekturprinzipien und typische Fallstricke
Unstrukturierte Multi-Agenten-Systeme können schnell hohe Token-Kosten verursachen oder unbrauchbare Ergebnisse liefern. Beachten Sie folgende Richtlinien:
| Prinzip | Empfohlene Vorgehensweise | Zu vermeidender Fallstrick |
|---|---|---|
| Kontextgrenzen wahren | Agenten nach Fachkontext trennen (z. B. Recherche getrennt von QA-Spezifikation). | Aufteilung in zu viele rein sequentielle Mikroschritte, bei denen vollständige Chatverläufe hin- und hergeschickt werden, was Token-Kosten um das 3- bis 10-fache steigert. |
| Lesen und Schreiben trennen | Leseaufgaben (Recherchen, Code-Analysen) parallelisieren; Schreibaufgaben (Backlog-Karten erstellen) zentral über den Lead bündeln. | Mehrere Agenten gleichzeitig schreibend auf dasselbe Board zugreifen lassen, was zu Duplikaten und Datenkonflikten führt. |
| Gezielte Übergaben (Handoffs) | Bei der Übergabe nur drei Dinge übermitteln: offenes Ziel, komprimierte Fakten und erwartetes Ausgabeformat. | Vollständigen Chatverlauf unreflektiert weitergeben (Transcript Dump), was zu Kontextüberlastung und Informationsverlust führt. |
| Menschliche Kontrolle | Vor der endgültigen Übernahme ins Board eine menschliche Prüfstufe (Human-in-the-Loop) beibehalten. | Vollkommene Autonomie ohne Review, wodurch ungeprüfte Aufgabenkarten das Board überfluten. |
Preismodelle, Modellwahl und AI-Credits
Der Betrieb von Agenten-Teams erfordert regelmäßige Modellaufrufe. Eine transparente Kostenplanung stützt sich auf die Tarifstruktur von Taskade:
- Tarifstufen in Taskade:
- Free: 2 Plätze, grundlegende Agenten und ein Basiskontingent an AI-Credits; ideal für Evaluierungen.
- Pro (10 USD/Monat bei jährlicher Zahlung): 10 Plätze und erweitertes monatliches AI-Guthaben; passend für einzelne agile Teams.
- Business (25 USD/Monat bei jährlicher Zahlung): Unbegrenzte Nutzerzahl, großzügiges Credit-Volumen und vollständige Multi-Agenten-Automatisierung; der Standard für wachsende Produktteams.
- Max (100 USD/Monat) und Enterprise (250 USD/Monat): Für hohe Arbeitsvolumina mit vorrangigem Zugriff auf fortschrittliche Reasoning-Modelle, SSO-Anbindung und Bring-Your-Own-Key-Optionen (BYOK).
- Modellabstimmung nach Aufgabentyp:
- Für Standardaufgaben wie Gherkin-Formatierung oder Verschlagwortung genügen schlanke Modelle (TSK-Instant / TSK-Standard), die schnell arbeiten und nur minimale Credits verbrauchen.
- Für die übergeordnete Zielzerlegung und die Abschlussprüfung durch den Sprint-Lead empfiehlt sich ein tiefenschärferes Modell (TSK-Reasoning).
Fazit
Manuelle Sprint-Planungen binden wertvolle Kapazitäten an rein administrative Aufgaben. Durch den Aufbau eines vierköpfigen KI-Agenten-Teams in Taskade:
- Bleibt aufwändige technische Recherche in isolierten Kontextfenstern gekapselt, ohne den Hauptarbeitsfluss zu belasten.
- Entstehen für jedes Feature einheitliche INVEST-User-Stories mit formalen Gherkin-Kriterien.
- Werden geschätzte und verschlagwortete Aufgaben direkt in das native Taskade-Kanban-Board übertragen.
- Behalten Projektleiter die volle Entscheidungsbefugnis, während sich der Zeitaufwand für die Vorbereitung von Stunden auf wenige Minuten reduziert.
Richten Sie spezialisierte Agenten ein, füttern Sie diese mit Ihren Projektrichtlinien und verwandeln Sie unklare Anforderungen in verlässliche, entwicklungsbereite Arbeitskarten.