I have already post about problems to be focus on project documentation (specifically functional specifications).

The problems I see with heavy documentation are:

• It’s expensive, out of date, complex in planning, hard to create
• Real-time feedback is disable, discourage open collaboration and innovation
• It’s really easy to misinterpret what someone wrote
• The solutions are build according to specifications instead of what customer’s needs
• They make bad assumptions/guessing as specification are made on paper not working prototypes
• They waste a lot of time

Agile principle: the most efficient and effective method of gathering information is face to face conversation.

User stories: Agile user stories are short descriptions of features our customer would like to one day see in their software. They are usually written on small index cards (to remind us not to try to write everything down).

These are the element of good user stories:

• A good user story is something of value to our customers
• User stories goes to end to end (gathering them by feature, enables us to treat them independent and flexible)
• User stories make sense to business
• User stories must be testable
• They stay away from the technical jargon (use the language of the customer)
• User stories are small (1 to 5 days to be delivered)

To give context to the user stories, it may help to use the following template:

• Start with goal stories
• Size the story for the time frame it would be implemented
• Keep User Interface (UI) out as long as possible
• Write for a single user (a job seeker instead of job seekers)
• Don’t number the story cards
• For each release the customer prioritise stories (remember 1 to 2 weeks max of development)

The story gathering work-shop: before we can create our agile project plan, we need a list of all the features our customers think they would like to see in their solution. This get together must be done with the customer and development team. Here are some useful tips:

• Get a big open room (good table, light, white boards, walls to use post-its…)
• Remember, be careful of not diving to deep on the details you want to keep it high level
• Write lots of stories (at the end of the day, 10 to 40 high level stories are good enough for 3 to 6 months of planning)
• Once you have your initial list done, it’s good to go through it again looking for duplicates, things you have missed, and grouping logical stories together.

I have written at the beginning of 2010 a good post The use of User Stories, I invite you to check it out to complement this technique.

Also I share here a video done by The Agile Academy:

Read the full series of articles about Agile Methodology: The Basics, Who and Why, How to Deliver, User Stories, Estimation and Planning.

Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf