Sprintplanung

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.Diese Methoden ermöglichen Ihnen den Übergang von einer groben Priorisierung der Rückstandselemente hin zu einer präzisen Reihenfolge, bei der Risiken, Relevanz und Kundenzufriedenheit gegeneinander abgewogen werden.

Betrifft

Application Lifecycle Management; Team Foundation Server

In diesem Artikel:

• Einführung

• Das Kano-Modell der Kundenzufriedenheit

• Innovations-Spiele

  • Prune the Product Tree

  • Buy a Feature

• Relative Gewichtung – Karl Wiegers

• Schlussfolgerung

Damit das Team für agile Softwareentwicklung effektiv arbeiten kann, müssen Sie die Elemente im Produktrückstand nach Priorität ordnen und diese Prioritätszuordnung während des Projekts stets aktuell halten.Alle Produktrückstände müssen anhand von Geschäftswerten und -risiken priorisiert werden.Durch diese Prioritätszuordnung kann sich das Team besser auf die Funktionen konzentrieren, die wesentlich sind für den Produkterfolg.Ein gut sortierter und priorisierter Rückstand wirkt sich nicht nur positiv auf die Zufriedenheit von Team und Kunden aus, sondern auch auf den Unternehmensgewinn.Informationen über Rückstände erhalten Sie unter Erstellen und Verwalten des Produktrückstands, Erstellen des Produktrückstands oder Hinzufügen zum Produktrückstand und Bereinigen und Schätzen des Rückstands.

Beim Sortieren und Priorisieren des Produktrückstands müssen Sie viele Faktoren berücksichtigen und Entscheidungen begründen können.Am Anfang, wenn Sie noch einen völlig unsortierten und nicht priorisierten Produktrückstand haben, wird Ihnen der Arbeitsaufwand sicherlich immens vorkommen.Glücklicherweise müssen Sie jedoch nicht alle Elemente auf einmal exakt einsortieren.In Schätzung beschreibe ich eine Technik, die ich als "Die große Mauer" bezeichne. Hierbei handelt es sich um ein effektives Verfahren zur schnellen Einschätzung eines unbearbeiteten Produktrückstands. Darüber hinaus werden Beteiligte hinzugezogen, um eine grobe Priorisierung zu erreichen.

Diese grobe Priorisierung ist ein guter Ausgangspunkt und für Ihre Bedürfnisse möglicherweise schon ausreichend.Unter Umständen möchten Sie diese Prioritätszuordnung jedoch verfeinern oder das Ganze etwas wissenschaftlicher angehen.Dafür stehen unterschiedliche Verfahren zur Verfügung.Im folgenden Artikel stelle ich drei Methoden vor, die sich für viele Teams der agilen Softwareentwicklung sehr bewährt haben: das Kano-Modell für Kundenzufriedenheit, die Innovationsspiele von Luke Hohmann und das Modell der relativen Gewichtung nach Karl Wiegers.Diese Methoden ermöglichen Ihnen den Übergang von einer groben Priorisierung der Rückstandselemente hin zu einer präzisen Reihenfolge, bei der Risiken, Relevanz und Kundenzufriedenheit gegeneinander abgewogen werden.

Das Kano-Modell der Kundenzufriedenheit

Das Kano-Modell der Kundenzufriedenheit wurde in den achtziger Jahren von Noriaki Kano, Professor an der Rika Universität in Tokio, entwickelt.Das Modell bietet ein einfaches Klassifizierungsschema, das zwischen wesentlichen und differenzierenden Attributen unterscheidet.Anhand von Fragebögen werden Produktmerkmale visualisiert und Debatten innerhalb des Designteams angeregt.

Beim Kano-Modell werden sowohl funktionale als auch dysfunktionale Fragen gestellt.Angenommen, wir befragen Kunden zu einem GPS-Navigationssystem für Autos.Zunächst stellen wir eine funktionale Frage:

