Das Kano-Modell der Kundenzufriedenheit

Donnerstag, 31. Dezember 2009 von  
unter Fachartikel Scrum

In meinem Artikel „Prioritäten von Anforderungen – Kategorie oder Reihenfolge“ hatte ich mehrfach Bezug auf das Kano-Modell der Kundenzufriedenheit genommen ohne dieses dabei näher zu erläutern. Diese fehlende Erläuterung möchte ich hier nun nachholen.

Die meisten von uns, die sich schon mal mit Produkt- oder Anforderungsmanagement auseinandersetzen durften oder immer noch dürfen, kennen das Problem der Entscheidung: In welcher Reihenfolge sind Anforderungen umzusetzen bzw. welche sind überhaupt umzusetzen. Selten mangelt es an Anforderungen an das, was ein zu erstellendes Produkt alles können soll, unzählige Interessenvertreter haben ihre eigenen Vorstellungen davon, was absolut unverzichtbar ist und damit auf jeden Fall umgesetzt werden muss. Und zwar immer als allererstes!

Das Kano-Modell versucht hierbei Licht ins Dunkel zu bringen und dem armen Entscheider, der es allen Recht machen und am Ende aber auch die Verantwortung für den Erfolg des Produktes tragen muss ein Werkzeug an die Hand zu geben, dass in diesem Wirrwarr die Streu vom Weizen trennt und für die Entscheidung, was wann umgesetzt wird eine nachvollziehbare Grundlage schafft. Damit ist aber auch direkt klar, was das Kano-Modell nicht macht: Es unterstützt nicht bei der Erhebung der Anforderungen. Um diesen teilweise unübersehbaren Pool an Anforderungen zu generieren, müssen also andere Techniken verwendet werden, die in diesem Artikel jedoch nicht besprochen werden (vielleicht lasse ich mich hierzu ja auch demnächst zu einem Artikel hinreißen).

Zum geschichtlichen beschränke ich mich auf den Hinweis, dass das Kano-Modell auf Prof. Dr. Noriaki Kano von der Universität Tokio zurückgeht. Mehr historisches dazu interessiert zumindest mich derzeit nicht.

Also zurück zum Handwerklichen oder besser erst mal zu einer ganzen Reihe von Definitionen.

Als erstes müssen wir festhalten, dass im Kano-Modell nicht von Anforderungen sondern von Produktmerkmalen gesprochen wird. Anforderungen sollten sich in der Regel auf Produktmerkmale beziehen, d.h. sie „fordern an“, dass das Produkt ein bestimmtes Merkmal aufweist bzw. nicht aufweist. Ein Produktmerkmal selber ist eine für den Kunden spürbare Eigenschaft des Produkts, also z.B. dass er sich anmelden kann. Und unter Kunden verstehen wir hier den Personenkreis, der mit unserem neuen Produkt umgehen muss bzw. es kaufen soll.

Jetzt wieder zurück zum Kano-Modell. Dort werden Produktmerkmale in fünf Kategorien aufgeteilt:

Basis-/Must-Have Merkmal: Basismerkmale eines Produktes sind so grundlegend und selbstverständlich, dass sie dem Kunden erst bei Nichterfüllung bewusst werden. Werden sie aber nicht erfüllt, dann entsteht nicht unerhebliche Unzufriedenheit. Umgekehrt entsteht aber bei Erfüllung nicht wirkliche Zufriedenheit. Ein Beispiel hierfür kann die Möglichkeit zur Anmeldung an eine Software sein.

Lineares-/Leistungsmerkmal: Lineare Merkmale sind dem Kunden durchaus bewusst und sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung. Ein Beispiel hierfür ist die Performance eines Softwareprodukts.

Begeisterungsmerkmal: Begeisterungsmerkmal sind Nutzen stiftende Merkmale, mit denen der Kunden nicht unbedingt rechnet. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einer überproportionalen Nutzenstiftung führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, die Nutzenstiftung aber dennoch enorm.

Unerhebliches Merkmal: Sind sowohl bei Vorhandensein wie auch beim Fehlen ohne Belang für den Kunden. Sie können daher keine Zufriedenheit stiften, führen aber auch beim Fehlen nicht zu Unzufriedenheit.

Rückweisungsmerkmal: Rückweisungsmerkmale führen beim Vorhandensein zu Unzufriedenheit, beim Fehlen jedoch nicht zu Zufriedenheit. Ein Beispiel hierfür wäre ein Kopierschutz.

