PO is a Person and a Role There has been a lot of talk lately about the Product Owner and people are getting quite heated about it. Here's my take on it.

Imagine our Product Owner says: "I want this feature by tomorrow and I don't care if you've got to hack it in. If we don't deliver it tomorrow, it will cost us millions of dollars!!" What do we do?

Imagine you are at the Sprint Review and the Sales Manager says, "That looks good! I can sell the heck out of that. Ship that puppy!" Now what? What do you need to do to get the system shipped, and how and when will you do it?

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.