Measuring Working Software – Measuring for Value!

Measuring Working Software Agile Scrum
What is our Measured Value?

This post comes from an issue that often comes up from time to time with development teams, whether explicitly or implicitly. Regardless, it needs to be addressed.

So, at the end of each iteration we’re supposed to demo and retrospect our code, correct?

This implies that we have working software at the end of each iteration, right?

Even if we don’t, how do we measure that the software is ‘working?’ Do we define it through the fact that our critical test paths work and the code is a flawless victory? Or should we look at how we define ‘working?’

Let’s look at a website for example:

  1. Does the dot com work? – Yes of course it does
  2. Do users like it? – Yes, it seems that most find it very useful for their needs
  3. What if we had a spike of tens of thousands of requests at the same time? We may have some application degradation and loading issues. Should we have metrics to incorporate load as a measure of our success?

Maybe you can think of a measurement of success that we’re not looking at currently. Our code may be good, but is our software truly working?

Sometimes it’s easier to look at issues by defining what they are not, first.

Not Good Measures of Working Software:

  1. Meeting specifications. Often the specifications have fatal flaws (we saw this in some of our specs for pricing changes)
  2. Revenue. A market fluctuation affects revenue and is not a true measure of whether the software works (what happens when RH conversion goes up 4% within a week seemingly random)?
  3. User surveys. Users often change their minds about the same piece of software (Our removal of the feedback link).

What would be some ways to measure our success of your software today?


5 Replies to “Measuring Working Software – Measuring for Value!”

Leave a Reply