One of the principles of agile is that you should measure working software:

Working software is the primary measure of progress - 12 principles of Agile

The thing is, while I can measure my software in terms of stories done, bugs squashed or the volume of defect reports decreasing, I'm stuck on how to measure the value of my software.

If I use Mike Cohn as an example and his helping SalesForce.com deliver 500% more value to it's customers compared to the previous year* - how do I measure that increase? How do I measure where I am right now?

Other metrics he uses are the number of features and the number of features per developer. This is something I could work out if my backlog was in good order and the stories were cut up by 'feature', but we're just starting out with Agile, so I need some way of working out what the value is we deliver now, then use a similar metric in say, six months, to see if we've increased our output.

I've heard about measuring value of software by an uptick in revenue, or an increase in customer satisfaction (how would you measure that though?) but those increases could be attributed to anything in the company (sales, accounting, support) and not directly to the work my department is doing.

So, how do you guys measure the value of your software and how did you start?

* Succeeding With Agile - Mike Cohn

  • 4
    500%? How did he measure that? Jan 17, 2011 at 14:59
  • To quote from the introduction of Succeeding with Agile: "Salesforce.com released 94% more features, delivered 30% more features per developer and delivered over 500% more value to its customers compared to the previous year (Greene and Fry 2008)." So, he didn't say it specifically, it's figures reported by someone else.
    – Mike
    Jan 18, 2011 at 10:33

6 Answers 6


Here is how I define value in general (even outside software development)

You define what value is.

If the value is the amount of money earned/saved thanks to the software, the value will be:

Revenue - Cost of development = Value


Saved Operational Costs - Cost of development = Value

It can be turn over. Do you know what cost the turnover in your company? If you can measure it, 50% reduction of your turnover thanks to agile will allow you to calculate value it provided:

50% Turnover reduction = (Turnover Cost / 2) = Value

Value can anything that matters to you, the guy that define what is the value.

That's why value is evaluated in points in agile. Points are compared to story points to help you prioritize value. Because you must compare (business) value (arbitrary) with story points value (cost).


In many cases, the value of software is measured by calculating "added earnings" or "achieved cost savings".

In other cases, where the software is integrated part of a larger system (i.e. the software that controls a car), it's more difficult. Either you measure the spending to make it (value=cost), or you calculate the value of the whole system (added earnings/archieved cost savings) and allocate a part of if to the software (e.g. proportional to the costs of the software vs. total costs)


Simply put you have to work out what the financial difference between having it and not having it is.

If a bit of software automates a process that means that two people who work full time don't have to do that task any more, that's a saving of their annual salaries (plus related costs) to the company. If salesmen on average sell 10% more than those not using the new system, the benefit is 10% of the total sales for all salesmen who might use the software.

The figures may only be rough and ready but most things can be quantified enough to give you some sort of useful impression of what to expect.


This is a tricky question. I'm not sure I like the "features / developer" metric, because not all features are created equal. Some features are "Must-have" and will steal clients away from your competitor. Some features are obscure and may be used by 0.1 % of your clients, and they might be able to do fine without it as well.

Upticks in revenue is good if you can easily correlate it to a sudden influx of sales / renewals of the software to the timing of a new release. Also if you were somehow able to track conversion of users from competeing products to a new release. Customer satisfaction could be measured in terms of number of happy calls (or lack of angry calls) normalized to number of customers or sales. To directly relate these to your department, the key thing might be timing of these changes and the timing of the software you're releasing.


Working software is the measure. Listen openly to your users and involve them in the development process. Regularly deliver the functionality that they tell you is needed when they need it. Deliver in small chunks so users feel progress.

If you are just starting agile development or even a new project...then stakeholders need to have a bit of faith. This requires the product owner to articulate why agile is better than other processes (I assume that you think it is in your specific situation).

If the product owner is not sure which features (stories) offer the most relative value then you need to sit down with stakeholders and figure it out. Planning poker is a good tool for that. Assigning Relative Business Value to each story also helps with prioritization but be careful not to talk to bean counters about "Agile Business Value" it's not the same as ROI!


There's often a 'hard' bottom-line that can be measured easily to keep bean counters happy, "Feature X increased our revenue by 150%". But more often than not it's a combination of 'hard' and 'soft' values "Our revenue increased by 160% and we think we can attribute that to the software change as customers on average gave us 11% higher ratings with the new UI feature".

It's really hard to measure these things accurately - try to look at it as holistically as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.