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?



  1. Agile Guide – Conversations Around Definition of “Done” | The Agile Scout *Alpha - October 8, 2010

    […] I specifically like the Surfacing the Current practice section that talks about what your team does now: Currently, Sometimes, Not Doing. – Sometimes understanding where you are now helps you know where you need to go. Sometimes the opposite is true: Knowing what you shouldn’t do. […]

  2. Tool Review – Scrum2Go – iPhone Apps! | The Agile Scout *Alpha - October 13, 2010

    […] metrics? Yep, they have it. Your typical burndown and velocity metrics. Valuable information for your […]

  3. What are the metrics by which you measure your agile development process? - Quora - November 12, 2010

    […] here  Agile Scout, Agile Coach, Speaker, Reporter Measuring Working Software – Article…Insert a dynamic date here  William Pietri I'm going to deny the premise of the […]

  4. Developers and Change – Scare Tactics? | Agile Scout - December 9, 2010

    […] reason could be. Estimation issues? Product Owner input issues? Team member communication issues? Management value issues? Scope issues? Tool issues? Process issues? Design issues? Technical debt issues? Consultant […]

  5. Agile Used in the Government – Veterans Affairs Success? » Agile Scout - September 1, 2012

    […] early features of the system quickly, they faulted the department for not setting measurable goals (Demonstration of product issue?) or common standards of completed work (Sounds like a definition of “done” […]

Leave a Reply