Digressing a little from the central topic -- Yeah, it's actually amazing how hard that message is to get through. And you even see a dichotomy where the HR side of a company will understand that and will go out of it's way to hire experienced people and retain them, but Product/Project Managers will completely discount them to the point of driving experienced people out of a business when the knowledge and experience says "Build it X way or you're in a world of hurt a year from now. I lived that once and I don't want to live it again."

Or, put another way, "Security is not a feature the business needs at this time in this PII-heavy project."

OTOH, if they embraced the agile methodology, they could've said "We do not know how long it will take, it depends on our velocity which we haven't yet established". $72K for a team of 6-10 developing an AAA-level game is just unrealistic.

I really don't like velocity as a metric. It's about as useful as counting lines of code to judge a project's completion.

I don't think I could explain it as well as Dave Thomas says it, so here's a link to his fantastic keynote: https://www.youtube.com/watch?v=a-BOSpxYJ9M

Unfortunately the link is a little longer than I have time to view today, but I will put it on my to-watch list ;-)

As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.

The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.

However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).

In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.

That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).

Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.

I hear you, I've also heard "How can we get our velocity higher?" more times than I can count.

What I don't like about velocity is that it encourages the gamification of the process. Developers start caring more about their velocity than the quality of their code and before long nobody has any clue of the big picture and the project starts going down the drain.

Working in the video game industry, I see the striking difference between playing games and developing games first hand, every day :)