Soweit so gut, ich habe jetzt also auf der einen Seite fünf Kategorien und auf der anderen einen Sack voll mit Anforderungen. Aber wie ordne ich jetzt meine Anforderungen in diese fünf Kategorien ein? Eine Möglichkeit wäre, dass ich als der Produktverantwortliche dieses anhand der Beschreibungen oben jetzt selber mache. Dafür muss ich aber die zukünftigen Kunden und deren Bedürfnisse schon ziemlich genau kennen und die Wahrscheinlichkeit, dabei des Öfteren mal daneben zu liegen dürfte recht hoch sein.

Besser also, ich frage die potentiellen Kunden selber und zwar möglichst viele davon. Aber auch hier die Frage, nach welchen Kriterien ist eine Anforderung einer der fünf Kategorien zuzuordnen. Die Beschreibungen oben sind verhältnismäßig dürftig, dürften von jedem etwas anders verstanden werden und darüber hinaus ist dies schon eine recht anspruchsvolle und komplexe Tätigkeit. Ich will damit nicht sagen, dass alle Endkunden zu … äh … damit überfordert wären, aber machen wir uns nichts vor, gerade wenn ich eine größere Gruppe von Personen zu etwas befragen möchte, dann sinkt die Qualität des Ergebnisses mit der steigenden Komplexität der Fragestellung.

Das Kano-Modell geht deshalb einen anderen Weg, den einer biopolaren Befragung. Jeder Proband wird zu jedem Merkmal jeweils mit einer funktionalen und einer dysfunktionalen Frage konfrontiert oder verständlich ausgedrückt, er soll zu jedem Merkmal mitteilen, wie er es fände, wenn es vorhanden ist und wie, wenn es fehlt.

Als Antwortmöglichkeiten stehen ihm für beide Fragen zur Verfügung:

– Ich mag es genau so
– Ich erwarte, dass es so ist
– Mir egal
– Ich kann damit leben
– Das stört mich

Super, jetzt habe ich pro Merkmal sogar zwei Antworten von einem Probanden, wie soll ich denn daraus jetzt zu meiner Kategorie kommen? Hier kommt die Magic des Kano-Modells ins Spiel und zwar in Form der Antworten-Kategorien-Matrix.

Antworten-Kategorien-Matrix des Kano-Modells

Wir finden in dieser Matrix in den Schnittmengen der möglichen Antworten auf die beiden Fragen alle unsere fünf Kategorien wieder plus zweimal eine unlogische Kombination. Bei dieser Antwortenkonstellation scheint irgendwie der Sinn der Fragestellungen abhanden gekommen zu sein. Entweder ignorieren oder die Frage nochmal stellen und dabei nochmal den Schwerpunkt auf das Verständnis der Fragestellungen legen.
Aus den Antworten auf die beiden Fragen eines Probanden kann nun also die Kategorie einfach abgelesen werden. Und machen wir nun nicht nur einmal sondern pro Produktmerkmal fragen wir möglichst viele potentielle Kunden und halten das Ergebnis tabellarisch fest. In der Tabelle unten habe ich mal ein Beispiel dafür erstellt. Wir haben drei Merkmale befragt und die Verteilung der Zielkategorien der einzelnen Befragungen prozentual in einer Tabelle zusammengefasst.

Beispiel der Auswertung

Bei dem Produktmerkmal 1 haben wir mit 43,8% eine eindeutige Spitze für lineares Merkmal, bei dem Produktmerkmal 2 mit 54,3% eine eindeutige Spitze für Basismerkmal. Beim Produktmerkmal 3 jedoch haben wir zwei Spitzen, einmal 36,6% für Basismerkmal und dann nochmal 39,1% für Begeisterungsmerkmal. Dies kann darauf hindeuten, dass wir zwei unterschiedliche Arten von Kunden für unser Produkt haben, die unterschiedliche Erwartung an unser Produkt hegen. Hier macht es Sinn, sich klarzumachen, welche unterschiedlichen Kundenarten das sind und anschließend festzulegen, auf welche von beiden Kundenarten wir mehr fokussieren wollen.

