Priorisierung

Von Mitch Lacey. Besitzer von Mitch Lacey & Associates, Inc, einem auf Agile- und Scrum-Umsetzungen und -Optimierungen spezialisierten Beratungsunternehmen.

Januar 2012

In diesem Artikel stellt Mitch Lacey drei Methoden vor, die sich für viele Teams der agilen Softwareentwicklung bewährt haben: das Kano-Modell für Kundenzufriedenheit, eine Reihe von Innovationsspielen von Luke Hohmann und das Modell der relativen Gewichtung nach Karl Wiegers. Jede dieser Methoden kann Sie dabei unterstützen, wie Sie von grober Priorisierung Ihres Bestands zu konkreter Auflistung übergehen, die zufriedenstellend Risiken, Relevanz und Kundenzufriedenheit gegeneinander abwiegt.

Betrifft

Application Lifecycle Management; Team Foundation Server

In diesem Artikel:

• Einführung

• Kano-Modell für Kundenzufriedenheit

• Innovationsspiele

  • Reduzieren der Produktstruktur

  • Erwerben einer Funktion

• Relative Gewichtung – Karl Wiegers

• Schlussfolgerung

Damit Ihr flexibles Team weiterhin effektiv agiert, müssen Sie die Elemente in Ihrem Product Backlog nach Priorität sortieren und dann diese Prioritäten mit fortschreitendem Projekt aktualisieren. Alle Product Backlogs müssen auf Basis von geschäftlichem Nutzen und Risiko priorisiert werden. Durch die Anerkennung dieser Prioritätenfolge kann sich das Team besser auf die Funktionen konzentrieren, die voraussichtlich zum Erfolg des Produkts beitragen. Ein übersichtlicher und priorisierter Backlog zahlt sich nicht nur durch die Zufriedenheit von Team und Kunden aus, sondern trägt auch zum Gewinn des Unternehmens bei. Informationen zu Backlogs finden Sie unter Erstellen und Verwalten des Produktrückstands, Erstellen Ihres Backlogs und Bereinigen und Schätzen des Backlogs.

Bei der Sortierung und Priorisierung Ihres Product Backlogs müssen Sie viele Faktoren berücksichtigen und in der Lage sein, Ihre Entscheidungen zu rechtfertigen. Wenn Sie mit einem unbearbeiteten Product Backlog starten, kann der Prozess nahezu unüberschaubar wirken. Glücklicherweise müssen Sie nicht jedes Element sofort vollständig in Ihrem Backlog einordnen. In Schätzung wird ein Verfahren namens „The Big Wall“ beschrieben, das eine effektive Möglichkeit bietet, um ein unbearbeitetes Product Backlog schnell zu bewerten und mit den Beteiligten zusammenzuarbeiten, um eine grobe Priorisierung zu erreichen.

Diese grobe Priorisierung ist ein guter Ausgangspunkt und ist für Ihre Situation möglicherweise ausreichend. In einigen Fällen möchten Sie diese Prioritäten möglicherweise optimieren oder auf wissenschaftlichere Weise bei einem priorisierten Backlog angelangen. Sie können dies mithilfe verschiedener Verfahren erreichen. Im folgenden Artikel stelle ich drei Methoden vor, die sich für viele Teams der agilen Softwareentwicklung bewährt haben: das Kano-Modell für Kundenzufriedenheit, eine Reihe von Innovationsspielen von Luke Hohmann und das Modell der relativen Gewichtung nach Karl Wiegers. Jede dieser Methoden kann Sie dabei unterstützen, wie Sie von grober Priorisierung Ihres Bestands zu konkreter Auflistung übergehen, die zufriedenstellend Risiken, Relevanz und Kundenzufriedenheit gegeneinander abwiegt.

Kano-Modell für Kundenzufriedenheit

Das Kano-Modell für Kundenzufriedenheit wurde in den 1980er Jahren von Professor Noriaki Kano von der Tokio Rika University entwickelt. Sein Modell bietet ein einfaches Rangfolgeschema, das zwischen grundlegenden und herausbildenden Attributen unterscheidet. Das Modell ist ein auf Fragebogen basierender Ansatz und bietet eine leistungsfähige Möglichkeit zur Visualisierung von Produktmerkmalen und zur Anregung von Debatten innerhalb des Designteams.

