Anforderungen mit Verfallsdatum
Es sind zu viele. Die Menge ist zu groß. Es ist einfach nicht zu schaffen und jeden Moment kommen neue hinzu. Die Rede ist von Anforderungen. Von Kunden und Interessenten erhalten Sie Anforderungen. Das Produktmanagement erstellt Wettbewerbsvergleiche und das Ergebnis führt zu neuen Anforderungen. Marketing und Vertrieb wollen Verkaufschancen verbessern und auch das führt zu neuen Anforderungen. Neue Gesetze, Normen, Regeln, freiwillige Auflagen – alles führt zu Anforderungen. Irgendwann verlieren Sie den Überblick. Die Menge der Anforderungen ist zu groß. Und nun? Wie können Sie Anforderungen reduzieren oder eliminieren? Nach welchen Kriterien gehen Sie vor? Was halten Sie von der Idee, Anforderungen mit einem Verfallsdatum zu versehen?
Die Prüfung formaler Kriterien
Wenn Sie die Menge der Anforderungen reduzieren wollen, liegt es nahe, Anforderungen auf formale Kriterien zu überprüfen. Sie können beispielsweise überprüfen, ob jede Anforderung eine Quelle, einen Beschreibungstext, einen erwarteten Nutzen oder ein Abnahmekriterium hat. Arbeiten Sie in Ihren Projekten mit einem Anforderungsmanagement-System finden Sie leicht die Anforderungen, die Ihren formalen Kriterien nicht genügen. Es könnte allerdings sein, dass Ihre Software Sie daran hindert, eine Anforderung als definiert zu deklarieren, wenn die hinterlegten formalen Kriterien noch nicht erfasst wurden. Das würde bedeuten, dass Sie erst weitere Arbeit in die formale Beschreibung der Anforderungen investieren müssten, bevor Sie sich Gedanken machen können, ob Sie die Anforderungsmenge um genau diese eine Anforderung reduzieren. Anforderungen anhand der Existenz formaler Kriterien zu eliminieren, kann also ein Mittel zur Reduzierung von Anforderungen sein, muss es aber nicht.
Die Prüfung des Systemkontexts
Bei der Entwicklung von Systemen ist die Definition des Systemkontexts eine der ersten Aufgaben. Mit dem Systemkontext bestimmen Sie die Grenzen Ihrer Entwicklung, das heißt Sie legen einen Bereich fest, für den Sie Anforderungen erfassen wollen. Definieren Sie beispielsweise, dass Sie ein neues System C bauen wollen, das mit System B interagieren soll, ist es für Ihr Projekt unerheblich, ob es neue Anforderungen für System A gibt. System A liegt in der sogenannten irrelevanten Umgebung. Gibt es Anforderungen zur Kommunikation zwischen System B und System C, so ist es an Ihnen zu definieren, ob diese Anforderungen zu Ihrem Scope gehören oder eben nicht.
Haben Sie zu Beginn eines Projekts einen solchen Systemkontext definiert, können Sie sich bei jeder neuen Anforderung fragen, ob diese in der zu beachtenden Umgebung liegt. Falls nicht, gibt es aus Sicht Ihres Projekts keinen Grund, diese Anforderung weiter zu verfolgen. Definieren Sie den Systemkontext verspätet im Laufe eines Projekts oder ändert sich der Systemkontext aufgrund einer Verschiebung des Scopes, können Sie vorhandene Anforderungen entsprechend überprüfen und gegebenenfalls eliminieren. Natürlich können Sie die so gefundenen Anforderungen auch in ein anderes Projekt transferieren – so oder so: die Menge der Anforderungen lässt sich dadurch reduzieren.
Häufig kämpfen Organisationen mit zu vielen Anforderungen. Ist es Zeit für ein Umdenken?
Die Prüfung der Ziele
Kennen Sie die Stakeholder Ihrer Entwicklung und deren Ziele? Aus den Zielen ergeben sich häufig Anforderungen. Wenn sich Ziele von Stakeholdern widersprechen, dann müssen Sie zu einem Zeitpunkt in Ihrer Entwicklung entscheiden, welches Ziel von welchem Stakeholder wichtiger ist. Zieldiagramme sind hierfür übrigens ein gutes Ausdrucksmittel. Idealerweise treffen Sie eine solche Entscheidung möglichst frühzeitig und kommunizieren Sie diese mit den betroffenen Stakeholdern. Folglich können Sie die Menge der Anforderungen um die Anforderungen reduzieren, die dem nachrangigen Ziel entsprechen.
Die Prüfung auf unbewusste Redundanz
Die Prüfung auf Redundanz, sprich auf ähnlich formulierte Anforderungen, die dasselbe meinen, dies aber nur unterschiedlich ausdrücken, ist eine gute Möglichkeit, Anforderungen zu eliminieren. Es gibt viele Gründe für redundante Anforderungen: Anforderungen werden von unterschiedlichen Personen erfasst, die schlicht nicht wissen, dass entsprechende Anforderungen bereits existieren. Oder die zeitliche Erfassung zweier Anforderungen liegt so weit auseinander, dass der Autor sich nicht mehr an die bereits vorhandene Anforderung erinnert. Entscheidend bei der Prüfung auf Redundanz ist, ob Redundanzen beabsichtigt sind. So kann es sein, dass in einem Gesamtsystem mehrere Teilsysteme dieselbe Funktion parallel ausführen sollen oder dass in einem System eine redundante Funktion im Falle eines Fehlers ausgeführt wird. Die Menge an Anforderungen lässt sich also um unbewusste Redundanzen reduzieren.
Die Prüfung der Prioritäten
Anforderungen werden priorisiert. Die Praxis zeigt, dass eine Priorisierung mit Stufen wie „hoch, mittel, niedrig“ oder „must, should, could, won’t“ häufig dazu führt, dass jede Anforderung in die höchste Prioritätsstufe eingeordnet wird. Dies liegt daran, dass der Verfasser der Anforderung fürchtet, eine niedriger priorisierte Anforderung besäße keinerlei Chance auf Realisierung. Würde er zusätzlich noch fürchten, dass die von ihm erfasste und nicht maximal hoch priorisierte Anforderung eliminiert werden könnte, so würde wohl jeder Verfasser seine Anforderung als „mega-wahnsinnig-unglaublich-wichtig“ einstufen.
Es gibt Organisationen, die arbeiten mit absoluten und nur einmalig zu vergebenden Prioritäten. Dies hat den Vorteil, dass keine Anforderung genauso wichtig ist wie eine andere. Eine Anforderung mit Priorität 863 ist wichtiger als eine Anforderung mit Priorität 716. Enthält die Anforderungsliste 1.000 Elemente, können Sie so sehr leicht erkennen, wie viele Anforderungen noch wichtiger und wie viele weniger wichtig sind. Manche Organisationen vergeben sogar absolute Prioritäten unabhängig von der tatsächlichen Menge der vorhandenen Anforderungen. So lässt sich noch leichter ausdrücken, dass die Anforderung xyz mit einer Priorität von 2.000 doppelt so wichtig ist, wie die Anforderung abc mit Priorität 1.000. Leider hilft diese Erkenntnis zwar bei der Priorisierung, nicht aber bei der Reduzierung der Anforderungen, denn ab welcher Prioritätsgrenze sollten denn Anforderungen eliminiert werden, wenn ständig neue Anforderungen hinzukommen?
Für die Priorisierung von Anforderungen gibt es neben den einfachen qualitativen Verfahren auch analytische Priorisierungsverfahren wie die „Wiegers’sche Priorisierungsmatrix“ oder das „Kano-Modell“ mit Basis-, Leistungs- und Begeisterungsmerkmalen. Diese Verfahren verursachen deutlich mehr Aufwand als die einfachen Priorisierungsverfahren, liefern aber in der Regel Ergebnisse mit größerer Aussagekraft. Leider lässt sich auch hier nicht eindeutig ableiten, wie Sie mit den gewonnenen Ergebnissen die Menge der Anforderungen reduzieren können. Als Hersteller sollten Sie nicht auf Basismerkmale verzichten, denn diese sind für Kunden und Anwender selbstverständlich, werden aber erst dann bewusst zur Kenntnis genommen, wenn sie nicht vorhanden sind. Auch auf Leistungsmerkmale sollten Sie nicht verzichten, denn Kunden fordern diese explizit und sind sie nicht vorhanden, ist der Kunde unzufrieden. Und auf Begeisterungsmerkmale werden Sie nicht verzichten wollen, denn sie bieten die größte Chance sich vom Wettbewerb abzuheben. Leider sind sie nicht leicht zu ermitteln, wenn Sie also tatsächlich Begeisterungsmerkmale identifiziert haben, sollten Sie diese nicht eliminieren.
Umsetzungdatum, Wiedervorlage und Verfallsdatum
Haben Sie beim Umgang mit Anforderungen schon einmal mit einem Verfallsdatum gearbeitet? Warum nicht? Haben Sie einmal die Erfahrung gemacht, dass eine Anforderung, die Sie vor zwei Jahren erfasst haben, tatsächlich noch realisiert wurde? Ja? Wie sieht es aus bei einer Anforderung, die vor drei Jahren erfasst wurde? Ist Ihre Antwort wieder „Ja“? Glückwunsch! Bei wie vielen Anforderungen war das der Fall? Vermutlich war es selbst bei Ihnen nur die Ausnahme und nicht die Regel. Vielleicht laufen Ihre Projekte keine zwei oder drei Jahre. Vielleicht erfassen Sie im Laufe eines Projekts keine neuen Anforderungen. Oder Sie arbeiten in einem sehr eingespielten Team und dokumentieren einfach weniger. In vielen Organisationen ist es aber die Regel, dass es einen Punkt gibt, an dem Anforderungen nur noch altern. Sie liegen fest im Backlog oder in Anforderungslisten, ohne Chance jemals realisiert zu werden. Und jeden Tag kommen neue Anforderungen hinzu. Der Berg wird immer größer, die Menge an Anforderungen steigt.
Was können Sie tun? Sie könnten einen Umsetzungszeitpunkt definieren, also einen Datum bestimmen, bis wann eine Anforderung umgesetzt werden sollte. Alternativ könnten Sie Anforderungen zukünftigen Entwicklungsreleases zuordnen. Das machen Sie vielleicht bereits heute, vermutlich aber nicht für jede Anforderung. Und das hat zwei Gründe:
- Sie können die Umsetzung der Anforderung zum heutigen Zeitpunkt nicht beurteilen. Wenn Sie die Anforderung aber als relevant einstufen, könnten Sie mit einer Wiedervorlage arbeiten. So würden Sie zu einem späteren Zeitpunkt dieselbe Anforderung mit hoffentlich neuem Wissen beurteilen können und entscheiden, ob und bis wann oder in welchem Release sie umgesetzt werden soll.
- Sie glauben nicht daran, dass diese Anforderung realisiert wird. Warum heben Sie die Anforderung auf? Sie könnten sie schlicht eliminieren (oder in anderen Worten mit einem Zustand wie „abgelehnt“ oder „archiviert“ versehen, so dass sie in Ihrem Anforderungssystem erhalten bleibt, Sie aber nicht bei Ihrer regelmäßigen Arbeit mit Anforderungen beeinflusst).
Alternativ zum Umsetzungsdatum könnten Sie mit einem Verfallsdatum arbeiten. Sie bräuchten keine explizite Wiedervorlage, denn bei der Einplanung von Anforderungen in zukünftige Releases arbeiten Sie praktisch immer gegen das Verfallsdatum. Doch wie weit in der Zukunft sollte ein Verfallsdatum liegen? Sie könnten sich die Beantwortung leicht machen und sagen, dass Sie jede Anforderung, die nicht binnen x Jahren oder y Monaten realisiert wird, zukünftig nicht mehr beachten wollen. Oder Sie könnten versuchen mittels Mengenüberlegungen eine Antwort zu finden. Fragen dazu wären: Wie viele Anforderungen verwalten Sie in Ihrem Anforderungsmanagement-System und wie viele davon können Sie in einem zu definierenden Zeitraum realisieren? Und wie viele Anforderungen kommen im Laufe dieses definierten Zeitraums hinzu? Oder Sie finden die Antwort in Abhängigkeit der Granularität der Anforderungen. Ein Epic setzen Sie nicht so schnell um wie eine Story. Die Implementierung einer neuen Datenbank für ein bestehendes System beansprucht viel mehr Zeit und Aufwand als das Einfärben eines vorhandenen Buttons in eine andere Farbe. Sie müssten sich also entscheiden, ob Sie für jede Granularitätsstufe ein Verfallsdatum etablieren wollen oder beispielsweise nur auf der Ebene von Stories.
Fazit
Vermutlich nutzen Sie zum heutigen Zeitpunkt beim Umgang mit Anforderungen weder Wiedervorlage noch Verfallsdatum. Auch wenn Organisationen häufig mit zu vielen Anforderungen kämpfen, sind Fragen nach dem Zeitpunkt einer Wiedervorlage oder nach der passenden Granularitätsstufe für die Verwendung von Verfallsdaten nicht leicht zu beantworten. Die Reduzierung der Anforderungen verursacht Aufwand, aber ohne diesen Aufwand wird der Berg an Anforderungen kontinuierlich anwachsen und die Übersicht und das permanente Arbeiten mit Anforderungen erschwert. Wenn Sie die Menge der Anforderungen dauerhaft reduzieren wollen, dann macht ein Umdenken Sinn. Die Verwendung von Wiedervorlagen oder von Verfallsdaten sind interessante Möglichkeiten für die gezielte Reduzierung bzw. Eliminierung von Anforderungen. Probieren Sie es doch einfach aus.
Hinweis:
Einige dieser Gedanken stammen aus einem Austausch auf XING mit Till-J. Faßold, Olaf Barheine und Rainer Wendt. Die Kommunikation finden Sie hier.
Zum Thema Prioritäten: Marktplatz
Das im folgenden beschriebene Verfahren zur Priorisierung von Anforderungen (Bezeichnung bei uns = Tickets) wird bei uns seit einigen Jahren mit großem Erfolg eingesetzt. Es basiert auf einem Blog-Artikel, den ich vor Jahren gelesen habe (Quelle leider unbekannt).
Es liegt das Modell eines Marktplatzes oder einer Auktion zugrunde, in der Waren und Dienstleistungen hergestellt und verkauft werden. Durch den Fluss von virtuellem Geld und dem Prinzip von Angebot und Nachfrage werden die knappen Ressourcen optimal eingesetzt. Auf diesem Markt gibt es die folgenden Objekte:
* Käufer – Die Stakeholder
* Verkäufer – Die Entwickler
* Waren und Dienstleistungen – Ticketbearbeitung durch die Entwickler: Planung, Analyse, Aufwandschätzung, Programmierung, Test, Dokumentation
* Geld – Punkte, die jeder Käufer auf die Tickets setzen kann (*1).
* Kosten – Der geschätzte Aufwand für die Umsetzung eines Tickets
* Priorität – Berechnet sich aus den Kosten und dem Geld, legt die Reihenfolge der Ticketbearbeitung fest (*2).
Das Verfahren wurde mit Excel realisiert. Eine Umsetzung in in-STEP BLUE sollte aber auch möglich sein.
(*1) Jedem Käufer steht zunächst einmal die gleiche „Geld-“ d. h. Punktemenge zur Verfügung. Dies wird durch Formeln in der Excel-Tabelle gewährleistet, in dem die einzelnen Punktwerte durch die Summe der Punkte je Käufer geteilt werden. Man muss also nicht von Hand dafür sorgen, dass eine bestimmte Gesamtpunktzahl eingehalten wird. Maßgeblich ist allein das Verhältnis der Punkte. Ggf. behält sich der Prozesseigner (Geschäftsführung o. ä.) vor, einzelnen Stakeholdern „,mehr Geld in die Hand zu geben“, d. h. die Punktwertung dieser Käufer höher zu gewichten.
(*2) Je „teurer“ ein Ticket ist, d. h. je höher der Aufwand für die Umsetzung, desto mehr Geld muss aufgewendet werden, d. h. desto mehr Punkte müssen die Käufer diesem Ticket geben, damit es umgesetzt wird. Umgekehrt bekommen „preiswerte“ Tickets, die mit geringem Aufwand umgesetzt werden können, schon mit wenigen Punkten eine hohe Priorität. Die Priorität berechnet sich aus der Summe der je Käufer gewichteten Punkte geteilt durch den geschätzten Aufwand in Personentagen. Die Zahlenwerte werden so normiert, dass das Ticket mit der höchsten Priorität den Zahlenwert 100 bekommt. Man könnte diese Zahl auch so deuten, dass sie der Wahrscheinlichkeit entspricht, dass dieses Ticket bald bearbeitet wird. Die Leitung behält sich vor, eigene Prioritäten außerhalb dieses Prozesses festzulegen.
Da allein schon das Schätzen des Aufwands in Personentagen für die Umsetzung eines Tickets einen Zeitaufwand darstellt, der vom Team nicht für alle Tickets geleistet werden kann, wird wie folgt vorgegangen:
Wenn noch keine Aufwandschätzung erfolgt ist, bleibt das Feld zum Ticket in der zugehörigen Spalte in der Excel-Tabelle leer und es wird ein konfigurierbarer Default-Wert für die Berechnung der Priorität angenommen, der bei uns heuristisch auf 2 Tage festgelegt wurde.
Die Aufwandschätzung erfolgt erst, wenn ein Ticket eine ausreichend hohe Priorität hat. Tickets mit geringer Priorität brauchen gar nicht betrachtet werden (Erfahrungswert: Bei uns gibt es momentan nur bei ca. 6% aller offenen Tickets eine Aufwandschätzung).
Wird ein hoher Aufwand geschätzt, wandert das Ticket in der Liste sofort weiter nach unten. Die Stakeholder müssen diesem Ticket also mehr Punkte geben, damit es wieder eine höhere Priorität bekommt und die Chance auf eine Umsetzung steigt.
Wird ein niedriger Aufwand geschätzt (< 2 Personentage), wandert das Ticket in der Liste weiter nach oben und wird ggf. sogar sofort bearbeitet.
Die Daten zu abgeschlossenen Tickets (Punkte und Prioritäten) werden aus der Liste entfernt. Dadurch ändert sich ggf. auch die Priorität der anderen Tickets, da diese entfernten Punkte nun nicht mehr auf dem "Punktekonto" des jeweiligen "Käufers" stehen. Ein "Käufer" bekommt also dadurch quasi "neues Geld". Er wird durch die Bearbeitung "seines" Tickets damit belohnt, dass seine auf andere, offene Tickets verteilten Punkte einen höheren Wert bekommen. Dies ist ein ausdrücklich erwünschter Effekt, der den "Käufer" motivieren soll, regelmäßig neue Punkte zu verteilen.
Einem Ticket kann auch ein negativer Punktwert gegeben werden. Damit kann ein Stakeholder ausdrücken, dass er eine Umsetzung nicht für sinnvoll erachtet. Daraus kann sich unter Umständen eine negative Priorität ergeben, die dafür sorgt, dass solche Tickets aus der Liste entfernt werden.
Hallo Herr Reimann,
das ist ja ein großartiges, individuelles Vorgehen. Danke für diesen tollen Einblick. Wie lange hat es denn gedauert, bis Sie alle Beteiligten davon überzeugen konnten?
Sonnige Grüße
Michael Schenkel
Hallo Herr Schenkel,
Es hat schon ein wenig gedauert und es nehmen noch nicht alle Kollegen teil. Einigen war die Beschreibung des Verfahrens wohl zu umfangreich. Was mich überrascht hat: Bei den großen Themen, d. h. aufwändigen Anforderungen besteht recht große Einigkeit.
Wolkige Grüße aus NRW
Volker Reimann