Kommen wir zurück zu unserer Ausgangssituation, wir sind ein armer Produktverantwortlicher und alle Interessenvertreter haben uns mit Unmengen an Anforderungen zugeschüttet. Wir haben aus (fast) all diesen Anforderungen Produktmerkmale extrahiert und diese durch das Kano-Modell in Kategorien eingeordnet. Ist damit jetzt klar, welche Anforderungen bzw. Produktmerkmale umzusetzen sind und in welcher Reihenfolge?
Leider nicht so ganz. Fangen wir mit den einfachen Fällen an, die Rückweisungsmerkmale und die unerheblichen Merkmale. Das Kano-Modell priorisiert Produktmerkmale aus Sicht des Kunden und aus dieser Sicht sollte auf Rückweisungsmerkmale auf jeden Fall verzichtet werden und unerhebliche Merkmale sollten nur am Schluss umgesetzt werden, wenn noch Zeit und Geld da ist. Obwohl sie aus dieser Sicht eigentlich nur Resourcenverschwendung sind. Also besser auch nicht umsetzen. Allerdings bestimmen ja nicht immer nur die Kundenwünsche die Notwendigkeiten zu Produktmerkmalen. Bevor diese Merkmale also tatsächlich komplett gefeuert werden, erst noch prüfen was die Intention zu diesen Merkmalen war. Bei gesetzlichen Vorgaben oder technischen Notwendigkeiten kann die Welt schon ganz anders aussehen. Aber wenn nichts dergleichen zutrifft, raus damit, schlanke Produkte designen.

Kommen wir zu unserem Dreigestirn: Basis-, lineare und Begeisterungsmerkmale.
Mit Basismerkmalen gewinnt man keinen Blumentopf, wenn sie aber fehlen floppt wahrscheinlich das ganze Produkt. Also müssen sie wohl rein. Wie dringend sie rein müssen, also mit welcher Priorität verglichen mit den Linearen und Begeisterungsmerkmalen, hängt davon ab, wie ich die Release auf den Markt bringe. Wenn ich klassisch im Wasserfall arbeite und vermutlich nur alle 12 Monate ein neues Release rausbringe (oder sogar noch langsamer), dann müssen alle Basismerkmale bereits im ersten Release drin sein, denn die Kunden werden das Produkt solange nicht akzeptieren, wie die Basismerkmale nicht enthalten sind oder mit der baldigen Nachlieferung zu rechnen ist. Wenn ich dahingegen in wesentlich kürzeren Zeitabständen meine Releases ausliefere, z.B. jeden Monat oder alle zwei und dieses auch entsprechend kommuniziere, dann sind Kunden schon eher geneigt, dass Fehlen von Basismerkmalen für kurze Zeit in Kauf zu nehmen. Natürlich muss dass, was ich da ausliefere in sich funktionsfähig sein, alles andere wäre ja völliger Unsinn. Aber anstatt für den gesamten geplanten Funktionsumfang des Produktes erst mal nur die Basismerkmale zu ersten und auszuliefern und dem Kunden damit ein „ist ja ganz nett“ zu entlocken, fokussiert man nur einen bestimmten Funktionsbereicht und realisiert diesen mit seinen notwendigen Basismerkmalen plus weitere Lineare und Begeisterungsmerkmalen. Der Kunden gewinnt damit einen guten Eindruck dessen, was in nach und nach bei unserem Produkt erwarten wird und kann evtl. auch schon mit der Teilfunktionalität schon Mehrwerte für sich erzielen.

Wäre das mit den Basismerkmalen schon mal geklärt, aber wie gewichten wir lineare gegenüber Begeisterungsmerkmalen. Begeisterungsmerkmale sprechen oft sehr subjektives Empfinden gegenüber einen Produkt an und gewinnen in der Regel eher durch den Überraschungseffekt oder das Alleinstellungsmerkmal (das hat halt kein anderer so, deshalb ist es cool). Beides nutzt sich mehr oder weniger schnell ab. Lineare Merkmale dahingegen stellen meist tatsächliche Wehrwerte des Produktes für den Kunden dar, die meist auch auf Dauer erhalten bleiben.
Rein ökonomisch gesehen wären deshalb die linearen Merkmale den Begeisterungsmerkmalen vorzuziehen. Aber unsere Kunden sind alle Menschen und die Begeisterungsmerkmale sind es, die dann doch oft die Kaufentscheidung oder die Akzeptanzbereitschaft für unser Produkt stark beeinflussen. So gesehen ist die Entscheidung für Begeisterungsmerkmale irgendwie auch ökonomisch. Zumindest für den, der das Produkt verkauft :-).

