I've been using and studying scrum ever since I heard about it from Linda Rising 12 or so years ago. At it's core Scrum is a pattern language, and it's been evolving as people find better ways of doing things, and the patterns have changed. This post will give a very quick overview of what I've seen change.

A few years (about 6-7, I think) I introduced the term "done/done/done" into agility in order to describe what "done" meant in an agile setting. It is now pretty established the "done" is a HUGE concept in scrum, but at the time we were just figuring it out. My thinking at the time was that a Story was "done" when it was "Done/Done/Done", where the three "dones" meant (coded/verified/validated).

I'd like to rant a little bit on something that I find prevalent in the teams that I coach and in the classes that I teach. When I talk to people about scrum (and agility in general) I invariably hear things like "I'd like my teams to be more efficient," "we're using scrum so that will be more efficient," and of course, "we'll be more efficient with this process and save some money, right?"

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.