Once upon a time...

User stories are the basis of business analysis in an agile project. A user story is an artifact which captures a small but valuable piece of business functionality which can be implemented and tested independently.

The philosophy behind agile methodologies is basically iterative development with short & fast feedback cycle which is used in improving the solution and accomodating changes (subject to priority) so that the end result is really what the customer wants. Inevitably this creates a unique position of a business analyst as a broker between the customer and the developer. Writing user stories is what this broker spends most of his time doing.

There are numerous ways of writing user stories but the goal is to capture a "role", an "action" and an immediate "goal".

Like:
As a Business Analyst
I would like to write my stories in "As a, I'd like to, so that" format
So that I can capture the role, action and goal easily

Ok, that's not an awfully great example... but the general idea goes thus.


User stories should be

1. Small
2. Independent
3. Testable and most of all
   
4. Valuable to business
   

and of course the next question is why.

This leads us to look at the meaning, purpose & priority of each of the above.

Valuable
The user story should deliver a valuable piece of business functionality. This is important so that the story can be released and used by the real users as soon as it is developed, thus giving the team a faster feedback.

Independent
Independence is a very important characteristic of a user story. When a story is independent, it can be picked up for development anytime during the iteration. It can deliver a valueable business functionality independent of the rest of the feature.

Testable
A story needs to be testable. Which means that the desired functionality that a story aims to deliver should be capable of being demonstrated, for all related business scenarios.

Small
A user story should be as small as possible... possible keeping all the above characteristics in mind. You can choose to split a functionality into shorter stories as long as it remains Valuable, Testable and Independant.

This is the primary job of the broker and what's challenging about it is what I'll be posting hereafter alongwith my version of the solution.