Methoden Seite an Seite ansehen.
Wähle bis zu vier Methoden. Ergänze sie über die Suche und teile den Vergleich über seinen Link.
In der Auswahl:Decision Rights MappingSpecification by ExampleStakeholder Salience ModelExample Mapping
| Kriterium | ![]() Decision Making Decision Rights Mapping | ![]() Agile Specification by Example | ![]() Facilitation Stakeholder Salience Model | ![]() Agile Example Mapping |
|---|---|---|---|---|
Zweckunterschiedlich | In Organisationen mit vielen Beteiligten verwischt oft, wer wirklich entscheidet und wer nur mitredet. Decision Rights Mapping legt diese Zuständigkeiten offen und verhindert, dass Verantwortung zwischen Rollen zerfasert. | Wenn fachliche Regeln präzise werden sollen, verbindet sie Sprache, Beispiel und Prüfung. Sie verhindert, dass Anforderungen zu abstrakt oder missverständlich bleiben. | Wenn Stakeholder sehr unterschiedlich wichtig erscheinen, bewertet das Stakeholder Salience Model ihre tatsächliche Priorität über Macht, Legitimität und Dringlichkeit. Es macht sichtbar, wer Aufmerksamkeit sofort, wer später und wer nur situativ braucht. | Wenn eine Story fachliche Regeln und Ausnahmen trägt, bringt sie Klarheit vor der Umsetzung. Sie macht Beispiele, offene Fragen und Abgrenzungen so sichtbar, dass die Logik gemeinsam tragfähig wird. |
Komplexitätunterschiedlich | Mittel | Mittel | Mittel | Niedrig |
Zeitunterschiedlich | 90-180 min | 60-90 min pro Feature | 60-90 min | 30-60 min |
Teilnehmendeunterschiedlich | 4-12 | 3-6 | 3-6 | 3-7 |
Formatidentisch | Workshop | Workshop | Workshop | Workshop |
Outputunterschiedlich | Decision-Rights-Matrix, Vereinbarung | Beispieltabelle, Acceptance Tests | Salience-Diagramm, Strategie pro Klasse | Example Map, Acceptance Criteria, Open Questions |
Tagskeine Überschneidung | EntscheidungGovernanceAbstimmungVerantwortung | AgilAnforderungenBeispieleBehavior-Driven Development | StakeholderFacilitationAbstimmungGovernance | Behavior-Driven DevelopmentAnforderungenBeispieleRefinement |



