Run SheetKnowledge ModelingIssue Mapping

IBIS

KomplexitätMedium

Zeit1-3 h

Teilnehmende2-8

FormatBoth

MaturityCanonical

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro-Board mit drei Notations-Farben (Issue als Frage, Position als Aussage, Argument pro/contra); Symbole für Pro (+) und Contra (-); Stifte; Timer; geteilte Definition der IBIS-Notation.

Personen / Rollen

Ein Facilitator mit IBIS-Erfahrung; zwei bis acht Teilnehmer mit Domänen- und Architekturkenntnis; ein Scribe, der die Map nachzieht und am Ende digital konsolidiert.

Vorabinfos

Zentrale Frage (Issue) als Ausgangspunkt; bestehende Designdokumente oder Architecture Decisions; Liste bisheriger Diskussionsstände; Definition, was als Argument zählt (qualitativ, quantitativ).

Zeitbedarf

1-3 h

Setup

Issue oben als Frage. Symbole für Position und Argument-Typ sichtbar. Regel ansagen: jede Position antwortet auf ein Issue, jedes Argument verweist auf eine Position.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Positionen beantworten die zentrale Issue, und welche Argumente sprechen für oder gegen jede Position?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Issue formulieren	10-15 min	Hauptfrage als offene Issue formulieren („Wie soll X gelöst werden?“). Bei zu breitem Scope in Sub-Issues zerlegen. Wichtigste Issue oben am Board.	Issues sind offene Fragen, keine Bewertungen. „Sollen wir X tun“ ist Bewertungsfrage, besser „Wie können wir X erreichen, gegeben Y und Z“.
2Phase 2: Positionen sammeln	20-30 min	Mögliche Antworten auf das Issue als Positionen sammeln (mindestens drei). Pro Position einen klaren Satz, der eine konkrete Antwort darstellt.	Wenn nur eine Position genannt wird, ist die Diskussion nicht offen. Facilitator generiert mit Devil's Advocate mindestens eine Gegenposition.
3Phase 3: Argumente zuordnen	30-45 min	Pro Position Pro- und Contra-Argumente sammeln. Argumente können Daten, Erfahrung oder Constraints sein. Pfeile von Argument zu Position, Pro/Contra-Symbol klar erkennbar.	Manche Argumente beziehen sich auf mehrere Positionen. Sauber pro Beziehung einen eigenen Pfeil setzen, sonst wird Map unleserlich.
4Phase 4: Beziehungen prüfen	20-30 min	Map gemeinsam durchgehen. Schwache Argumente markieren. Sub-Issues, die sich aus Argumenten ergeben, als neue Issues notieren („Issue-Knospe“).	IBIS-Maps wachsen oft Issue-Knospen, die in eigene Sub-Maps gehören. Nicht alles auf einer Map zwingen.
5Phase 5: Entscheidung oder offene Fragen	15-20 min	Entscheidungstragende Position markieren. Begründung im Decision Log. Offene Sub-Issues mit Owner und Datum versehen.	IBIS ist primär Dokumentation, nicht Entscheidungsmaschine. Wenn keine Position klar dominiert, Entscheidung an Decider übergeben mit Map als Anlage.

Artefakt

Was am Ende rauskommt

Form

IBIS-Diagramm als Bild oder digitale Map mit Issues, Positionen und Argumenten plus Markdown-Dokument mit hierarchischer Struktur, Decision Rationale, offenen Sub-Issues und Owner.

Tool-Alternativen

Compendium oder DesignVUE für klassische IBIS-Tools
Miro mit IBIS-Template
Markdown mit eingerückten Listen im ADR-Repo
draw.io mit gerichtetem Graph

Versionierung / Ownership

Pro Issue eigene Map mit Datum. Bei neuer Information oder umgestoßener Entscheidung Folge-Map als v2; alte Positionen nicht löschen, sondern als „abgelehnt“ kennzeichnen mit Begründung.

canvas

IBIS Arbeitsvorlage

Kompakte Arbeitsvorlage für IBIS mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# IBIS Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Issue Map:
- Positions:
- Argument Notes:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

ibis-beispiel.md

markdown

## IBIS — Authentifizierungsstrategie für neue App (19.05.2026)

**Issue**: Wie integrieren wir Authentifizierung für die neue Mobile App, gegeben bestehende Web-OAuth?

**Positionen**:
- P1: OAuth2 mit PKCE wiederverwenden.
- P2: Eigenes Mobile-SDK mit Token-Refresh-Flow.
- P3: Drittanbieter-IdP (z. B. Auth0, Okta).

**Argumente**:
- P1 (+): bestehende Infrastruktur nutzbar (Beleg: Production seit 2024).
- P1 (-): PKCE-Implementierung auf iOS aufwendig (Erfahrungsanekdote, Spike geplant).
- P2 (+): volle Kontrolle über UX (Argument: Design-Wünsche aus User-Interviews).
- P2 (-): hoher Eigenaufwand (Schätzung 6 PT).
- P3 (+): SLA und Compliance-Features (Beleg: Anbieterliste mit ISO 27001).
- P3 (-): laufende Kosten ab Nutzerzahl 10k.

**Sub-Issue (Knospe)**: Wie ist die Migration bestehender Web-Tokens zu Mobile-Tokens? Owner: @ben, Spike bis 30.05.

**Entscheidung**: P1, mit Spike für PKCE-iOS. Decider: @julia. Begründung: Wiederverwendung schlägt Greenfield, Drittanbieter unter Kosten- und Datenresidenzgesichtspunkten zurückgestellt.

Was tun

Bei jeder Architektur- oder Designänderung Map updaten oder neue Version anlegen. Sonst wird Map zur Geschichtsfälschung.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Issue ist nach 15 min nicht als offene Frage formulierbar.

Nur eine Position vertreten, keine echte Diskussion möglich.

Keine Person mit Sachkenntnis anwesend, Argumente bleiben spekulativ.

Workshop unter 45 min angesetzt, fünf Phasen nicht durchführbar.

Diskussion ist primär emotional oder konfliktgeladen, IBIS-Notation greift nicht.

Keine Entscheidungsbefugnis im Raum oder Entscheidung wird nicht in Decision Log überführt.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden