LoopsWork
Interactive Guide
LOOPSWORK IN DER PRAXIS

Jira steuert die Arbeit. Confluence hält das Wissen. KI-Agenten helfen bei der Umsetzung.

LoopsWork benötigt kein eigenes Tool. Das Framework verbindet vorhandene Systeme so, dass aus einer gewünschten Wirkung kleine umsetzbare Specs entstehen, Änderungen überprüft werden und neue Erkenntnisse wieder in die Arbeit zurückfließen.

Mit Jira, Jira Product Discovery und Confluence lässt sich dieser Kreislauf direkt abbilden. KI-Agenten können zusätzlich Recherche, Planung, Umsetzung, Prüfung und Analyse übernehmen.

JiraConfluenceAI Agents

Tool-agnostisch

LoopsWork definiert Arbeitsprinzipien, keine Software. Jira und Confluence zeigen hier beispielhaft, wie diese Prinzipien mit bestehenden Tools umgesetzt werden können. Das KI-Framework für Softwareentwicklung bleibt technologieunabhängig.

LoopsWork legt keinen neuen Prozess über Jira. Es verbindet bestehende Werkzeuge so, dass Build Loop, Value Loop und Learning Loop sichtbar miteinander verbunden werden.

01 / ZIELBILD

Ein System – drei Loops

JIRA

Build Loop

Spec → Slice → Umsetzung → Review → Release

Review-Ergebnisse verbessern die Spec.
JPD + JIRA

Value Loop

Outcome → Messung → Ergebnis → Entscheidung

Wirkung verändert Prioritäten und neue Arbeit.
CONFLUENCE

Learning Loop

Learning → Experiment → Decision → neuer Kontext

Erkenntnisse verbessern die nächsten Specs.
Die Loops laufen parallel und geben einander Rückmeldung. Ein Release startet die Wirkungsmessung; es beendet das Lernen nicht.
Menschen entscheiden
Jira / Confluence KI-Agenten
Code / Systeme
02 / JIRA PRODUCT DISCOVERY

Erst Wirkung, dann Arbeit

Eine LoopsWork-Initiative beginnt nicht mit einer Feature-Liste, sondern mit einem gewünschten Ergebnis.

Jira Product Discovery bildet damit die Ebene oberhalb der eigentlichen Umsetzung: Ein Vorhaben verknüpft das gewünschte Outcome mit der Delivery-Arbeit in Jira.

  1. Outcome
  2. Initiative
  3. Specs

Die Felder sind ein möglicher Kartenaufbau. Outcomes und Initiativen müssen keine zusätzlichen Jira-Hierarchieebenen sein.

Initiative · Illustratives Beispiel

Checkout vereinfachen

Problem
Kunden brechen den Checkout zu häufig ab.
Desired Outcome
Checkout-Abbruchquote reduzieren.
Baseline / Target
12,4 % → < 10 %
Confidence / Investment
Medium / M
Messprüfpunkt
14 Tage nach Release
03 / ARBEITSAUFTRAG

Die Spec ist der Arbeitsauftrag

Die zentrale Arbeitseinheit von LoopsWork ist die Spec. Sie beschreibt nicht nur, was verändert werden soll, sondern auch warum, unter welchen Bedingungen und woran später erkannt wird, ob die Änderung erfolgreich war. Specification Driven Development liefert dafür die gemeinsame Vereinbarung zwischen Menschen und Agenten.

LW-142 · Spec · BeispielReady

Express Checkout

Outcome
Mehr Kunden schließen den Checkout erfolgreich ab.
Change
Gespeicherte Adressdaten können übernommen werden.
Acceptance Examples
Given ein eingeloggter Kunde
When der Checkout geöffnet wird
Then wird seine gespeicherte Adresse vorausgewählt.
Constraints
Gastbestellung nicht verändern · bestehende Payment-Schnittstelle beibehalten
Relevant Context
Customer Profile API · DEC-023 · Checkout Architecture
Expected Value
Checkout-Abbruchquote von 12,4 % auf unter 10 %
Reliability & Observability · optional
Kritikalität · Monitoring · Alert wenn · SLO / erwartete Verfügbarkeit (optional) · Verhalten bei Ausfall · Dashboard / Tool (optional). Für unkritische Änderungen klein halten oder weglassen. Geführte Vorlage öffnen
Messung / Prüfpunkt
Checkout Funnel / 14 Tage nach Release

Die Initiative hat ein gemeinsames Wirkungsziel. Einzelne Specs leisten einen Beitrag; sie versprechen nicht jede für sich die gesamte Verbesserung.