Die gesunde Mischung macht es aus. Ein Produkt nur mit linearen Merkmalen ist zwar wertvoll, aber unsexy, ein Produkt nur mit Begeisterungsmerkmalen verleitet zwar zum schnellen Kauf aber nicht zur Nutzung. Ein guter Erfahrungswert ist, den Schwerpunkt auf lineare Merkmale zu setzen, damit der Kunden tatsächlich echten Mehrwert erhält und das mit einer Handvoll Begeisterungsmerkmale zu würzen, damit er sich auch für unser Produkt entscheidet bzw. die Nutzer das Produkt bereitwillig akzeptieren.

So, ich hoffe das hat ein bisschen Licht ins Dunkel gebracht. Die Quintessenz ist, das Kano-Modell bietet eine gute Unterstützung dabei, sich der Qualität von Anforderungen bewusst zu werden und sich aus der Vielzahl an Anforderungen auf die zu konzentrieren, die bei den Kunden gut ankommen werden. Es ist aber zum Leidwesen einiger kein Mechanismus, in den ich oben einfach alles rein kippe und unten kommt dann die fertige Reihenfolge heraus. Der gesunde Menschenverstand der Produktverantwortlichen ist immer noch erforderlich.

Und zumindest ich bin froh darüber!

Quellen:

Prioritäten von Anforderungen – Kategorie oder Reihenfolge?

Freitag, 6. November 2009 von  
unter Fachartikel Scrum

Ein typisches Problem in jedem Projekt (nicht nur in der Softwareentwicklung) ist die Frage der Prioritäten der Anforderungen. Was muss zuerst erledigt werden, was hat Zeit für später, auf was kann ggfs. ganz verzichtet werden.

Es gibt verschiedene Methoden und Verfahren, diese „Wichtigkeiten“ der Anforderungen zu bestimmen, auf die ich hier nicht näher eingehen möchte. Was mich hier aus aktuellem Anlass eher beschäftigt ist die Frage, wie diese Priorität anschließend festgehalt wird.
Aktuell sind mir dazu zwei Modelle geläufig: a) Einteilung in feste Kategorien und b) relative Priorität in Form einer Reihenfolge.

Betrachten wir beide Modelle mal kurz getrennt voneinander:

Kategorien: Zur Einteilung der Anforderungen wird eine Anzahl n Kategorien definiert. Besonders beliebt sind die Kategorien „Priorität 1“ bis „Priorität 5“. Wenn sich der Prozessverantwortliche noch besonders Mühe gibt, dann bekommen die Kategorien noch so sprechende Bezeichnungen/Beschreibung wie z.B. „Must have“, „Nice to have“ oder auch „Sehr wichtig“, „Wichtig“ oder „Normal“. Dass sich mal jemand getraut hätte eine Kategorie ganz offen als „Wird wohl niemals gemacht werden“ zu deklarieren, habe ich leider noch nicht erlebt. Aber ehrlich wäre es.

Mittels einer geeigneten Methode (z.B. Kano Modell) oder oft auch Bauchgefühl wird jeder Anforderung nun einer dieser Prioritätskategorien zugeordnet.

Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können.
Nachteile ergeben sich aber oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen. Dazu weiter unten aber mehr.