In Kano werden eine Reihe von Fragen auf zwei verschiedene Arten gestellt: funktional und dysfunktional. Angenommen, wir befragen Kunden zu einem GPS-Navigationssystem für Autos. Wir stellen zuerst die funktionale Form der Frage:

• Wie würden Sie sich fühlen, wenn dieses Auto über ein GPS-Navigationssystem verfügen würde?

Wir beschränken die Antworten auf die folgende Auswahl:

• Mir würde es gefallen

• Ich würde es erwarten

• Ich bin neutral

• Ich könnte es akzeptieren

• Mir würde es nicht gefallen

In diesem Beispiel nehmen wir an, dass unsere fiktiven Kunden mit „Mir würde es gefallen“ antworten.

Als Nächstes stellen wir die dysfunktionale Form der Frage:

• Wie würden Sie sich fühlen, wenn dieses Auto nicht über ein GPS-Navigationssystem verfügt?

Unsere fiktiven Kunden können jede beliebige aufgeführte Antwort auswählen. Die Antwort kann häufig anders lauten und sie ist es in der Regel auch. In diesem Beispiel nehmen wir an, dass unsere fiktiven Kunden mit „Ich würde es erwarten“ auf die dysfunktionale Form der Frage geantwortet haben.

Wenn wir dies für ein aktuelles Projekt durchführen, können wir diese Liste mit gegensätzlichen Fragen verschiedenen Kundengruppen stellen, d. h. unterschiedlichen Gruppen von Personen, die unterschiedliche Funktionen der Kundenorganisation repräsentieren. Möglicherweise gibt es die Gruppe „Marketing“, die Gruppe „Buchhaltung“, die Gruppe „Produktion“ usw. Zum leichteren Verständnis dieses Modells nehmen wir jedoch an, dass wir nur einer Kundengruppe eine einzelne Frage stellen. Nachdem wir unser Antwortenpaar zusammengestellt haben (die Antworten auf die funktionale und die dysfunktionale Form), ordnen wir es in einem Raster zu, wie in Tabelle 1 dargestellt.

Tabelle 1 – Kano-Zuordnung

Beachten Sie, dass die fiktiven Kunden in unserem Beispiel auf die funktionale Frage mit gefallen und auf die dysfunktionale Frage mit erwarten geantwortet haben. Wenn wir dieses Paar dem Raster zuordnen, sehen wir, dass die Schnittmenge dieser beiden Attribute ein „E“ ist, wie das gelb markierte Quadrat anzeigt. Untersuchen wir, was das für unseren priorisierten Backlog bedeutet.

• E = Erreger. Hierbei handelt es sich um Funktionen, die der Kunde nicht erwartet hat, und die ein Produkt von den Konkurrenzprodukten unterscheidet. Sie sind schwer zu ermitteln, insbesondere zu Beginn, da es schwierig sein kann, die Fragen zu stellen, die interessante Features entlocken. Aus diesem Grund tendieren Erreger dazu, vorrangig bei fortschreitendem Projekt und bei einsetzendem Kundenfeedback zu entstehen und anzusteigen.

  • Kunden empfinden durch diese Features große Zufriedenheit und sind daher bereit, für diese einen Aufpreis zu zahlen. Der iPod von Apple hat beispielsweise Kunden mit seiner intuitiven Möglichkeit begeistert, Inhalte auf dem Bildschirm drehen zu können, damit diese mit der Ausrichtung des Bildschirms übereinstimmen. Das Fehlen dieses Merkmals hätte die Zufriedenheit nicht gemindert, da die Kunden es nicht erwartet hätten.

  • In unserem Beispiel wäre die GPS-Navigation ein faszinierendes Feature. Die Untersuchung dieses Features sollte zumindest bis zum Eintreffen des Kundenfeedbacks eine relativ hohe Priorität haben.

• B = Ausgangslage. Diese Features müssen im Produkt vorhanden sein. Dies sind die unverzichtbaren Features mit hoher Priorität.

  • Unabhängig davon, wie gut diese grundlegenden Attribute ausgeführt werden, verhält sich der Kunde zum Produkt neutral. Ein Textverarbeitungsprogramm muss z. B. über die Funktionen „Dokument erstellen“ und „Dokument speichern“ verfügen. Sie sind der Einstiegspreis.

  • Wenn wir unsere Kundengruppe zu Sicherheitsgurten befragt hätten, würden die meisten Leute antworten, dass sie bei einem neuen Auto Sicherheitsgurte erwarten und es ihnen nicht gefallen würde, wenn dies nicht der Fall ist. Wenn wir diese zwei Antworten im Raster zugeordnet hätten, würden wir feststellen, dass Sicherheitsgurte eine Ausgangslage (B) und somit ein unverzichtbares Feature sind.

• L = Linear. Lineare Funktionen, die auch als Leistungsanforderungen bekannt sind, korrelieren direkt mit der Kundenzufriedenheit. Sie liegen hinsichtlich der Priorität direkt unterhalb der Features der Ausgangslage, müssen aber gegen ihre Kosten abgewogen werden.

  • Eine erhöhte Funktionalität oder Ausführungsqualität erhöht die Kundenzufriedenheit. Eine verringerte Funktionalität reduziert die Kundenzufriedenheit.

  • Der Produktpreis wird häufig mit diesen Attributen in Verbindung gesetzt.

• I = Indifferent. Diese Features sind für den Kunden am unwichtigsten und sollten daher für das Produkt die geringste Bedeutung haben. Sie führen voraussichtlich zu einem geringen oder keinem Geschäftswert.

In Tabelle 1 werden auch Q und R angezeigt.

• Q: Fragwürdig – Die Frage ist vermutlich falsch oder die Antwort ist suspekt.

• R: Gegenteil – Die Kombination von Antworten steht im Widerspruch. Betrachten Sie das GPS-Navigationssystem: Wenn jemand antwortet, dass er es erwarten würde, aber es ihm gleichsam gefällt, wenn es nicht vorhanden ist, dann entspricht dies einer R-Antwort.

Wenn ein Antwortpaar mit Q oder R bewertet wird, sollten Sie Ihre Fragen oder das Antwortpaar eingehender untersuchen.

Innovationsspiele

Innovationsspiele sind Tools, die Ihnen bei der Entwicklung primärer Marktstudien helfen. Mit diesen Tools spielen Kunden „Spiele“ mit dem Ziel, Feedback und Informationen zu einem Produkt oder Dienst zu generieren. Luke Hohmann erstellt und beschreibt mehr als 12 dieser Spiele in seinem Buch Innovationsspiele, das für jede Bibliothek eine hervorragende Ergänzung darstellt. Meiner beiden bevorzugten Spiele zum Priorisieren eines Backlogs sind Reduzieren der Produktstruktur und Erwerben einer Funktion, die von Luke in diesem Auszug des Buchs beschrieben werden (mit Genehmigung verwendet):

Reduzieren der Produktstruktur

Gärtner stutzen Bäume, um deren Wachstum zu steuern. Das Stutzen erweist sich manchmal als kunstvoll und es ergeben sich Sträucher in Form von Tieren oder interessanten abstrakten Figuren. Häufig ist das Stutzen darauf ausgerichtet, einen ausgewogenen Baum zu erhalten, der qualitativ hochwertige Früchte trägt. Bei diesem Vorgang dreht es sich nicht um das „Stutzen“, sondern um die „Gestaltung“. Verwenden Sie diese Metapher, um Sie bei der Erstellung des Produkts zu unterstützen, das sich Ihre Kunden wünschen.

Das Spiel

Malen Sie zunächst einen großen Baum auf ein Whiteboard oder ein großes Blatt Papier, oder drucken Sie eine Baumgrafik als großformatiges Poster aus. Dicke Äste stellen die Hauptfunktionsbereiche innerhalb Ihres Systems dar. Der Rand des Baumes, seine äußeren Zweige, stellen die in der aktuellen Version verfügbaren Features dar. Schreiben Sie potenzielle neue Features auf verschiedene Karteikarten, die idealerweise die Form von Blättern haben. Bitten Sie Ihre Kunden, gewünschte Features um den Baum herum anzuordnen, um die nächste Wachstumsphase zu definieren. Bilden Sie einen Baum, der in ausgewogener Weise wächst? Erhält ein Zweig, vermutlich ein Hauptmerkmal des Produkts, den größten Teil des Wachstums? Wird ein nicht ausgenutzter Aspekt des Baumes stärker? Wir wissen, dass die Wurzeln eines Baumes (Ihre Support- und Kundendienstinfrastruktur) mindestens so weit reichen müssen wie seine Beschirmung. Reichen Ihre Wurzeln so weit?

Produktstruktur – Hohmann

Warum es funktioniert

Sie und Ihre Kunden wissen, dass die Bedeutung von Features variiert. Daher möchten wir unsere Bemühungen auf die wichtigsten Features konzentrieren, d. h. die Features, die den größten Wert für Kunden bieten. Leider bedeutet dies manchmal, dass wir uns zu wenig auf die Features konzentrieren, die zum Vervollständigen des Produkts erforderlich sind. Das Spiel „Reduzieren der Produktstruktur“ bietet Ihren Kunden eine Möglichkeit, um Beiträge für die Entscheidungsfindung bereitzustellen, indem Sie die Gruppe von Features ganzheitlich betrachten, die das Produkt bilden.

Erwerben einer Funktion

Welches Feature verleitet Ihre Kunden zum Kauf des Produkts? Welches Feature verleitet Kunden zu einem Upgrade? Welches Feature macht Kunden so glücklich, dass sie die Features ignorieren oder tolerieren, die sie lieber in geänderter Form oder überhaupt nicht vorfinden möchten?

Produktplaner erörtern diese und andere Arten von Fragen endlos. Die Auswahl der richtigen Gruppe von Features für eine Version macht häufig den Unterschied zwischen kurzfristigem Fehlschlag oder langfristigem Erfolg. Leider treffen zu viele Produktplaner diese Entscheidung, ohne die Personen einzubeziehen, die am stärksten davon betroffen sind – ihre Kunden. Das Spiel „Erwerben einer Funktion“ erhöht die Qualität dieser Entscheidung, indem die Kunden um ihre Unterstützung gebeten werden.

Erwerben einer Funktion – Sterne

Das Spiel

Erstellen Sie eine Liste der möglichen Features, und weisen Sie jeder einen Preis zu. Wie bei einem echten Produkt kann der Preis auf den Entwicklungskosten, dem Kundenwert oder auf etwas anderem basieren. Obwohl der Preis die Ist-Kosten darstellen kann, die Sie für das Feature ansetzen möchten, ist dies in der Regel nicht erforderlich. Kunden erwerben Features, die sie sich in der nächsten Version Ihres Produkts wünschen, mit dem Spielgeld, das Sie ihnen geben. Stellen Sie sicher, dass der Preis einiger Features hoch genug ist, dass sie von keinem Kunden erworben werden können. Ermutigen Sie Kunden dazu, ihr Geld zusammenzulegen, um besonders wichtige und/oder teure Features zu kaufen. Dadurch werden Gespräche zwischen Kunden angeregt, welche Features am wichtigsten sind.

Dieses Spiel funktioniert am besten mit vier bis sieben Kunden pro Gruppe. Dadurch ergeben sich für Kunden mehr Möglichkeiten, ihr Geld durch Verhandlung zusammenzulegen. Anders als das Spiel „Produktverpackung“ basiert das Spiel „Erwerben einer Funktion“ auf der Liste der Features, die vermutlich den Weg in Ihren Entwicklungsplan finden.

Warum es funktioniert