04 / SPECS SCHNEIDEN

Small Specs, Small Context

Je größer eine Aufgabe wird, desto größer wird auch der Kontext, den Menschen und KI-Agenten verstehen müssen. LoopsWork versucht deshalb, Arbeit in möglichst kleine, eigenständig umsetzbare Specs oder Slices zu schneiden.

Große SpecViel Kontext · hohe Komplexität · potenziell höhere AI-Kosten
↓ Fachlich sinnvoll schneiden
Slice A · Adresse ladenAPI + Fehlerfälle
Slice B · Adresse auswählenUI + Akzeptanzbeispiele
Slice C · Wirkung messenFunnel + Datenqualität
Jeder Auftrag bekommt passenden Kontext. Gemeinsame Schnittstellen und Abhängigkeiten bleiben sichtbar.

Weniger Kontext

Agenten erhalten nur die Informationen, die sie für die Aufgabe wirklich benötigen.

Bessere Ergebnisse

Kleine Aufgaben lassen sich präziser beschreiben, umsetzen und prüfen.

Geringere Kosten

Gezielte Kontextauswahl kann Token- und Verarbeitungsaufwand senken. Zusätzliche Agentenläufe und Koordination zählen mit.

Schnelleres Feedback

Kleine Änderungen sind früher überprüfbar und gelangen schneller durch Build Loop und Value Loop.

Klein ist kein Selbstzweck: Ein Slice braucht einen klaren Auftrag und eine eigenständige Prüfung. Sub-Tasks helfen beim Schneiden, wenn sie auch den tatsächlichen Agentenauftrag begrenzen. Im Warenkorb-Beispiel ansehen.

05 / JIRA-HIERARCHIE

Klare Struktur für Initiativen, Specs und Slices

InitiativeGewünschte Wirkung

Spec · Adresse übernehmen

Fachlich abgegrenzte Veränderung

  • Slice · API-Anbindung
  • Slice · Vorauswahl

Spec · Funnel beobachten

Fachlich abgegrenzte Veränderung

  • Slice · Ereignisse erfassen
  • Slice · Auswertung prüfen

Die Initiative beschreibt die Wirkung, die Spec eine abgegrenzte Veränderung und der Slice die kleinste sinnvoll umsetzbare Arbeitseinheit. Bug, Experiment und Task können ergänzend bestehen bleiben.

Bestehende Jira-Typen reichen oft aus.

Zum Beispiel: JPD-Idee mit verknüpftem Epic, Specs als Stories oder Tasks und Slices als Sub-Tasks. Die konkrete Zuordnung hängt von Eurer Jira-Konfiguration ab. LoopsWork braucht keine eigenen Tickettypen für jede Eventualität. Jira hat auch ohne Hilfe schon genug Möglichkeiten, einen Ticket-Zoo aufzubauen.

06 / WORKFLOW

Nach dem Release: Wirkung prüfen

  1. Draft
  2. Ready
  3. Building
  4. Review
  5. Released
  6. Measuring
  7. Learned

Release → Wirkung prüfen

Eine Änderung ist technisch abgeschlossen, wenn die vereinbarten Qualitätskriterien erfüllt sind und sie kontrolliert ausgeliefert wurde. Bei kritischen Komponenten gehören notwendige Beobachtbarkeit, sinnvolle Alerts und geprüftes Fehlerverhalten dazu. Der Loop ist damit aber noch nicht geschlossen. Erst wenn überprüft wurde, welche Wirkung die Änderung tatsächlich hatte, entsteht Feedback.

  1. Expected Value
  2. Release
  3. Measurement
  4. Actual Value
  5. Entscheidung
✓ Wirkung bestätigt↻ Weiter beobachten△ Anpassung erforderlich✕ Wirkung nicht bestätigt

Das ist ein logischer Ablauf, kein vorgeschriebener Jira-Workflow. Measuring und Learned können auch in einem verknüpften Value-Review-Item oder in Feldern abgebildet werden. Rückmeldungen können jederzeit zur Spec oder zu einer neuen Hypothese führen.

Feedback Debt

Feedback Debt beschreibt ausgelieferte Änderungen, deren Wirkung noch nicht überprüft wurde.

Released Specs
24
Value checked
17
Feedback Debt
7

Eine wachsende Feedback Debt ist ein Warnsignal: Das Team produziert Änderungen schneller als es daraus lernt.

