Fri 16 Jun 2006
Agile is all about “delivering business value”. Core to this mantra is prioritising features, getting the highest value stuff in first. But proceed with caution. I was talking to Dan North about this yesterday. It’s not *all* about business value.
Where is the business value in “log in”? It’s not driving revenue or reducing costs. You can’t place any monetary value on it. How about the emotional requirements that will create a buzz amoungst your consumers? Don’t have the compliance guys in the prioritisation workshop and no-one in the business is going to put auditing in their “must haves”. Yet these are show-stoppers.
A couple of thoughts. Firstly, think in terms of doing your prioritisation around themes - Jeff Patton [pdf] has written some great stuff on this. And rather than business value, how about “Stakeholder value”. This will map to key business drivers:
customers - increase revenue
employees - reduce costs
auditors - compliance
By giving each business driver an owner or a persona you can ensure that no one audience can hijack the MoSCoWs.
June 16th, 2006 at 4:46 pm
A “log in” feature does have value. Not having the log in feature has a risk, and therefore a cost, associated with it, so having the feature has a monetary value. Financial institutions have entire Operational Risk departments and systems who calculate those costs.
June 16th, 2006 at 7:40 pm
Great topic! I guess it depends on how you define “business value”. Scrum guides customers in prioritizing non-functional requirements and prerequisites along with the rest of the requirements. I guess that at the end of the day it depends on your relationship with the stakeholders. If they trust you, they will listen to you when you explain why “log in” has to be prioritized.
June 19th, 2006 at 1:59 am
It seems to me that ‘log in’ does have a business value - using stories such as: “As a customer want that certain data and interactions with YourSite are password protected, so that my private data is not available to other customers” or: “As YourSite I’d like to require my customers to log in so that unauthorised users are not able to execute protected functionality” should be able to frame the conversation such that it is easier to see how it drives revenue (more people feel happier using the site), or reduces costs (only the right people can execute actions) …
Things like compliance and auditing, and even emotional requirements are also of great value to ‘the business’ as a whole - if they weren’t, then we wouldn’t want to work on them - but they may not be important to the subsection of business representatives in the room.
I think it’s not a matter of saying that there are things that are important that aren’t captured by “business value”, it’s more that we need to make sure that we are considering the entire business when capturing and prioritizing requirements.
I guess this is the “stakeholder value”, but I wonder whether this is in fact too broad - taking things to an extreme, I could see, for instance, a customer valuing very highly a feature of a banking system that doubled the amount of credit she recieved each time she made a deposit - but the value of doing this for the customer is overridden by the cost of doing this for the bank - thus “stakeholder value” is only valuable when it contributes back to “business value”, although framing the discussion in terms of stakeholders may make these relationships clearer …
June 19th, 2006 at 11:20 pm
The value of a login feature equals the cost of not having it. If there is no login feature, valuable information may be stolen, altered, or erased. If this happens, it costs money.
For example, if ATM machines had no login procedure, banks would loose money. (Worse, so would I, since anyone could empty my account.)
As for the other three goals you mention, I am afraid they are all false goals. (Though quite common.)
Increase Revenue - Sounds good, but I have seen companies chase revenue to near death. A company can have a great revenue, and still be loosing money. For example, the revenue can be high, but if the operating expenses are even higher, the net profit is negative.
More insidious, the potential revenue may be high, but the investment costs kill profitability. (IT consultants chasing big contracts for very large clients are prone to loose money this way, I have noticed.)
Reduce Costs - Not a good thing to focus on. A healthy company needs a good return on investment:
ROI = (Throughput - Operating Expense) / Investment
Chasing costs means focusing on operating expenses. Unfortunately, this can easily have the unintended side effect of reducing Throughput, or even increasing investment.
Cost reduction programs tend to create very local optima, that have a very harmful effect on a business process as a whole.
The classic example is firing secretaries. The company saves money because they do not have to pay the secretary anymore. They also loose money, because now managers (and everyone else the secretary assisted), with much higher wages, have to do the secretarial work. This costs more than the secretary did. It also means the people who now have to do administrivia themselves, cannot spend as much time contributing to throughput as before.
This often adds up to a substantial net loss for the company.
Compliance - Compliance has no value in itself. It can be good (everyone on the team must write unit tests), but it can also be bad (developers may not write unit tests).
Business value can and (, in my opinion,) should, be based on the ROI equation. It is the only thing I have seen that provides a valid definition for business value in all situations. (Unfortunately, the customer does not always know that, but that is a different matter…)
June 20th, 2006 at 11:15 am
Hey Marc,
What Henrik has mentioned above is true that just increasing the revenue or decreasing the costs in themselves do not provide the true business value. In the end the project should be making the money for the company, which can be determined through variety of corporate finance disciplines like NPV, IRR, ROI etc. However, this should be done at the overall project level and not individual feature level.
For individual feature level, you need to work with the drivers that you mentioned in your post for different stakeholders. It is only when there is a problem with relative prioritisation that you try and break down the card’s individual business value - but again that would not be a fair comparison e.g. Is getting SOX compliance better than increasing the revenue by £20 million ? The only one who can answer that is the uber sponsor who has a balanced view of the whole world and not the individual stakeholders.
Finally, prioritisation is a negotiation exercise and like in all negotiations, you have to give some and take some. I can see emotional features getting prioritised this way and its value lies in the complete buy-in that you get from all stakeholders that drive the project.
So all in all, I agree its not all about business value at individual feature level, however if the overall proposition does not stand the rigor of quantification then it should be consigned to junk.
Cheers..
Prashant
June 20th, 2006 at 9:26 pm
I do not see how it can be a good thing to use revenue/cost/compliance as drivers for individual features, when it is not good for stories and entire applications. Could you please give an example of what you mean?
Seems to me that if you are going to improve a process, then it is _always_ the ROI of the entire process that must be optimized.
For example, imagine a health care system. Suppose that some part of the system is optimized for cost reduction, for example by cutting resources for detecting breast cancer at an early stage.
This may cause a cost increase at some other part of the system that is greater than the savings, for example the cost of treating terminal cancer patients.
Even if the savings on breast cancer detection are greater than the cost of treating more cancer patients, the health care system itself is just a subsystem in society. To figure out the real cost, one would also have to factor in the productivity loss because of the extra cancer patients cannot work, and possibly other costs incurred because of that.
Can you really ensure that the local cost reduction is a benefit to the ROI of the system as a whole? If so, how?
Same thing with any system, including, of course, software systems. It is very dangerous to make local optimizations without considering the effect on the whole. Therefore, I have a hard time seeing revenue/cost/compliance working as good drivers at any level.
I believe it is the ROI that should rule. A more interesting question than choosing drivers is, I believe, where the boundaries of the systems are. If we add a new piece of software to boost the ROI of a system, then this may affect interacting systems adversely.
For example, a software system that (somehow) helps a sales organization make more sales, can create a disaster if the back end system providing services or goods cannot keep up. So, where are the system boundaries, and where are the boundaries of responsibility?
June 21st, 2006 at 11:40 am
Henrik,
Using individual drivers does not preclude looking at the bigger picture/overall process of the proposition. In fact, we should use the overall project proposition to work out the drivers and not the other way round.
When Marc and I mention revenue/costs/ compliance as drivers, we have the business applications as our basis (although not stated explicitly). However, if we consider your example of healthcare system, then the drivers would be different i.e. number of early detections, reduction in number of terminal patients etc.
You are talking about ROI of the process. I suggest that even within the process, there may be inefficiencies which can be removed by questioning the need for the feature. And hence, the whole point about associating features with their relative benefits.
Regarding your question on system boundaries, I think the correct approach is to understand the business proposition without bringing the systems into equation. As an organisation, if the motivation is to increase sales, then one has to also work out how the organisation proposes to serve the additional sales. Does it already have spare capacity which it does not presently utilise ? Can the supply chain handle additional units ? etc. Once these questions are answered,the underlying systems should be brought into picture and one can then work out all the features needed within such a system. I dont think the boundaries would exist here because the system would be overarching across the entire process and not just for the sales aspect.
Does that answer the question ?
regards,
Prashant
June 21st, 2006 at 1:35 pm
Interesting thoughts. Certainly ROI is key to understanding the value a project will deliver, but when you first sit down with a customer with the goal of understanding *why* they want to do the project, sticking the formula
ROI = (Throughput - Operating Expense) / Investment
is likely to draw blank faces (certainly with some of the customers I have worked with!) Often customers are very vague around the question “why”. Using the model of cost reduction / increasing revenue / compliance etc is a good way to start thinking about the business drivers. Actually putting some values on these should be a next step.
Not that I wouldn’t welcome suggestions on how you’d kick a workshop off with ROI (or NPV or any other indicator of project value)…
November 28th, 2006 at 11:23 pm
[…] My colleague,Marc, has gone a step further and suggests associating drivers for each stakeholder to achieve the same result. […]