Agile projects prioritize requirements based on business value. There may seem like no business value in the non-functional requirements of Compatibility, Usability, or Reliability, but if the systems fails to deliver one or more of these “~ilities” then the system is a dead-duck delivering no business value whatsoever. (We may design and build the highest specification car on the planet, but if it only runs on unicorn sweat, needs three hands to drive it, or manages only 5 seconds between break-downs it is not useful.)
So, given that we do need to prioritize non-functional development alongside functional requirements, what mechanism do we use? One approach that business folks understand uses money as the prime driver. A fancy descriptor for the technique might be “Feature prioritization based on balancing predicted ROI against expected monetary value of risk mitigation” but let’s just call it “Smart Planning” for simplicity.
On all projects we have to balance delivering features along with doing all the important behind-the-scenes stuff. Leaving non-functional development until very late in the project has two major problems:
- It costs more then. If you would have done it earlier it would have been easier, taken less time and left more capacity (time and budget) for business value adding features. This represents poor customer service as in the end less functionality gets delivered for the dollars and time available.
- It creates project risks that can lead to project problems. By avoiding risk reduction work (such as proving some architectural component) in an early iteration because it did not have a high business priority, the project is exposed to risks that could delay or jeopardize the endeavour. This also represents poor customer service.
The responsible thing to do is to explain to the customer the reason why these seemingly less important work items need to be done sooner rather than later in a way that they understand. Once you do this it becomes obvious to everyone that the smart thing to do is the next set of remaining prioritized functional and non-functional requirements that iteration.
Some project teams attempt to hide non-functional development work in slack time, refactoring time or under a banner of architecture. This is a cop-out that does not serve the business well as it creates doubt around team estimates and productivity. It is better to have a transparent process that prioritized functional and non-functional work under and single queuing process.
Most teams are comfortable with ranking functional requirements (stories, features, use-cases) by business value. This is often subjective, based on a proxy user’s gut feeling or preference, but if we want to get more scientific about it we can focus on the Return On Investment (ROI) per feature. Presumably, for the project to get approved, someone did a cost benefit analysis to justify that our, say, $2M project would generate (or save) $4M over 3 years. For regulatory compliance or maintenance projects we can still come up with a dollar figure, just brainstorm with the business the economic penalties for non-compliance (fines, lost business, etc).
Once we have a ROI figure for a project the business (not the development team) should distribute or pro-rate this across the identified features. Often, the business pushes back at this idea. “I can’t put a dollar value on a sales report, that would be too subjective or misleading”. Well excuse me, but someone came up with a projected payback for this project and if we cannot divide it across the systems features then where does this money come from, the documentation?
So having, probably somewhat arbitrarily, attributed a dollar value to the system features we end up with a prioritized feature list with ROI values.
What we now need is some way of monetizing all the non-functional requirements also. A recognized way of doing this is to consider the risks associated with the non-functional items. For example, if we were concerned about the performance of the in-house reporting tool and wanted to try (spike) some development to test performance we could examine the Expected Value of this risk. Assuming the in-house reporting tool has a $0 cost to the project and buying a high performance reporting engine costs $10,000. If we think there is a 50% chance of needing this tool then:
Risk Expected Monetary Value = Risk Impact (in dollars) X Risk Probability (as a percentage)
In our case $10,000 X 50% = $5,000. Now we can say to the project sponsors that we believe the economic value to the organization of mitigating this risk is $5,000 and so its priority for development scheduling should be on a par with functional features valued at $5,000.
This can be done for most risks. Technical risks usually have a purchase cost (as the reporting engine) or time penalty (it will take two developers another three weeks) which can be translated into a dollar amount. HR and business risks can likewise be estimated in monetary terms. We may think some things can not have a value put on them, but insurance assessors spend their days determining the value of a lost finger or emotional distress for clients and the same techniques apply. It is important to remember that we are looking for relative scorings rather than precise numbers. The initial ROI figure was undoubtedly a crap-shoot anyway, so let’s not get hung up on the accuracy of the risk values. We want general, justifiable numbers that have consensus from the project stakeholders to use as a basis for prioritization, not a balance sheet.
Using this approach, we can rank the project risks to produce a prioritized risk list ordered by risk severity.
Of course not all risks have avoidance or mitigation steps we want to schedule into the project. Some risks may have to be accepted (we are waiting for service pack 2) or transferred (we have taken out insurance) but for the steps that can be proactively tackled, these steps can now be prioritized alongside functional features.
As shown above, attributing a dollar figure to both functional and non-functional requirements allows for a more meaningful discussion with the sponsors/users. We can see that the second risk from the top has an Expected Monetary Value of $8000 X 50% = $4000 so when it comes to selecting requirements (features) for an upcoming iteration, the risk mitigation action associated with risk 2 ranks similar to the functional requirement number 2. In other words, doing this seemingly non-business value adding work, makes sense because if is of equal value to the organization.
Figures Lie and Liars Figure
A guess multiplied by a guess is unlikely to be very accurate. The purpose of this exercise is to facilitate better discussions with the business as to how to best sequence work items. If people start rigging the numbers to serve their personal agendas then the purpose and true power of Smart Planning has been lost. Technical dependencies and sponsor mandates will take precedence over sequences derived from this approach. However, the true benefits arise when the business and development team find a way to bridge a significant communications gap and engage in meaningful schedule trade off discussions. So although we use numerical techniques to level the playing field it is really more a qualitative rather than quantitative method.
"...the true benefits arise when the business and development team find a way to bridge a significant communications gap and engage in meaningful schedule trade off discussions."
So next time you are faced with trying to explain why it is important to incorporate some non-functional requirement instead of the next feature try assessing its expected monetary value and comparing it to a features likely value.
(If you get pushback from awkward users that they don’t care about maintenance costs because it is not their budget, remind them that the risk costs are in today’s dollars and yet the current value of a $4M payback in 3 years is a lot less than their pro-rated amounts. Also with all the new features they have been asking for recently, that $4M is now spread a lot thinner, so in fact you are doing them a favour by allowing these remaining features in the iteration! Oh wait, now we are being quantitative again.)