Determining Value in Agile

The Problem
One of the central tenets of Agile is that "value" should be delivered as soon as possible.  That sounds great on paper, but how can one value software code?


For functional user stories, this can be easy.  If you believe that some sort of enhancement will allow you to increase the profitability of your product, the value calculation is straight-forward: the "value" of the enhancement is the increased profitability.  But, it can also be hard: a new report might give you a new insight on a new (more profitable) way to operate...but you won't really know until you see the data in the new report.  In this case, the user story has the potential for increasing value but you won't really be able to put an accurate figure on it until the deed is done.


For non-functional user stories, the question of "value" starts to become impossible to determine.  An example of a non-functional story might be enhancing your logging architecture to be able to better troubleshoot problems.  (Of course, you're writing perfect software with no problems in the first place, so this is a silly example...but humour me please!) 


You would only pursue this a story if the current logging architecture makes it difficult to troubleshoot problems.  But how much does the "difficulty" cost?  And if you're writing this software for customers you don't yet have, how much does it cost?  This user story falls into what I would call "avoiding the loss of value"...it's defensive in nature.  Scalability, performance, operability...all of these (and many more) are important non-functional capabilities and attributes of good software, but how do they get built if you can't gauge their value?


I suspect this is a problem that a lot of Agile ISVs (Independent Software Vendors, or people who write and sell software for use outside of their own company) must struggle with.  The most vocal stakeholders (the sales team and sales-oriented product managers) demand functional enhancements: they're the sexy bits that sell software.  But there are a whole bunch of stakeholders on the operations and support side who aren't as vocal...and these are the folks who would derive great value on stories that avoided the loss of value.


One Idea
So, an idea I've had floating about in my head is this...what if the stakeholders in your product had to put their money where their mouth is?  I think the executives of ISVs (at least those that I would want as an employer) "get" the importance of non-functional capabilities.  Customers need a good ownership experience, but this is made difficult if they're always "losing value" because of poor quality, poor performance, or difficulty in its operation.

I might be so bold as to suggest that they could probably give a pretty decent guess as to how much they would like to have invested in functional versus non-functional enhancements.

So, let's assume that I give the executive team 1,000,000 gold dubloons.  (Avast!  Thar be maths a'comin'!), and let's say in the next release they want to see invest 70% of these invested in functional enhancements and 30% in non-functional enhancements.

The game is this...and this is really just a brain dump so it might not read that well:

• Stakeholders (who represent the Agile customer interests) have authored Stories (which include both enhancements and defects).  It is possible to be a Stakeholder without having authored a story, more on that later.
• Each Story must be well-articulated in the sense that it outlines what the story should do to be considered "complete", and is well-groomed in the sense that the story can be earned (written, accepted, and tested) within a single iteration.  
• Each Story also has a "value pitch" which outlines how the story adds (or avoids the loss of) value, using qualitative and/or quantitative language.
• It is up to the product management team to ensure these stories are "good".
• All good stories are placed on the product backlog...REGARDLESS of what the product managers believe the value of these stories to be.  
• Assuming total executive dubloon allocation is D, the total number of Stories on the backlog (up for consideration) is N, and the total number of Stakeholders is S.  
• Each story author is automatically entitled to allocate 20% x D / N dubloons.  
• Story owners are therefore automatically Stakeholders.
• This leaves 80% x D dubloons to spread across all Stakeholders.
• One does not need to be a story owner to be a Stakeholder.  Anybody with dubloons is considered a Stakeholder.
• Because the executives desired a 70/30 split between functional and non-functional value-add, the remaining 80% of dubloons are allocated along these lines.  The primary functional product manager is therefore given 56% x D dubloons, and the primary non-functional product manager is given 24% x D dubloons.
• Any individual Stakeholder can hold at most 2 x D / S dubloons.
• The product managers who have been given such a generous pile of dubloons will therefore need to seek out others who they feel can represent their respective interests.  These could be other product managers, architects, sales team members, support team members...whoever they think would be able to make a value determination.
• As more Stakeholders are added, the quantity 2 x D / S decreases, meaning that some stakeholders may need to give up some dubloons.
• Next, Stakeholders allocate dubloons to the stories on the backlog.
• Stakeholders should be independent; there should be no coercion or lobbying for one story over another.  The "value pitch" is the story authors sole means of trying to attract dubloons.
• A Stakeholder can allocate their dubloons however they want.  They could put all their dubloons onto a single story, indicating that they believe ALL of the value of the backlog is embodied in this single story.  
• A Stakeholder can "spend" the dubloons in their hand, but no more.  They must spend all their dubloons or give them to another person (who might suddenly find themselves as a stakeholder).
• Upon completion of a Story, the development and test teams get to keep all of the dubloons allocated to the story.  
• They will therefore be highly motivated to complete the stories that have attracted the most dubloons, and will not be highly motivated to complete the stories with very few dubloons.
• There should be some sort of real-life compensation for holding a dubloon.  Maybe this is money, some sort of time-in-lieu, gift certificate, stock...something.  This is to give the development and test teams a real incentive to complete stories.  There ends up being a real-world budget for this effort...maybe it's $0.01 per dubloon ($10k for the release)...it doesn't need to be much.  Perhaps it is some number of dollars per developer+tester.
• The ratio of dubloons between developers and testers should vary by completed story.  Basically, developers should be incented to get it right the first time...if they do they get a disproportionate fraction of the dubloons (maybe 120% of what they would if it were divided evenly).  BUT, if testers reject a story because of a legitimate problem, the balance shifts...maybe the first retest developers get 100% of an even division, and if there is a second retest it falls to 70%.  Basically, this is to incent the testers to find problems.  
• The stakes here aren't huge, and the development manager would be the person to police abuse of the system.

So...what does this complex game achieve?  Quite a few things actually...

1. The executives "created" dubloons because they wanted to unlock additional value in the product.
2. They had an idea about the sort of value they wanted to see added...70% functional and 30% non-functional.  They were able to achieve this by giving 80% of the dubloons to the two individuals who represented functional and non-functional interests.
3. Story authors (who are the proxy for customers) get a say too...they have 20% of the dubloons to allocate as they see fit.
4. Because of the "wealth cap" a wider set of individual value judgements are made.  Basically, this "crowd-sources" value determination of stories.
5. Priority rankings now become completely trivial: development will now do whatever they can to earn as many dubloons as possible.  Because dubloons are a proxy for value...value is delivered as quickly as possible.

So...am I nuts?  What other ways are there to solve this problem?