Produktplaner denken fälschlicherweise häufig, dass Kunden über eindeutig definierte Produktprioritäten verfügen. Bei einigen ist dies der Fall. Bei den meisten jedoch nicht. Wenn Kunden eine Reihe von Optionen angeboten werden, sagen viele einfach „Ich möchte sie alle“ und sie übergeben die Verantwortung für die Priorisierung ihrer Anforderungen dabei an Sie. Alternativ erfassen Produktmanager die Featureprioritäten häufig durch die Zusammenarbeit mit Kunden im Zweiergespräch und übernehmen in diesem Prozess wiederum die Verantwortung für die Priorisierung der Features, ohne dies vermutlich überhaupt zu bemerken. Durch die Einbindung von Kunden als Gruppe und die Bereitstellung einer begrenzten Anzahl von Ressourcen bieten Sie ihnen die Gelegenheit, ihre Wünsche als Gruppe zu priorisieren. Aber darin liegt das Geheimnis nicht verborgen. Das Geheimnis liegt in der Strukturierung der Unterhaltungen, sodass die Kunden hinsichtlich der bestimmten Features untereinander verhandeln. Es sind diese Verhandlungen, die Ihnen weitere Einblicke dahingehend vermitteln, was Ihre Kunden wirklich wünschen.

Relative Gewichtung – Karl Wiegers

Eine weitere hervorragende Methode für die Priorisierung ist die relative Gewichtung, die 1999 von Karl Wiegers eingeführt wurde. Diese Methode bietet nicht nur einen Mechanismus für die Priorisierung von Anforderungen basierend auf Benutzereingaben und Feedback, sondern umfasst auch das Sachverständigenurteil des Teams. Wie Kano und die Innovationsspiele ermöglicht die relative Gewichtung dem Produktbesitzer eine bessere Beurteilung, welche Features in welcher Prioritätsreihenfolge implementiert werden müssen.

Der erste Schritt ist die Zuordnung einer Gewichtung zum relativen Nutzen eines Features. Ein Nutzen ist der Vorteil für Benutzer, wenn das fertige Produkt über das Feature verfügt. Als Nächstes wird der relative Nachteil zugeordnet. Der Nachteil ist die Konsequenz für Benutzer, wenn das fertige Produkt nicht über das Feature verfügt. (Die Bewertung von Vorteilen und Nachteilen führt zu demselben Ergebnis wie die funktionale und dysfunktionale Form einer Frage der Kano-Methode.) Die Gewichtungen sind beliebige Zahlen, die darstellen, wie Ihr Unternehmen die Vorteile und Risiken von Features bewertet. Es entspricht sehr stark der Vorgehensweise von Lehrern bei der Bestimmung, welche Gewichtung Hausaufgaben, Anwesenheit, Tests und Klausuren bei der Gesamtnote haben. Sie variiert von Lehrer zu Lehrer. Wenn Sie entscheiden, dass Vorteile die Nachteile überwiegen, wählen Sie im gewünschten Verhältnis eine höhere Gewichtung als für die Nachteile. Wenn Sie entscheiden, dass Nachteile die Vorteile überwiegen, passen Sie die Gewichtung entsprechend an. Im Beispiel in Tabelle 2 hat der Vorteil die relative Gewichtung von 2 und der Nachteil die relative Gewichtung von 1 erhalten. Das bedeutet, dass der Vorteil der einflussreichere Faktor bei der Bestimmung der endgültigen Priorität ist.

Auf die gleiche Weise ermitteln wir die Gewichtung für die prozentuale Höhe der Kosten und Risiken. Im folgenden Beispiel wurde dem Risiko nicht so viel Bedeutung für das Projekt zugemessen, daher hat der Prozentsatz für die Kosten die Gewichtung 1 und der Prozentsatz für das Risiko die Gewichtung 0,5 erhalten. (Beachten Sie, dass Kosten und Risiko als Prozentsätze gewichtet werden, obwohl Vorteil und Nachteil vor der Berechnung des Prozentwerts gewichtet wurden.) Wenn ein Projekt mit hohem Risiko vorliegt, erhält das Risiko möglicherweise eine höhere Gewichtung als die Kosten.