• Wie würden Sie es finden, wenn dieses Auto ein GPS-Navigationssystem hätte?

Wir beschränken die Reaktion auf folgende Antworten:

• Das würde mich sehr freuen.

• Das setze ich voraus.

• Das ist mir egal.

• Das nehme ich gerade noch so hin.

• Das würde mich stören.

Gehen wir für unser Beispiel davon aus, dass die fiktiven Kunden mit "Das würde mich sehr freuen" geantwortet haben.

Als nächstes verwenden wir dann die dysfunktionale Form der Frage:

• Wie würden Sie es finden, wenn dieses Auto kein GPS-Navigationssystem hätte?

Die fiktiven Kunden können aus den aufgelisteten Antworten wählen.Andere Antworten sind jedoch möglich und sogar wahrscheinlich.Gehen wir davon aus, dass unsere fiktiven Kunden mit "Das setze ich voraus" auf die dysfunktionale Form der Frage antworten.

Wenn wir diese Aktion für ein tatsächliches Projekt durchführen, können wir die dysfunktionale Befragung für mehrere Kundengruppen, also unterschiedliche Personenkreise mit unterschiedlichen Funktionen im Unternehmen, durchführen.Unterschiedliche Kundengruppen wären beispielsweise das Marketing, die Buchhaltung oder die Produktion.Der Einfachheit halber gehen wir in unserem Beispiel aber davon aus, dass wir nur einer Kundengruppe eine Frage stellen.Nach der Kompilierung des Antwortpaars (Antwort auf die funktionale und dysfunktionale Form) ordnen wir dieses wie in Tabelle 1 gezeigt in ein Raster ein.

Tabelle 1 – Kano-Zuordnung

Beachten Sie, dass in unserem Beispiel die fiktiven Kunden mit mag ich auf die funktionale Frage und mit erwarte ich auf die dysfunktionale Frage geantwortet haben.Ordnen wir dieses Paar in das Raster ein, stellen wir anhand des gelb hervorgehobenen Kästchens fest, dass die Schnittmenge der beiden Attribute ein E ergibt.Was bedeutet dies nun für unseren priorisierten Rückstand?

• E = Exiters (Begeisterungsfaktor).Dies sind Funktionen, die der Kunde nicht erwartet hat und die das Produkt von dem der Konkurrenz abheben.Die Identifizierung ist insbesondere zu Beginn sehr schwierig, da das Formulieren von Fragen, die letztendlich zu neuen, spannenden Funktionen führen, nicht einfach ist.Deshalb treten die sog. Exciters in Hinblick auf die Priorität oftmals erst mit zunehmendem Projektfortschritt und Beginn des Kundenfeedbacks auf.

  • Diese Funktionen bringen eine große Kundenzufriedenheit, sodass der Kunde bereit ist, einen angemessenen Preis dafür zu zahlen.So hat das iPod von Apple Kunden dadurch begeistert, dass die Ausrichtung des Displays an den Inhalt angepasst werden kann.Ein Fehlen dieser Funktion würde die Zufriedenheit jedoch nicht senken, da der Kunde diese Funktion gar nicht erwartete.

  • In unserem Beispiel wäre die Möglichkeit der GPS-Navigation eine herausragende Funktion.Dem Kundenfeedback für diese Funktion sollte eine relativ hohe Priorität zugewiesen werden.

• B = BaselineDiese Funktionen müssen im Produkt enthalten sein.Sie sind sogenannte "Must-Haves", Funktionen mit hoher Priorität.

  • Unabhängig davon, wie diese grundlegenden Attribute ausgeführt werden, der Kunde bleibt, was das Produkt angeht, neutral.Ein Textverarbeitungsprogramm muss beispielsweise Funktionen wie "Dokument erstellen" und "Dokument speichern" aufweisen.Diese sind quasi die Eintrittskarte, um überhaupt konkurrenzfähig zu sein.

  • Hätten wir unsere Kundengruppe nach Sicherheitsgurten gefragt, hätten die meisten wohl geantwortet, dass sie in einem neuen Auto Sicherheitsgurte erwarten und es nicht mögen, wenn diese fehlen.Ordnen wir diese beiden Antworten in unser Raster ein, stellen wir fest, dass Sicherheitsgurte zur Baseline (B) gehören, also eine "Must-Have"-Funktion darstellen.

• L = Linear.Auch als Leistungsanforderungen bezeichnet. Lineare Funktionen korrelieren direkt mit der Kundenzufriedenheit.Sie rangieren hinsichtlich der Priorität direkt unter den Baseline-Funktionen, müssen aber mit den Kosten abgeglichen werden.

  • Eine Steigerung von Funktionalität oder Qualität der Ausführung erhöht die Kundenzufriedenheit.Eine Reduzierung der Funktionalität mindert die Kundenzufriedenheit.

  • Der Produktpreis ist oftmals mit diesen Attributen verknüpft.

• I = Indifferent.Diese Funktionen haben für den Kunden die geringste Bedeutung und sollten deshalb auch die geringste Bedeutung für das Produkt haben.Sie wirken sich in der Regel kaum oder nur geringfügig positiv auf den Geschäftswert aus.

Tabelle 1 zeigt außerdem die Faktoren Q und R.

• Q: Questionable (fraglich) – Die Frage ist möglicherweise nicht korrekt oder die Antwort ist suspekt.

• R: Reverse (gegensinnig) – Die Kombination der Antworten kann nicht verarbeitet werden.Nehmen wir das GPS-Navigationssystem. Antwortet jemand, dass er ein solches System erwartet, es aber zudem auch mag, wenn es nicht vorhanden ist, dann ergibt das eine Antwort vom Typ R.

Wird ein Antwortpaar mit Q oder R bewertet, sollten Sie die Fragen oder Antwortpaare genauer untersuchen.

Innovations-Spiele

Mit Innovationsspielen können Sie primäre Marktforschungen betreiben.Mit diesen Tools spielen Kunden "Spiele", die darauf ausgerichtet sind, Feedback und Daten zu einem Produkt oder einer Dienstleistung zu erhalten.Luke Hohmann hat mehr als 12 solcher Spiele entwickelt und beschreibt diese in seinem Buch Innovation Games, das als großer Gewinn für jede Bibliothek gesehen werden kann.Meine beiden Lieblingsspiele daraus sind Prune the Product Tree und Buy a Feature, die Luke in diesem genehmigten Auszug aus seinem Buch wie folgt beschreibt und die sich hervorragend für die Priorisierung eines Produktrückstands eignen:

Prune the Product Tree

Gärtner beschneiden Bäume, um deren Wachstum zu kontrollieren.Manchmal kommen dabei kleine Kunstwerke (Tiere, abstrakte Formen) heraus.Ziel ist es jedoch, einen Baum so zu beschneiden, dass er einen möglichst hohen Ertrag liefert.Der Fokus liegt dabei auf dem "Formen" und nicht auf dem "Schneiden". Behalten Sie dies im Hinterkopf, und Sie können das Produkt generieren, das Ihre Kunden tatsächlich wünschen.

Das Spiel

Malen Sie zunächst einen großen Baum auf ein Whiteboard oder ein Blatt Papier, oder drucken Sie ein entsprechendes Motiv als großformatiges Poster aus.Dicke Äste stehen für die wesentlichen Funktionsbereiche in Ihrem System.Der Umriss des Baums, die äußeren Verzweigungen, stellen die Funktionen dar, die im aktuellen Release verfügbar sind.Schreiben Sie potenzielle, neue Funktionen auf verschiedene Registerkarten, die idealerweise die Form von Blättern aufweisen.Bitten Sie Kunden, die gewünschten Funktionen aufzuschreiben und am Baum aufzuhängen, sodass die nächste Wachstumsphase festgelegt wird.Kommt es dabei zu einem ausgeglichenem Wachstum?Oder wächst ein Zweig (möglichweise die Kernfunktion des Produkts) unverhältnismäßig stark?Gewinnt ein kaum genutzter Aspekt des Produkts (Baum) an Bedeutung?Wir wissen, dass die Wurzelns eines Baums (Support und Kundenservice) mindestens so lang sein müssen, wie die Krone des Baums.Ist das der Fall?

Produktstruktur - Hohmann

Warum es funktioniert

Sie und Ihre Kunden wissen, dass nicht alle Funktionen gleich wichtig sind.Deshalb neigen wir dazu, die meisten Anstrengungen in die wichtigsten Funktionen zu stecken, also in die Funktionen, die den Kunden den größten Gewinn bringen.Leider führt dies manchmal dazu, dass Funktionen vernachlässigt werden, die für die Vollständigkeit eines Produkts erforderlich sind.Das Prune the Product Tree-Spiel ermöglicht Ihren Kunden, Einfluss auf den Entscheidungsprozess zu nehmen, indem sie sich dem Produkt als Ganzes widmen.

Buy a Feature

Welche Funktion führt dazu, dass Kunden Ihr Produkt kaufen?Welche Funktion führt dazu, dass Kunden ein Upgrade durchführen?Welche Funktion würde Kunden so glücklich machen, dass ihnen der Verzicht auf gewünschte oder verbesserte Funktionen nicht so viel ausmachen würde?

Diese und ähnliche Fragen werden von Produktplanern oftmals endlos diskutiert.Die Auswahl der richtigen Funktionen für ein neues Release entscheidet häufig über Erfolg oder Misserfolg.Leider treffen zu viele Produktplaner eine Auswahl, ohne diejenigen mit einzubeziehen, die es betrifft – die Kunden.Beim Buy a Feature-Spiel helfen Ihnen Ihre Kunden, die richtige Entscheidung zu treffen.

Buy a Feature – Sterne

Das Spiel

Erstellen Sie eine Liste möglicher Funktionen, und ordnen Sie diesen einen Preis zu.Dabei kann der Preis wie bei einem richtigen Produkt auf den Entwicklungskosten, dem Kundenwert oder auf anderen Faktoren beruhen.Der im Spiel genannte Preis kann den Kosten entsprechen, die Sie für die Funktion berechnen möchten, notwendig ist dies jedoch nicht.Kunden kaufen Funktionen, die sie im nächsten Produktrelease nutzen möchten, mit dem von Ihnen ausgegebenem Spielgeld.Achten Sie darauf, den Preis für einige Funktionen so hoch anzusetzen, dass er von keinem Kunden gezahlt werden kann.Fordern Sie Ihre Kunden auf, Ihr Geld zu sammeln, um wichtige und/oder teure Funktionen erwerben zu können.Dadurch werden Verhandlungen zwischen den Kunden gefördert, wodurch deutlicher wird, welche Funktionen am wichtigsten sind.

Für dieses Spiel ist eine Spielstärke von vier bis sieben Kunden pro Gruppe ideal. So haben die Kunden eine bessere Möglichkeit zu Verhandeln und Gelder zusammenzulegen.Im Gegensatz zum Product Box-Spiel basiert Buy a Feature auf einer Liste von Funktionen, die vermutlich auch in Ihrem Entwicklungsplan enthalten sind.

Warum es funktioniert

Produktplaner glauben fälschlicherweise oftmals, dass Kunden klare Prioritäten hinsichtlich eines Produkts haben.Bei einigen ist das so.Bei den meisten nicht.Präsentiert man Kunden eine Reihe von Optionen, sagen die meisten: "Die möchte ich alle". Damit sind Sie dann wieder verantwortlich für die Priorisierung der Anforderungen.Alternativ ermitteln Produktmanager Funktionsprioritäten der Kunden oftmals in persönlichen Vier-Augen-Gesprächen. Dabei kommt es früher oder später jedoch wieder dazu, dass die Produktmanager den Priorisierungspart übernehmen.Indem Sie Kunden zu einer Gruppe zusammenfassen und ihnen begrenzte Ressourcen zur Verfügung stellen, können diese ihre Wünsche als Gruppe priorisieren.Das allein ist jedoch noch nicht das Geheimnis des Erfolgs.Das Geheimnis besteht darin, die Gespräche so zu strukturieren, dass die Kunden miteinander über die wichtigsten Funktionen verhandeln.Denn es sind diese Verhandlungen, die dazu führen, dass Sie besser verstehen, was Ihre Kunden möchten.

Relative Gewichtung – Karl Wiegers

Eine weitere hervorragende Methode zur Priorisierung ist das Modell der relativen Gewichtung (Relative Weighting), das 1999 von Karl Wiegers eingeführt wurde.Diese Methode stellt nicht nur Feedback sowie einen Mechanismus zum Priorisieren von Anforderungen basierend auf Benutzereingaben bereit, sondern enthält zudem die fachliche Beurteilung des Teams.Genau wie beim Kano-Modell und den Innovation Games kann der Produktbesitzer besser einschätzen, welche Funktionen implementiert werden sollten und welche Funktionen eine hohe oder niedrige Priorität haben.

Der erste Schritt besteht darin, eine Gewichtung zu einem relativen Nutzen einer Funktion zuzuweisen.Der Nutzen bzw. Vorteil für den Benutzer besteht darin, dass die Funktion im Endprodukt enthalten ist.Als nächstes ist die relative Leistungsmessung zuzuweisen.Die Strafe ist die Konsequenz für Benutzer und besteht darin, dass die Funktion im Endprodukt nicht enthalten ist.(Durch Bestimmen von Vorteilen und Strafen wird das Gleiche erreicht, wie mit den funktionalen und dysfunktionalen Fragen der Kano-Methode.) Die Gewichtungen sind beliebige Zahlen, die darstellen, wie Ihr Unternehmen Vorteile und Risiken von Funktionen bewertet.Dabei wird ähnlich vorgegangen, wie in der Schule, in der der Lehrer den Hausarbeiten, der Teilnahme am Unterricht und den Tests unterschiedliche Gewichtungen zuweist. Daraus ergibt sich dann eine Gesamtnote. Die Gewichtung der einzelnen Faktoren ist dabei von Lehrer zu Lehrer unterschiedlich.Wenn Sie entscheiden, dass die Vorteile wichtiger sind, als die Strafen, legen Sie ein entsprechendes Verhältnis fest.Sind Sie der Meinung, dass die Strafen mehr Gewicht haben sollten, ändern Sie das Verhältnis entsprechend.Im Beispiel in Tabelle 2 haben die Vorteile ein relatives Gewicht von 2 und die Strafen ein relatives Gewicht von 1. Damit haben die Vorteile beim Festlegen der endgültigen Priorität eine stärkere Gewichtung.

Auf die gleiche Weise werden der prozentuale Kostenanteil und der prozentuale Risikoanteils festgelegt.Im folgenden Beispiel spielte das Risiko für das Projekt nur eine untergeordnete Rolle. Deshalb wurde der prozentuale Kostenanteil mit 1 gewichtet und der prozentuale Risikoanteil mit 0,5.(Beachten Sie, dass, obwohl Vorteile und Strafen gewichtet werden, ehe die Berechnung des Wertanteils erfolgt, Kosten und Risiken als Prozentsätze gewichtet werden.) Bei einem Projekt mit hohem Risiko werden Sie das Risiko vermutlich höher gewichten als die Kosten.

