[ars_nihili]

  > Or how about the ScrumMaster that empirically determines
  > current velocity and then tells the team how many stories
  > they can do for the upcoming sprint?

Honest question: how should a team manage what will be done in the next sprint without basing on its velocity?

edit: formatting

[DanielBMarkham]

This also applies to the T-Hawk's question.

Velocity is the empirically-measured percentage of backlog complexity that the team can reliably deliver. It is determined (and varies over time) as the problem gets solved.

It's a measurement, not a control factor. The team has control, not some number. Look at it this way: each sprint when you look at the work, you keep getting better and better at executing: your unit tests are dialed in, the CI server is rocking, you figured out that cool thing where you cut the amount of code in half, and so on. So when you look at what you can honestly do in the next sprint, that's an important piece of business feedback that other people need. You're "recalibrating" the release plan, which you should always do because stuff changes. In Agile, when you pick what you can do at the beginning, the whole schedule slides around. Business guys know at the front of the sprint that things are out of whack. That's great. It gives them the entire sprint to figure out what to do. In other systems they don't know until the end, which sucks for everybody.

Doing it backwards provides absolutely no new information to the business. You're saying the problem hasn't changed, the team hasn't gotten any better or worse, and there are no new risks. Instead of adding your expertise to people who are looking at the big picture, all you're doing is playing some kind of game.

Combine this with other bad stuff like never re-estimating or re-stating the backlog (or having a 3,000-item backlog) and it's like taking a sports car and putting a lawn-mower engine in it. Yes, you can call it Agile, but you're really doing it in a very painful and inefficient way. That hurts. Don't do that.

[ljw1001]

I think Mike Cohn has been _real clear_ on the subject and he says story points are NOT a measure of complexity, they're a measure of effort, which he (and I) connect directly with time.

If points are not a measure of complexity than velocity can't be a measure of complexity either, since it's just points/time.

I don't always agree with Mike, obviously, but I think he's about as knowledgeable on agile scheduling as anybody out there.

[DanielBMarkham]

You know, as soon as I typed "complexity" I knew we'd end up here.

I believe we're deep into semantics. The fact is, whether you call it complexity, effort-till-delivery, or chopped liver, the process is still the same. And it still works.

And while I like story points, frankly I could give a rat's ass with Cohn has to say about it. He's a nice guy, and he's obviously an expert, but I'm much more interested in what works than in anything else. Story points work because we pick them up and use them for stuff, not because Cohn calls them one thing or another or recommends doing them a certain way. Remember the point here is that the predictive modeling process the team uses evolves and becomes more accurate over time. It's really nowhere near as important where you start as that you keep getting better. I've started teams using a 2-tier H/M/L process for assigning points and it works fine. No matter how they think about it, the team gets better over time and it ends up giving them powerful predictive capabilities. That's the key item here. You're getting wrapped up in the weeds.

Sorry, but when I talk about insufferable Agile people, the number one annoying thing they do is name drop. Really bugs me. People drop some famous author's name and then all rational thought shuts down. The great one has spoken.

I'm very sorry you seem to not be getting the answer you wanted. Like I said, I feel your pain.