Beispieldaten derselben Kohorte. Zusätzlich prüfen: Wie alt sind die offenen Reviews, und welche sind bereits fällig?

An jeder ausgelieferten Spec stehen Review-Verantwortung, Prüfdatum und Evidence-Link. Im Value Review werden überfällige oder riskante Rückmeldungen priorisiert. Passende Evidence und eine dokumentierte Entscheidung schließen die Prüfung; ein Statuswechsel allein genügt nicht.

Zum Value Loop · Scorecard · Value Review

07 / CONFLUENCE

Confluence hält den Kontext, der bleiben soll

Operative Arbeit gehört nach Jira. Langlebiges Wissen gehört nach Confluence. Confluence ist gleichzeitig Wissensbasis für Menschen und KI-Agenten.

Space · LoopsWork
  • Team Context
  • Product Context
  • Architecture
  • Decisions
  • Experiments
  • Learnings
  • AI Context

Gebt dauerhaftem Kontext einen Owner und einen Aktualitätsstand. Verlinkt bestätigte Specs und Entscheidungen, statt dieselben Regeln mehrfach zu kopieren.

08 / DECISION LOG

Entscheidungen bleiben auffindbar

DEC-023 · Beispiel

Customer Profile bleibt Source of Truth

Context
Checkout benötigt zusätzliche Kundendaten.
Decision
Der Customer Profile Service bleibt Source of Truth.
Why
Keine doppelte Datenhaltung.
Consequences
Checkout verwendet die Profile API.

Specs verlinken nur den Kontext, den sie tatsächlich benötigen.

09 / LEARNING LOOP

Aus Ergebnissen entsteht neuer Kontext

Learning L-17 · Fiktive Messwerte

Bestandskunden profitieren besonders

Observation
Express Checkout verbessert Conversion hauptsächlich bei Bestandskunden.
Evidence
Bestandskunden: +4,2 % · Neukunden: +0,1 % relative Conversion-Veränderung im Beispiel
Learning
Der größte Reibungspunkt für Neukunden liegt wahrscheinlich vor dem Payment. Das ist eine neue Hypothese, kein bewiesener Befund.
Change
Neue Hypothese untersuchen; Vergleichbarkeit und Unsicherheit der Daten prüfen.
  1. Spec
  2. Change
  3. Result
  4. Learning
  5. Neue Hypothese
  6. Neue Spec
↻ Die Erkenntnis wird zum Kontext des nächsten Build Loops.
10 / AUSFÜHRUNG

Arbeit kann Menschen und Agenten zugewiesen werden

In klassischen Frameworks werden Aufgaben Rollen und Menschen zugeordnet. In KI-gestützter Entwicklung kommt eine weitere Frage hinzu: Wer führt die Arbeit aus – Mensch, Agent oder beide?

Human

Max
Der Mensch setzt die Aufgabe selbst um.

AI Agent

Copilot Backend Agent
Ein Agent bearbeitet eine klar definierte Spec oder einen Slice weitgehend selbstständig.

Hybrid Häufiger Praxisfall

Max + Copilot Backend Agent
Der Mensch behält die Verantwortung, der Agent übernimmt Teile der Ausführung.

Agentennamen bezeichnen hier beispielhafte Ausführungsprofile, keine automatisch vorhandenen Jira-Benutzer.

11 / VERANTWORTUNG

Menschen verantworten. Agenten führen aus.

LW-143 · Slice · Beispiel

Gespeicherte Adresse laden

Responsible Human
Max
Execution / Agent
AI Agent / Copilot Backend
Context
Customer Profile API · DEC-023 · Checkout Architecture

Allowed Actions

  • Code ändern
  • Tests erstellen
  • Pull Request erstellen
  • Jira kommentieren

Human Approval Required

  • Merge
  • Production Release

LoopsWork trennt bewusst Verantwortung und Ausführung. Ein Agent kann Arbeit übernehmen. Die Verantwortung bleibt bei einem Menschen.

Humans own decisions. Agents own tasks.Menschen verantworten Entscheidungen. Agenten übernehmen Arbeit.

Praktisch kann der Jira-Assignee die verantwortliche Person bleiben. Execution Mode und Execution Agent werden als Felder oder im Agentenauftrag geführt. Die gezeigten Freigaben sind Grenzen dieses Beispielauftrags.

12 / TECHNISCHE BRÜCKE

Jira-Kontext direkt für Coding-Agenten

Über den Atlassian Remote MCP Server können MCP-fähige KI-Systeme auf Jira- und Confluence-Kontext zugreifen. Damit muss der relevante Kontext nicht ständig manuell in Prompts kopiert werden.

