Stories are - stories!

One of the things that we've found most difficult to explain to people new to Agile is the difference between an agile Story and an old-school waterfall specification.

If for example, you have a story for some website that goes like this:

Users can log in

and a line in a detailed old-fashioned specification document that reads:

1.2.2.3 Users can log in

How are the two different?

It seems very difficult to say that they are different when they essentially say the same thing, they have the same content. The difference between a story and a specification isn't necessarily in the content. Rather it is in the way that the story and the specification are used. As Henrik Kniberg says in his fabulous book Scrum and XP from the Trenches, stories are an ongoing negotiation between priority, effort and scope. Huh? Is that supposed to make things clearer? OK, we should deal with this in an Agile manner - a little bit at a time. Lets start with priority.


The "1.2.2.3" tacked onto the beginning of the specification is to indicate that this particular bit of specification is buried deep inside some multi-level numbered document and there, in a traditional waterfall development model, it will stay. In contrast, each Agile story gets some kind of priority rating either at the initial meeting where stories are extracted, or at the meeting where what goes into an iteration is decided. This prioritisation has be to done in consultation with the customer. As a result this story doesn't stay fixed like the waterfall specification but it moves around - it either becomes one of the stories that is likely to be implement in an iteration, or one that is left until later.

Now lets deal with effort. Each story is given an estimate of some unit of time that it will take to complete, preferably by the person who will be responsible for implementing that story.

Finally there's scope - just what does:

Users can log in

include and imply? What isn't needed? Again, in conjunction with the customer, the team need to work this out. Maybe some of this needs to be noted on the story card.

OK, so now we've got an idea of what priority, effort and scope are - how is a story a negotiation between all these things? Well, imagine we're sitting in a meeting with a client trying to decide the next iteration and we've got this story in front of us:

Users can log in
Priority: 100
Effort: 10 days

And the customer (who's normally very reasonable) says "What? How the hell can it take that long?" One of your developers explains that - although you haven't written this on the story card - you imagined that this would also need a form to register users and a bunch of work to create a database of users. So the scope for this story would look like this:
Scope: login page, user registration page, set up of user database

The customer is shaking is head - "No, no, no, right now we don't need to be able to register anyone new - we've got an already existing user database - all you need is a form with a username and password and we absolutely have to have it in this release."

So the team look around at the priorities on some of the other stories and then do a bit of scribbling and the story comes out like this:
Priority: 150
Effort: 3 days
Scope: login page, integrate with existing user database