Nachdem die Gewichtungen festgelegt sind, werden die Benutzer aufgefordert, den relativen Vorteil und den relativen Nachteil der einzelnen Features zu bewerten. Jeder Vorteil und jeder Nachteil wird anhand einer festgelegten Skala bewertet. Wiegers empfiehlt eine Skala von 1–9, aber solange Sie konsistent sind, können Sie auch eine andere Skala verwenden. Der relative Vorteil ist der Wert, den das Feature bietet. Der relative Nachteil ist die potenzielle negative Auswirkung, wenn das Feature nicht implementiert wird.

Nehmen wir beispielsweise an, dass ein mögliches Feature die „Entsprechung der Sarbanes-Oxley-Bestimmungen“ ist. Das bietet den Benutzern praktisch keinen relativen Vorteil, aber der relative Nachteil ist erheblich. Wenn dieses Feature nicht implementiert wird, könnte dies zum Ende der Geschäftstätigkeit des Unternehmens führen. Daher wird für den relativen Vorteil eine Bewertung von 1 oder 2 verwendet, während sich für den relativen Nachteil eine Bewertung von 8 oder 9 ergibt.

Im folgenden Beispiel haben Benutzer den relativen Vorteil des Features „Abfragestatus einer Lieferantenbestellung“ mit 5 bewertet. Den relativen Nachteil haben Sie mit 3 bewertet. Zur Ableitung des Gesamtwerts dieses Features werden die beiden Zahlen mit ihren relativen Gewichtungen multipliziert und anschließend addiert:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

In diesem Fall ergibt sich ein Gesamtwert von 13 Punkten für das Feature.

Wenn wir den relativen Gesamtwert und den Wertprozentsatz für die Features erhalten, wenden wir uns von den Benutzern ab, um Einblicke des Teams zu erhalten. Wir fordern das Team auf, die relativen Kosten für die Implementierung der einzelnen Features anhand derselben Skala einzuschätzen. Karl Wiegers erläutert, dass „Entwickler die Kostenbewertungen auf Grundlage von Faktoren wie der Anforderungskomplexität, des Umfangs der erforderlichen Arbeit für die Benutzeroberfläche, der potenziellen Möglichkeit zur Wiederverwendung vorhandener Entwürfe oder Codes und des Umfangs für erforderliche Tests und Dokumentationen schätzen“.

Nach der Schätzung der relativen Kosten wird das relative Risiko veranschlagt. Wiegers sagt dazu, dass „Entwickler den relativen Grad der technischen oder anderweitigen Risiken, die mit den einzelnen Features verbunden sind, auf einer Skala von 1 bis 9 schätzen. Der Wert 1 bedeutet, dass Sie das Feature im Schlaf programmieren können, während der Wert 9 auf schwerwiegende Bedenken hinsichtlich Realisierbarkeit, der Verfügbarkeit qualifizierter Mitarbeiter oder der Verwendung nicht bewährter oder unbekannter Tools hinweist. Das Arbeitsblatt berechnet den Prozentsatz des Gesamtrisikos, das mit den einzelnen Features einhergeht.“

Nachdem wir die relativen Werte für Vorteil, Nachteil, Kosten und Risiko notiert haben, werden die einzelnen Spalten zusammengefasst. Diese Gesamtwerte werden zur Berechnung der Prozentsätze verwendet.

• Wertprozentsatz gesamt: Dividieren Sie die Summe von relativem Vorteil und relativem Nachteil durch die im unteren Bereich befindliche Gesamtsumme. Im folgenden Beispiel ergibt dies „13/154 = 8 %“.

• Prozentsatz für relative Kosten: Teilen Sie den relativen Kostenwert durch die Gesamtsumme der relativen Kosten im unteren Bereich. Im folgenden Beispiel ergibt dies „2/42 = 4,8 %“.

• Prozentsatz für relatives Risiko: Teilen Sie den relativen Risikowert durch die Gesamtsumme des relativen Risikos im unteren Bereich. Im folgenden Beispiel ergibt dies „1/33 = 3 %“.