Nachdem die Gewichtungen festgelegt wurden, werden die Benutzer aufgefordert, den relativen Nutzen und die relative Leistungsminderung der Funktion zu bewerten.Jeder Vorteil und jede Strafe ist auf einer festgelegten Skala definiert. Wiegers empfiehlt eine Bewertung von 1 - 9. Sie können jedoch auch eine andere Skala auswählen, solange diese konsistent ist.Der relative Vorteil ist der Wert, den die Funktion erzielt; die relative Strafe gibt die potenziellen negativen Auswirkungen an, die durch das nicht Einführen der Funktion entstehen können.

Angenommen, eine mögliche Funktion ist "Das Widget soll den Sarbanes-Oxley-Bestimmungen entsprechen". Praktisch entsteht dadurch für die Benutzer kein Vorteil, die relative Strafe für das Unternehmen ist jedoch hoch. Werden die Bestimmungen nicht eingehalten, kann dies das Aus des Unternehmens bedeuten.Als Resultat erhalten wir 1 oder 2 Punkte für den relativen Vorteil und 8 oder 9 Punkte für die relative Strafe.

Im folgenden Beispiel bewerteten Benutzer den relativen Vorteil der Funktion "Status einer Lieferantenbestellung abfragen" mit 5.Für die relative Strafe gab es eine 3.Um den Gesamtwert dieser Funktion zu berechnen, multiplizieren wir die zwei Zahlen mit ihrem relativen Gewicht und addieren sie miteinander.

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

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

Dadurch erhält die Funktion insgesamt 13 Punkte.

Nachdem wir nun den gesamten relativen Wert und den Wertanteil der Funktionen haben, entfernen wir uns von den Benutzern und wenden uns dem Team zu.Wir bitten Sie mittels derselben Skala zu schätzen, welche relativen Kosten durch das Implementieren der Funktion entstehen würden.Dazu Karl Wiegers: "Entwickler schätzen die Kosten anhand verschiedener Faktoren ein. Dazu zählen: Komplexität der Anforderung, Umfang der Arbeiten an der Benutzeroberfläche, Wiederverwendbarkeit von Design und Code, Ausmaß an Tests und erforderliche Dokumentationen."

Nach der Schätzung der relativen Kosten erfolgt das Schätzen des relativen Risikos.Wiegers hierzu: "Entwickler schätzen das Ausmaß technischer oder anderer Risiken, die mit der Funktion verbunden sind. Dabei steht ihnen eine Skala von 1 bis 9 zur Verfügung.1 bedeutet, eine Programmierung nahezu im Schlaf, 9 bedeutet, ernsthafte Sorgen über Umsetzbarkeit, die Verfügbarkeit von Mitarbeitern mit den erforderlichen Kenntnissen oder die Verwendung von nicht getesteten oder unbekannten Tools.Über das Arbeitsblatt wird dann der Prozentsatz des gesamten Risikos errechnet, der sich aus den einzelnen Funktionen ergibt."

Nachdem die Werte für Vorteil, Strafe, Kosten und Risiken eingetragen wurden, werden die einzelnen Spalten aufsummiert.Anhand dieser Summen werden die Prozentsätze errechnet.

• Wertanteil gesamt: Um den Wertanteil insgesamt zu bestimmen, wird der Summenwert des relativen Vorteils und der relativen Strafe durch die Gesamtsumme am Ende der Spalte dividiert.Im folgenden Beispiel heißt das: 13/154 = 8 %.

• Relativer Kostenanteil: Zur Berechnung des relativen Kostenanteils wird der Wert der relativen Kosten durch die gesamten relativen Kosten am Ende der Spalte dividiert.Im folgenden Beispiel heißt das: 2/42 = 4,8 %.

• Relativer Risikoanteil: Zur Berechnung des relativen Risikoanteils wird der relative Risikowert durch die relative Risikosumme am Ende der Spalte dividiert.Im folgenden Beispiel heißt das: 1/33 = 3 %.

