WARNING: this entry is in the ‘really quite geeky / technical specialist’ category. It assumes knowledge of an Agile software development framework called Scrum. If that isn’t you then you’ve probably got better things to do with your life. Maybe I need a new blog for things THIS weird?
[ The title of this article has been changed but it needs to be revised further to explain that ‘smallest job first’ is assumed in the examples before ordering of equal size jobs by user-story benefit:cost ratio. 29/4/2014 ]
I was recently introduced to a management fashion for calculating the http://en.wikipedia.org/wiki/Net_present_value of projects. It appears to offer an excellent mechanism for demonstrating the greater value delivered by Agile, if we knew the business value of each requirement.
I started to think about how we might estimate the approximate benefit that would delivered by each user-story and whether, within a Scrum sprint, the order that user-stories were tackled would change the total benefit delivered. In the LinkedIn Agile group I proposed the following thought experiment:
3 user-stories, worth 2, 1 & 1 units of business value and estimated at 20, 10 & 10 story-points respectively. Assuming no dependencies, the same priority and 1 developer, what order do you tackle them in?
“Working in the lab, late one night” these were the results of that experiment.
SprintByValueOrder (only 3 pages, including 2 diagrams)
I would welcome any feedback. Was that obvious? Has it been said before or is it new? Should I develop a mathematical proof and publish in a technical journal? Please don’t make me do a literature. I read REALLY slowly.
On The Outside 