Number of Acceptance Test Cases: a meaningful measurement in sw project mgt

Some one had asked me, besides count in g line of code, how to decide the complexity and working load of a feature. and how to understand where we are in a project
And still some one asked us another question, how can we keep tracking "tasks" in a flow composed of "analysis/design", "coding", "testing", that is if they all have a todo list, or queue, what's should put in the list.

I really took some serious thinking on it and talked about it.
Now I guess Acceptance Test Cases would be a good answer to  them both
Compare 3 measurement, LOC, story points and number of acceptance test cases.

1, Line of code

It's a mis-leading measurement, as it implicitly suggest that the feature is "done" after codingEven if we can estimate how much work left behind, e.g. testing, based on the LOC, the most risk part is the quality in terms of number of bugs to coms in testing

Well the most concern I have is it has some distance from our real intention, to meet the customer's requirement

2. Story Point

I am not sure, the idea is difficult to me, it's an integer, but I don't know what "1" mean.
It's failed cause it not conceret and can not collected "automatically", and can be easy for cheating

3. Number of acceptance test cases

It's meaningful

Think of the question "how can we tell our feature meets the requirement from the customer", it's acceptance test cases, normally end-to-end

Acceptance Test Cases is direct and close to our real goal, satisfy our customer's requiement

Number of AT cases passed tells where we are in a project in terms of how many requriements are met

It also suggested how complicated a feature is, complicated feature sure has more test cases, or else what is the meaning of complexity

It's concrete

number of acceptance test can collected without human interpretion

It leads to an easy collaboration among teams for it's an end-to-end goal

I once worked in sustaining for a long time and I noticed that it's easy to collaborate with other teams for bug fix, different component design teams, testing teams  works well together, For they share a same goal.

In feature development, as different team has different goal, it's really hard to co-work, a lot of  meeting s, d isc ussions, calling for actions, reprioritize ...

It suggested quality besides quantities

It's meaningful to the whole flow of "design/coding/testing" and overall mgt

To SD, system design, 

acceptance test cases are their meaningful and concrete  output

What they are doing now, translating protocol and customer requirement is a foggy task, and makes this crutial knowledge 2nd handed to design team.

To design, 

Besides of ease of collebrating and sync. It avoid over design.

To project mgt

It's a direct and close to our goal, meets the customer requirement and it's explicite, conrete and meaningful measurement

BTW. it also answers another question, how can we drive and teach team to write end-to-end story which to me is an approach instead of goal, writing end-to-end acceptance test cases, and make a test case a story will do.