• Priorität: Wertanteil geteilt durch (Kostenanteil * Kostengewichtung) plus (Wertanteil * Wertgewichtung).Im folgenden Beispiel heißt das 8,4 % / ((4,8 % * 1) + (3 % * 0,5).Dies gibt den Prioritätswert (1,345).

Nachdem die Prioritätswerte ermittelt wurden, wird die Prioritätsspalte absteigend sortiert, sodass Elemente mit der höchsten Priorität oben sind.Werden weitere Elemente zum Produktrückstand hinzugefügt oder kommen neue Informationen hinzu, muss die Prioritätszuordnung neu bewertet werden.

Am Ende sieht das Blatt wie diese Tabelle aus:

Mit diesem Ansatz können Sie leichter die Bereiche identifizieren, die für das Team und für die Projektbeteiligten wichtig sind.Es verbessert auch die Diskussionsgrundlage, da eine objektive Bewertung von Faktoren wie Vorteil, Strafe, Kosten und Risiko für einzelne Funktionen recht schwierig ist.

Wiegers erläutert, wie Sie das Modell in die Praxis übertragen können:

"Passen Sie das Modell an Ihre Bedürfnisse an, und nutzen Sie erfüllte Anforderungen und abgeschlossene Funktionen aus einem vorherigen Produkt.Passen Sie die Gewichtungsfaktoren an, bis die berechnete Prioritätsreihenfolge mit Ihrer nachträglichen Auswertung der tatsächlichen Relevanz der Anforderungen für den Test übereinstimmt.Dieses Modell hilft Ihnen auch bei der Bewertung neuer Anforderungen Kompromisse einzugehen.Ermitteln Sie deren Priorität mithilfe des Modells, um herauszufinden, wie Sie mit vorhandenen Anforderungen übereinstimmen. Anschließend können Sie dann eine entsprechende Implementierungsreihenfolge festlegen.Alle Aktionen, mit denen Sie die Anforderungspriorisierung aus dem politischen Bereich in einen objektiven und analytischen verschieben können, tragen dazu bei, dass Sie bei Ihrem Projekt die wichtigsten Funktionen in optimaler Reihenfolge bereitstellen können.

Karl Wiegers hat zwei Bücher geschrieben, die ausführlich auf die relative Gewichtung eingehen: Software Requirements, Second Edition und More About Software Requirements: Thorny Issues and Practical Advice.

Egal, ob Sie nun eine der vorgestellten Methoden oder ein anderes Verfahren einsetzen, denken Sie immer daran, dass ein Produktrückstand kein statischer Zustand ist.Ein Produktrückstand wird nicht nur einmal priorisiert und gilt dann für die Ewigkeit. Für einen "gesunden" Produktrückstand sind regelmäßige Neufestsetzungen der Prioritäten erforderlich.Damit Ihr Projekt immer auf dem neuesten Stand ist, müssen Sie stetig Neubewertungen der Stories vornehmen und einschätzen, welchen Einfluss neue Informationen auf den Rückstand haben.Sie müssen sich darum bemühen, dass Beteiligte und Kunden während des gesamten Prozesses im Projekt involviert sind.Darüber hinaus dürfen Sie nicht vergessen, dass die Bewertung eines Elements wesentlich ist für dessen Prioritätszuordnung.Vermeiden Sie veraltete Rückstände.Pflegen und kümmern Sie sich um Ihre Rückstände. Dies kommt nicht nur dem Endprodukt, sondern auch dem Geschäftsergebnis zugute.

Siehe auch

Konzepte

Erste Schritte im Team

Agile-Planung und -Iterationen

Fragen Sie die Projektbeteiligte-Feed-back und verarbeiten Sie mit Team Web Access verwenden

Arbeitsnachverfolgung und Workflowverwaltung

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   "Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol.14, No.2, October 1984.Der Originalartikel von Kano.

2. http://www.processimpact.com/articles/prioritizing.html