Reihenfolge: Die Anforderungen werden abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Hier weiß man genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C. Man fängt mit zwei Anforderungen an und fügt dann weitere Anforderungen im Bubblesort-Verfahren (http://de.wikipedia.org/wiki/Bubblesort) in die Reihenfolge ein.

Nachteil ist, dass der initiale Aufbau der Reihenfolge etwas aufwändig scheint, da man die einzelnen Anforderungen bei der Frage nach ihrer Priorität nicht isoliert betrachten kann. Und auch bei der Aufnahme weiterer Anforderungen ist ein Vergleich mit den anderen Anforderungen notwendig. Dabei muss man aber bei der Einsortierung nicht immer ganz unten anfangen; wenn ich weiß, meine neue Anforderung H ist wichtiger als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger wie alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren. Da kann es sich anbieten statt Bubblesort das Verfahren des binären Suchens (http://de.wikipedia.org/wiki/Binäres_Suchen) anzuwenden. Das ist doch mal spannend, mathematische Sortierverfahren bei der Priorisierung von Anforderungen einzusetzen. Die Mathematiker jetzt aber bitte nicht alle melden und darauf hinweisen, dass es optimalere Algorithmen für die Sortierung gibt. Ich kann mir nur schwer vorstellen, dass tatsächlich ein Produktverantwortlicher oder Anforderungsmanager einen mathematischen Sortieralgorithmus verwenden wird, die Vergleiche dienen hier nur als anschauliche Beispiele.

Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier mal nennen möchte) ist, dass ich hier nun eine eindeutige Reihenfolge habe, in der die Anforderungen umzusetzen sind. Was ist, wenn ich zwischen zwei Anforderungen nicht entscheiden kann, welche von beiden wichtiger ist? Münze werfen oder die weiteren Begleitumstände beachten (ist klar, dass eine der beiden Anforderungen aufgrund äußerer Umstände erst später umsetzbar sein wird, dann kann sie auch direkt weiter nach unten wandern. Dies gehört aber zum Thema, wie überhaupt bestimmt werden kann, welche Anforderungen wichtiger sind wie andere. Das behandeln wir mal in einem anderen Artikel).

Werfen wir beide Modell nun mal in den Ring und betrachten wir ihre Stärken und Schwächen im direkten Vergleich.

Bei einer kleinen überschaubaren Anzahl an Anforderungen machen sich beide Kandidaten recht gut. Die Vergabe der Prioritäten im auf Kategorien basierenden Ansatzes ist wie bereits oben besprochen ja eh recht trivial (Priorisierungsmethode der Wahl anwenden, Ergebnis nehmen und auf Kategorien transformieren, fertig). Aber auch im relativen Modell ist der direkte Vergleich der Wichtigkeit der Anforderungen untereinander schnell erledigt. Und auch bei der Abarbeitung der Anforderungen bzw. der Einplanung zeigen sich beide Modelle hilfreich.

Aber wie sieht es mit einer großen Anzahl an Anforderungen aus, wie sie schon in durchschnittlichen Projekten schnell erreicht ist?
Wir unterstellen mal eine initiale Anzahl von 100 Anforderungen zum Projektstart. Und hier wird es langsam interessant.

Betrachten wir als erstes wieder den Aufwand für die initiale Priorisierung der Anforderungen.
Im auf Kategorien basierenden Modell nehmen wir mal die typische Aufteilung in fünf Kategorien an, die wir hier als P1 bis P5 bezeichnen wollen, wobei P1 für die wichtigsten Anforderungen stehen wird und P5 für die unwichtigsten. Die Verteilung der 100 Anforderungen auf die fünf Kategorien ist erneut mit wenig Aufwand verbunden. Na gut, mit verhältnismäßig wenig Aufwand, natürlich muss jede der 100 Anforderungen bewertet werden, das ist schon Arbeit. Als Ergebnis bestimmen wir in unserem Beispiel, dass 30 Anforderungen nun P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5. Das ist irgendwie nicht unüblich, dass der überwiegende Teil der initialen Anforderungen ziemlich wichtig zu sein scheint.

Beim relativen Modell steigt der Aufwand deutlich, denn hier müssen nun die 100 Anforderungen im Verhältnis zueinander nach Wichtigkeit sortiert werden. Das klingt aber schlimmer als es dann wirklich ist. Man fängt mit zwei Anforderungen an und fügt dann Anforderung für Anforderung hinzu. Und wie oben schon mal erklärt, muss nicht bei jeder Anforderung unten mit der Sortierung angefangen werden sondern in der Regel kann direkt weiter oben in der Reihenfolge eingestiegen werden (weiter unten sage ich da noch was zu).

Wie sieht es jetzt mit der Einplanung der Anforderungen aus? Auch hier treffen wir für unser Beispiel ein paar vereinfachte Annahmen. Wir definieren, dass wir mit Scrum arbeiten, dass alle Anforderungen mit einem Aufwand von einem Story Point (SP) geschätzt sind und dass wir in einen Sprint 20 Story Points unterbringen können.
Wenn wir nun unseren ersten Sprint planen, dann stellen wir im Kategorienmodell fest, dass wir insgesamt 30 SPs haben, die Priorität vor allem anderen haben. Soweit war das Modell ja schon mal hilfreich. Im ersten Sprint unterbringen können wir aber nur 20 SP. Welche sollen wir da nun nehmen? Hier fangen wir dann vermutlich an, diese 30 Anforderungen untereinander zu vergleichen, um innerhalb dieser Gruppe eine gewisse Sortierung zu erzielen. Das gleiche gilt dann für die nächsten Sprints. Vorausgesetzt, die 20 geplanten SPs des ersten Sprints werden auch umgesetzt, stehen für den zweiten Sprint 10 weitere SPs der Priorität P1 an und 40 der Priorität P2, von denen aber nur 10 im Sprint Platz finden. Also wieder vergleichen und sortieren innerhalb von P2, und so weiter. Wir fangen uns hier also den Aufwand ein, den wir vorher bei der initialen Priorisierung vermeintlich gespart hatten.
Bei der bereits eindeutig sortierten Reihenfolge des relativen Modells haben wir diese Probleme hier nicht mehr, es ist jederzeit klar was als nächstes wichtig ist. Dafür haben wir aber vorher mehr Aufwand reinstecken müssen.

Und jetzt kommen wir zur Königsdisziplin, eine neue Anforderung, die wichtiger ist wie alles andere, sagen wir eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist (neue gesetzliche Vorgaben werden vor allem in Konzernen ja gerne mal so lange ignoriert, bis sie dann auf den letzten Drücker doch plötzlich unvermeidbar scheinen).
Wie bilde ich das mit meinen Kategorien ab? P1 ist ja schon das wichtigste, aber meine neue Anforderung ist ja sogar noch wichtiger als die 30 bereits als P1 eingestuften Anforderungen. Definiere ich jetzt adhoc eine neue Kategorie P0, die noch über P1 steht? Da dauert es garantiert nicht lange, bis auch diese neue Kategorie regelmäßig gefüllt wird, denn hochpriore Kategorien haben die Eigenschaft, Anforderungen anzuziehen. Wir haben hier also ein nichttriviales Problem, dass in vielen Fällen damit gelöst wird, dass zusätzlich zur eigentlichen Kategorie noch ein weiteres Attribut wie z.B. Severity (in Bugzilla) hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und enhancement (diese gibt es so z.B. eben in Bugzilla aber auch anderen Tools) annehmen. Das ist aber nicht nur redundant, sondern kann auch zu Inkonsistenzen führen. Was ist denn nun wichtiger, eine Anforderung mit P1/enhancement oder eine mit P3/blocker? Und wieso kann eine P3 Anforderung ein Blocker sein, bzw. wieso kann ein scheinbarer Blocker nur die Priorität P3 haben? Das führt zu Chaos!

Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen hochprioren Anforderung leicht zu lösen. Die neue Anforderung einfach ganz oben einsortieren, Problem gelöst.

Bis hierhin scheint das relative Modell also besser geeignet zu sein.

Jetzt hatte ich aber weiter oben ausgeführt, dass die meisten Methoden zur Priorisierung von Anforderungen eher das Denken in Kategorien unterstützen. Das jetzt schon mehrfach zitierte Kano Modell der Kundenzufriedenheit z.B. teilt Produktmerkmale (aus denen Anforderungen werden) in die fünf Kategorien Basis-, Leistungs-, Begeisterungs-, Unerhebliches und Rückweisungsmerkmal ein.
Muss ich nun auf diese Methoden verzichten, wenn ich mit einem relativen Prioritätsmodell arbeiten möchte? Natürlich nicht! Wenn ich eine eindeutige Reihenfolge meiner Anforderungen aufbauen möchte, dann muss ich die Wichtigkeit der einzelnen Anforderungen irgendwie begründen können. Warum ist denn die Anforderung A wichtiger als die Anforderung B? Da brauche ich für beide Anforderungen irgendwelche Anhaltspunkte dafür, weshalb sie wichtig oder auch nicht wichtig sind. Und genau dafür sind viele Methoden der Priorisierung eine große Hilfe. Mit ihnen kann ich zumindest schon mal ein grobes Raster schaffen, dass mir bei der ersten Vorsortierung hilft. Und wenn die Anforderung A nach dem Kano Modell in die Kategorie Basismerkmal fällt und die Anforderung B in die Kategorie Leistungsmerkmal, dann weiß ich ganz automatisch, das A wichtiger ist als B. Und nur wenn die Anforderung C ebenfalls ein Basismerkmal zu sein scheint, muss ich mir im Vergleich von A und C mehr Informationen heranziehen um hier eine eindeutige Entscheidung zu fällen.

Fazit:
Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind. Nein, sie sind eine hilfreiche Zwischenstufe auf dem Weg zu einer sortieren Reihenfolge relativer Wichtigkeit und diese Zwischenstufe kann nicht nur viel Zeit sparen sondern bei der Verwendung geeigneter Methoden die fundierte Basis für die Bewertung der relativen Wichtigkeiten liefern. Nur davon, dann bei diesen Kategorien stehen zu bleiben und auf dieser Basis dann z.B. die Sprint- oder Releaseplanung zu betreiben oder die Priorität von Anforderungen zu kommunizieren, rate ich dringend ab.