What's the point of highlighting story point "velocity"?

I see story points as an early estimation of relative complexity of a given software development task.

Part of the purpose of using story points instead of "ideal man days" is that the team can avoid getting too bogged down in how long it will actually take to achieve.

Keeping a record of these early estimates is fair enough, but is there really any point in using them as a significant indicator of the team's achievement from iteration to iteration?

What can the team do when they see the story point count is a little low so far in the current iteration?

• Arbitrarily re-prioritise stories?
• Cut corners by compromising on quality?
• Work some extra time without pairing?
• Save time in meetings by not having a say?

Estimates have some usefulness, but it is my assertion that they are counter productive as an indicator of progress mid-iteration.

Keeping the B in "No BDUF"

Avoiding Big Design Up Front to be flexible for changing requirements and making decisions when you have the most information available is a commonly held principle in eXtreme Programming.

Lately I'm finding myself guilty of ignoring the word "Big", and getting stung by having to go back and make adjustments.

No BDUF != 0 DUF

What a difference a name makes

I've started working on an application to allow people to manage their Facebook groups from outside of Facebook, as a hobby project to keep my skills fresh while I am between roles.

This morning as I was writing some tests and expanding the application to the point where it would be ready to start interacting with Facebook, I found myself feeling uneasy about the structure of a Service.

The method needed to know about a few fields that I have already encapsulated elsewhere. I found myself wondering, do I pass in the entire object or should the object actually be responsible for calling the method and passing its member fields as parameters?

After a few minutes of umming and aahing, the penny dropped and I renamed my "Service" class to be a Gateway. The way that the call gets processed should have made it stick out like a flashing neon sign that this is a gateway.

Having an organisation object make calls on the gateway, rather than being passed as a parameter into the gateway seems cleaner, but I expect another aspect of the domain that I have yet to uncover will move the responsibility out of the organisation object. Of course day 1 of the project is probably a bit early on to get concerned about this sort of detail.

This is yet another reason why Martin Fowler's Patterns of Enterprise Application Architecture lives on my table, rather than my bookshelf.