Jira

Spec · Status · Auftrag

Confluence

Architecture · Decisions · Learnings

Atlassian Remote MCPKontext & erlaubte Tool-Aktionen

GitHub Copilot

In einer MCP-fähigen Umgebung

OpenAI Codex

Mit konfigurierter MCP-Anbindung

Claude Code

Oder weitere MCP-fähige Agenten

Codebase / EntwicklungswerkzeugeSeparater Repository-Zugriff des Agenten
MCP verbindet Atlassian-Kontext mit dem Agenten. Die Fähigkeit, Code zu ändern, kommt aus dessen Entwicklungsumgebung.

Zuweisung und Zugriff sind zwei verschiedene Dinge.

LoopsWork modelliert die logische Zuweisung zu einem Execution Agent. Über MCP erhält dieser Agent anschließend Zugriff auf den notwendigen Jira- und Confluence-Kontext. MCP macht einen Copilot-Agenten nicht automatisch zum Jira-Assignee und startet nicht von selbst einen Coding-Auftrag.

Client, Authentifizierung und Berechtigungen müssen eingerichtet sein. Zugriffe richten sich nach den freigegebenen Rechten; das Agentenprofil allein vergibt keine Rechte.

Atlassian Remote MCP Server ↗

Jira MCP und Atlassian MCP bilden hier eine mögliche technische Brücke für den AI Agent Workflow. Maßgeblich für die Einrichtung ist die offizielle Dokumentation.

13 / AGENTENGRENZEN

Gute Agenten brauchen drei Dinge

Context

Was muss der Agent wissen?
Spec · Architecture · Decisions · APIs · Constraints

Capability

Was darf der Agent tun?
Code lesen · Code verändern · Tests erstellen · PR erstellen · Jira aktualisieren

Boundary

Wo entscheidet ein Mensch?
Architekturentscheidung · Merge · Production Release · Budget · fachliche Abnahme

Give agents context, capability and boundaries.
14 / IM TEAM

AI-Agenten im LoopsWork-Team

Scout

Findet relevanten Kontext, Abhängigkeiten und bestehendes Wissen.

Planer

Analysiert Specs und schlägt kleine Slices vor.

Workmaster

Setzt vereinbarte Änderungen um und macht offene Reviews sowie fehlende Nachweise sichtbar. Die Merge-Freigabe bleibt bei der benannten menschlichen Person im Delivery Team.

Prüfer

Prüft Acceptance Criteria, Tests, Risiken und Umsetzung.

Wirkungsanalyst

Bereitet Messwerte und Value Reviews vor.

Lernbegleiter

Erkennt Muster und leitet Learnings oder Experimente ab.

KI baut nicht nur Funktionen.

Gemäß Spec können Agenten Monitoring-Konfiguration, Logs, Metriken, Alerts, Fehlerfalltests, Fallbacks, Recovery und Runbooks ergänzen. Menschen verantworten Kritikalität, akzeptables Risiko, Alert-Schwellen, SLOs, Eskalation und Freigabe.

Betriebsaufträge und menschliche Verantwortung

Menschen entscheiden. Agenten helfen.

Zu den bestehenden Rollen und Agentenprofilen →

15 / END-TO-END

Ein vollständiger LoopsWork-Cycle

Ein LoopsWork-Cycle verbindet Build Loop, Value Loop und Learning Loop: von der gewünschten Wirkung über die Umsetzung und Wirkungsmessung bis zur Erkenntnis, die neue Arbeit anstößt. Die drei Loops greifen ineinander und können parallel laufen.

Durchgehendes, fiktives Checkout-Beispiel. Die Messwerte sind keine realen Produktergebnisse.

  1. 01

    JPD Initiative

    Checkout-Abbruchquote reduzieren

  2. 02

    Spec

    Gespeicherte Adresse vorauswählen

  3. 03

    Planer

    Spec in kleine Slices zerlegen

  4. 04

    Assignment

    Responsible: Max · Execution Agent: Copilot Backend

  5. 05

    MCP Context

    Jira + Confluence + Decisions gezielt abrufen

  6. 06

    Build

    Agent erstellt Änderung + Tests + PR

  7. 07
  8. 08

    Release

    Mensch gibt die Veröffentlichung frei

  9. 09

    Value Review

    12,4 % → 9,8 % Abbruchquote im fiktiven Beispiel

  10. 10

    Learning

    Bestandskunden profitieren besonders

  11. 11

    Neue Hypothese / Spec

    Hindernisse für Neukunden untersuchen

