Jeder Anwendungsfall bzw. jede User Story hat für die Stakeholder einen bestimmten Wert. Im Agilen wird dieser Wert als Business Value (zu Deutsch: Geschäftswert) bezeichnet. Bei einem agilen Vorgehen ist eine detailliertere Betrachtung des Business Value wichtig, da der Umfang als variabel begriffen wird. Es ist daher wesentlich, eine klare Vorstellung davon zu haben, welche Anforderungen dem Kunden wie wichtig sind. Nur so können die richtigen Entscheidungen getroffen werden, wenn es um die Reihenfolge der Umsetzung geht oder gar um eine Reduktion des Umfangs.
Der Business Value ist somit ein wesentlicher Einflussfaktor bei der Planung von Iterationen. Die Sortierung der Anforderungen bzw. User Stories in einem Product Backlog basiert im Allgemeinen auf dem Business Value. In diesem Fall benötigt der Business Value keine numerische Einheit, da er bereits durch die Reihenfolge der User Stories untereinander festgelegt ist.
Auch in klassischen Projekten kennt man die Idee, die hinter dem Business Value steckt. Dort wird oft mit Priorisierungen gearbeitet. Dann gibt es Prio-1-Themen, die auf jeden Fall umgesetzt werden müssen, Prio-2-Themen, die umgesetzt werden sollten und Prio-3-Themen, auf die ggf. auch verzichtet werden könnte.
Welche Anforderung welchen Business Value hat, sollte der Auftraggeber festlegen. Insbesondere im klassischen Projektumfeld mit typischerweise vielen verschiedenen Stakeholdern ist die Bestimmung des Business Value oft gar nicht so einfach. Im schlimmsten Falle sind auf Seiten des Auftraggebers unterschiedliche Abteilungen oder gar Firmen am Projekt beteiligt, die alle versuchen, ihre eigenen Interessen gegen die der anderen durchzusetzen. Dabei sollte nicht der gewinnen, der „am lautesten schreit“. Besser setzt man ein formales Verfahren ein, um den Business Value für alle nachvollziehbar zu bestimmen. Hierfür kann sich eine gewichtete Entscheidungsmatrix anbieten. Auch hier hilft die Darstellung der Anforderungen als User Story ungemein. Denn ansonsten wird es für den Auftraggeber bzw. Anwender oft schwierig sein, den Business Value festzulegen. Mittels der User Story wird für manche isolierte Anforderung erst klar, in welchem Kontext sie genutzt wird und welchen Business Value sie hat.
In klassischen Projekten wird bei Anforderungen oft noch danach unterschieden, welche davon go-live-kritisch sind. Diese müssen dann natürlich auch einen hohen Business Value haben.