Tildele en forretningsverdi til hvert krav er et sentralt begrep i smidige metoder som Scrum. De relative virksomheten verdier gi en første prioritering av kravene. Ideen er å prøve og levere så mye forretningsverdi snarest possible.For prosjekter med mindre enn hundre, bruker-story store krav dette kan fungere godt.
I motsetning til prosjekter med flere hundre slike krav, der en betydelig andel må iverksettes for sluttresultatet å være til nytte, tilbringe tid verdsette individuelle behov blir over-kill.
I slike tilfeller er det bedre å jobbe med sett av funksjoner knyttet av virksomhet eller brukeraktivitet, prioritering like mye av risiko og avhengighet, FDD-stil.
Men forretningsverdi kan fortsatt brukes for å avgjøre om en sett av funksjoner inngår i minstelevedyktig produkt (MVP), er verdt prisen for å utvikle, eller vil koste mer å utvikle og bruke enn de noen gang vil produsere i profitt.
Det gjør absolutt ingen mening å selv kaste bort tid på å snakke med et utviklingsteam om et sett med funksjoner hvis disse funksjonene ikke vil øke inntektene, øke produktiviteten, eller redusere kostnadene med et rimelig beløp. Det eneste unntaket er funksjoner for å møte myndighetskrav, men disse er vanligvis godt og virkelig del av mvp.
utelate kravene i liten eller ingen verdi virker som sunn fornuft, men interessenter ofte føler seg presset til å insistere på kravene av tvilsom verdi .
Det er trykket av eksisterende forretningspraksis, den "måten vi gjør det i dag", eller "hva vi har gjort i år". Deretter er det bekymring for ikke å ville la ut noe viktig, slik at de kan ikke lastes for mangler det når brukere klager senere. Selvfølgelig, personlige kjepphester og et behov for å beskytte egen karriere interesser kan også legge til press for å insistere på inkludering av tvilsomme krav, og inkludere dem "i den første utgivelsen! '.
Undersøke forretningsverdien av et slikt sett av funksjoner gir objektiv ammunisjon til å slå tilbake mot det emosjonelle presset til å inkludere dem tidlig eller i det hele tatt.
Estimering forretningsverdien av et sett med funksjoner er rett fram i noen tilfeller men i mange situasjoner er det ikke, og en halv bok kunne bli skrevet om emnet som Mike Cohn har i Agile Planlegging og estimering. Det er ikke nok til å vurdere den frekvens med hvilken et sett av funksjoner vil bli brukt. En sjelden brukt funksjon kan levere relativt enorm verdi hver gang det brukes.
I motsetning til dette, kan