Understanding Agile with Complete Rate

This quote only appears to be an interesting statement, but actually it perfectly explains scoping, which is one of the core skills of project management.

This statement is true because the percentage is generated by comparing what current program does and what requirements the scope defines. A program can be no less than 90% complete in one scope, and no more than 95% complete in another scope. And you can always find these two kinds of scopes for any program you have. Let's see a simple example:

A 92.3% completed "Hello, World"

Let's say you have a program that prints "Hello, World".

  • If your requirement is prints "Hello, World", then this program is 100% complete, more than 90%.
  • But if your requirement is prints "Hello, World!", then it's only ~92.3% complete (12 chars out of 13 chars), less than 95%.

Features and bugs are the same thing

With this program complete rate in mind, we can reduce both features and bugs to this single concept.

It's easy to say that our product is not done when we have undeveloped features left. And we can calculate a complete rate easily.

For bugs, it's not so common to understand them in this way. But I found this understanding to be easier and simpler. According to IEEE 610.12-1990, a bug is "the degree to which a system meets specified requirements or user expectations." In another word, a bug is the complete rate of a program compared to its scope.

Basically, features and bugs are the same thing. So as long as user expectations are not fixed (and they will never be fixed), we will have unlimited number of unfinished features and bugs. We can never have a program that's more than 95% complete.

A 90%-95% development cycle

OK. We've talked about the bad news in this quote. Let's look at the bright side. As long as we keep the complete rate of our program in mind, we can ship 95%-completed programs frequently.

Our job as project managers is a cycle:

  1. First, we need to prioritize the features and scope the project so that we can get a 95%-completed program as quickly as possible.
  2. After we hit the 95% line, we ship it to the user, and ask what the remaining 5% features/bugs are (warning: this 5% may be way larger than the 95% you have now).
  3. Now, knowing what the "5%" remaining features are, we can repeat the step 1: Prioritize! Pick the most urgent features so that our program is 90%-completed again.

This is my current 95%-completed understanding of Agile software development, explained with the complete rate concept. Hope it would help you understand "Agile" 1%-better. And I'm looking forward to your feedback to make my understanding 90%-completed again.