↻ Neue Specs beginnen mit dem Wissen aus dem letzten Loop.
16 / AUTOMATIONEN

Automationen unterstützen die Loops

Spec erstelltScout / Planer prüfen Spec-Qualität
ReadyRelevanten Kontext und bestätigte Version prüfen
BuildingExecution Agent erhält den begrenzten Auftrag
ReleasedValue Review terminieren
Measurement Date erreichtWirkungsanalyst erstellt eine Zusammenfassung
Value Review abgeschlossenLearning dokumentieren
Learning relevantBestätigten Kontext aktualisieren

Jira Automation, Rovo beziehungsweise andere Agenten können viele dieser Übergänge unterstützen. Das sind Konfigurationsbeispiele: Für externe Coding-Agenten braucht es einen passenden Trigger oder eine Orchestrierung zusätzlich zum MCP-Zugriff.

Ein „Spec Coach“ ist hier eine Tätigkeit von Scout und Planer, kein zusätzliches siebtes Agentenprofil. Schreibrechte, Freigaben und Budgetgrenzen werden für jeden Auftrag festgelegt.

Automatisiert wird Arbeit – nicht Verantwortung.

17 / TERMINE

Weniger Status. Mehr Entscheidungen.

Die bestehenden LoopsWork-Termine verbinden KI-Vorbereitung mit menschlicher Klärung und Entscheidung. Der Takt ist ein Startwert; Termine bei Bedarf auslösen.

Täglich · bis 10 Min.

Flow Check

Agenten bereiten Blockaden, offene Reviews und wartende Abnahmen vor. Menschen klären die nächste konkrete Aktion.

Ablauf ansehen →
Wöchentlich · 45 Min. als Startwert

Refinement

Scout und Planer bereiten Beispiele, offene Regeln und kleine Specs vor. PO, Team und Fachpartner klären die nächste Änderung.

Ablauf ansehen →
Bei Klärungsbedarf · 30 Min.

Spec Clinic

Bei Widersprüchen oder Budgetdruck schlagen Agenten Optionen vor. Menschen vereinbaren den kleinsten nützlichen Umfang.

Ablauf ansehen →
Bei Abnahmereife · 20 Min. reservieren

Acceptance Slot

Der Prüfer bündelt Kriterien und Nachweise. Fachpartner bestätigen reale Szenarien oder benennen Abweichungen.

Ablauf ansehen →
Regelmäßig alle 4 Wochen · 30 Min.

Value Review

Der Wirkungsanalyst bereitet geprüfte Messwerte und Nutzerfeedback vor. Der PO entscheidet über die nächste Produktarbeit.

Ablauf ansehen →
Alle 2 Wochen · 45 Min. als Startwert

Retrospektive

Der Lernbegleiter bündelt freigegebene Beobachtungen. Das Team bewertet seine Arbeitsweise und vereinbart ein Experiment.

Ablauf ansehen →
Monatlich oder nach bewährtem Befund · 30 Min.

Learning Exchange

Agenten bereiten belegte Vorher-Nachher-Beispiele vor. Teams teilen Erkenntnisse und prüfen deren Übertragbarkeit.

Ablauf ansehen →

Alle Termine & Vorgehensweisen →

18 / LOOP LOTSE

Der Loop Lotse verwaltet nicht Jira. Er achtet auf die Loops.

  • Werden unsere Specs immer größer?
  • Steigt unsere Feedback Debt?
  • Warten Value Reviews zu lange?
  • Bekommen Agenten zu viel Kontext?
  • Erzeugen Learnings tatsächlich Veränderungen?
  • Wo bleiben Loops offen?

Der Loop Lotse macht fehlendes Feedback und Hindernisse sichtbar. Er unterstützt das Team dabei, die Kreisläufe zu schließen und die Arbeitsweise zu verbessern.

19 / BUILD. VALUE. LEARN.

Jira verwaltet nicht LoopsWork. Jira macht die Loops sichtbar.

LoopsWork verbindet Outcomes, kleine Specs, Umsetzung, Wirkung und Lernen zu einem kontinuierlichen System.

Menschen übernehmen Verantwortung.
Agenten übernehmen Arbeit.
Feedback schließt den Loop.

Loops verstehenBeispiel ansehen
Jira, Confluence und Atlassian MCP sind eine mögliche Referenzimplementierung von LoopsWork – einem technologieunabhängigen AI Software Development Framework.