So, since we are astute enough so that we're not expecting a story’s size (In Story Points) to be an accurate reflection of the effort it takes for the story – even though we expect a correlation on average – what is our expectation of what a story’s size reflects?

One of the questions that we get all the time is “why can’t you estimate better?” This is a good question, but it's actually a trick question – and not the right question. What the questioner really wants to know is "why didn't your actual effort match your estimate?" Now, this is a very good question, and it has a very good answer.

Agile development is all about delivering value early and often, in order to get and incorporate feedback as soon as possible. Many of the organizations I coach are convinced that it will take months before they can write any code that produces value. Is this a reasonable fear? How do we get past this fear?

When we drive development with stories, we need the stories we're actually working on to have numerical estimates of size; we use these numbers to calculate a velocity, which is an approximation to our capacity. By having a capacity we can have some confidence in our budgeting and predictions.

Fine.

When XPers started using 'user stories' to drive development, they were very simple things: one or two sentences on a 3x5 card, possibly with some testing ideas on the back. Very nice... and they work well for small, cohesive, independent, highly-skilled, empowered teams.

There is a big hoohah going on right now about who "invented" agility. I think that the idea that somebody invented agility is nonsense, and I'll tell you why... but let's start at the beginning.

First of all, what is agility according to us agilistas? Well, it is just the notion of adapting to reality, inspect and adapt, replanning when we have to, etc.