• Priorität: Teilen Sie den Wertprozentsatz durch (Kostenprozentsatz * Kostengewichtung) + (Risikoprozentsatz * Risikogewichtung). Im folgenden Beispiel wäre dies „8,4 %/((4,8 % * 1) + (3 % * 0,5)“. Dadurch ergibt sich der Prioritätswert (1,345).

Nachdem wir die Prioritätswerte erhalten haben, wird die Prioritätenspalte in absteigender Reihenfolge sortiert, damit die Elemente mit der höchsten Priorität am Anfang stehen. Wenn Elemente zum Product Backlog hinzugefügt oder weitere Informationen zu einem Kapitel verfügbar werden, muss die Priorität neu bewertet werden.

Am Ende sieht das Arbeitsblatt wie diese Tabelle aus:

Mit diesem Ansatz können Sie die Bandbreite besser verstehen, die für das Team und die Projektbeteiligten geeignet ist. Außerdem führt er zu besseren Grundlagendiskussionen, da es schwierig sein kann, Elemente wie Vorteil, Nachteil, Kosten und Risiko für die einzelnen Features objektiv zu berücksichtigen.

Wiegers erläutert, wie Sie das Modell realitätsnäher gestalten können:

„Kalibrieren Sie dieses Modell für Ihre eigenen Zwecke mit einer Reihe von abgeschlossenen Anforderungen oder Features eines früheren Produkts. Passen Sie die Gewichtungsfaktoren an, bis die berechnete Prioritätsreihenfolge mit der nachgestellten Auswertung übereinstimmt, wie wichtig die Anforderungen in Ihrer Testanordnung tatsächlich waren. Dieses Modell kann Ihnen auch dabei helfen, Kompromissentscheidungen zu treffen, wenn Sie vorgeschlagene neue Anforderungen auswerten. Schätzen Sie deren Priorität mithilfe des Modells ein, um Ihnen zu vermitteln, wie sie sich im Vergleich zu vorhandenen Anforderungen verhalten, damit Sie eine geeignete Implementierungsreihenfolge wählen können. Alle Maßnahmen, die Sie ergreifen können, um die Priorisierung von Anforderungen aus dem politischen in einen objektiven und analytischen Bereich zu verschieben, verbessern die Möglichkeiten des Projekts, die wichtigsten Funktionen in der zweckmäßigsten Reihenfolge bereitzustellen.“

Karl Wiegers hat zwei Bücher geschrieben, die sich eingehender mit der relativen Gewichtung befassen: Software Requirements, Second Edition und More About Software Requirements: Thorny Issues and Practical Advice.

Ganz gleich, ob Sie eine der folgenden Methoden oder ein anderes Verfahren anwenden, sollten Sie daran denken, dass das Product Backlog ein reges Wesen aufweist. Es wird nicht nur einmalig priorisiert und dann beiseite geschoben: Die erneute Priorisierung ist ein normaler Bestandteil der Verwaltung eines fehlerfreies Backlogs. Um Ihr Projekt auf Kurs zu halten, müssen Sie die Konzepte, ihre Bedeutung für das Projekt und die Auswirkung neuer Informationen auf das Backlog beständig neu bewerten. Sie müssen dafür Sorge tragen, dass die Beteiligten und Kunden im gesamten Verlauf des Projekts einbezogen werden. Darüber hinaus müssen Sie daran denken, dass die Einschätzung eines Elements für die Ermittlung seiner Priorität unerlässlich ist. Sorgen Sie dafür, dass Ihre Backlogs nicht veralten und ungültig werden. Investieren Sie Zeit und Mühe in die Hege und Pflege des Backlogs. Die Ergebnisse machen sich nicht nur im Endprodukt, sondern auch im Gewinn bemerkbar.

Siehe auch

Konzepte

Zusammenarbeit (weiter vertiefen) [umgeleitet]

Zusammenarbeit [umgeleitet]

Anforderungs-und Überprüfungs-Projektbeteiligte-Feed-back mit Team Web Access

Arbeitsnachverfolgung und Workflowverwaltung [umgeleitet]

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   „Attractive Quality and Must-be Quality“ Noriaki Kano, Quality JSQC, Vol. 14, Nr. 2, Oktober 1984. Der ursprüngliche Artikel von Kano.

2. First Things First: Prioritizing Requirements von Karl E. Wiegers