Measuring the state of progress in an agile project

Question

Is there a way to measure the success of an agile project as it relates to a well defined outcome? 

For example, I've pair coded Conway's game of life with 12 people using TDD, and each time it was different, but the goal of implementing a fully working version of the program was the same everytime.

Clearly that's an extreme example, and most projects will not be that small, or well defined in scope, but it's just an attempt to express the concept I'm presenting, and which I'm looking to better understand.

Answer 1

According to James Shore, the author of "The Art of Agile Development" Book, success has three aspects, Organizational, Technical and Personal Success. If it meets all, then it can be considered as success. The following is the excerpt from the book.

Success is usually defined as delivering on time, under budget, and as specified. That's a flawed definition. Many late projects are huge successes for their organizations, and many on-time projects don't deliver any value. Instead, think in terms of organizational, technical, and personal success.

Agile development is no silver bullet, but it is useful. Organizationally, agile delivers value and reduces costs; technically, it highlights excellence and minimal bugs; personally, many find it their preferred way to work.

You can see the more details here: http://jamesshore.com/Agile-Book/why_agile.html

Answer 2

Assuming the well defined outcome is a collection of user stories, measuring success could mean a steady progression of software that satisfies the user stories.

Answer 3

There is really only two measures of success for any project, really:

1. Is the customer happy with the results? This is the most important item.
2. How many project team casualties resulted from the project? The fewer, the better

That's it.

Answer 4

Regardless of velocity or actual user stories completed or anything like that, isn't the true measure of success on an agile project (really, any project) that the user accepted the software? Perhaps if you focus more on illustrating a scenario where your product owner approved some stories, did not approve others, maybe added or changed some along the way, and then reached a point of accepting the project as "done" that might be more illustrative than just saying some equivalent of "it's not done until all the requirements pass testing".