A story starts as an idea to improve the functionality or appearance of a product. It doesn't have to be a completely defined idea. It can just be a reminder of an idea that can be brainstormed and defined at a later date. For example, a QA engineer who is adding the same standard tasks to each user story for a sprint from scratch for the umpteenth time thinks "Wouldn't it be great if the sprint management tool automatically added these tasks to all of the stories?" He doesn't want to lose that thought so he writes up a "story" as a promise to have a conversation about it at a later date with the product manager and/or developers of that tool.

The story provides the beginning of the concept - an overall picture of who is involved and the goals they want to achieve. You don't have to have an ending when you first write it. It is an invitation to conversation that says "This is what I want to do, can you help me find a way to do it?" - a fuzzy goal that gets the idea moving but doesn't blind the team to other opportunities.

There are three common variations of the standard format that can be used to write your story statement to keep them short and sweet but each team can, and will, create their own:

• As a [role], I want [feature] because [reason]
• As a [role], I can [feature]
• As a [role], I can [feature] so that [reason]

As a QA engineer, I want a way to automatically add standard test tasks to every story because I waste a lot of time adding the same tasks each sprint.

It isn't important to have a solution at this time. That will come later when the developers pick up the story and start to brainstorm ways to achieve the stated goal of helping people to not waste time adding the same tasks every sprint. By going into too much detail early on, you will box in the developers and maybe prevent them from seeing a better solution or an opportunity to expand on the idea. Maybe this is an issue that applies to more than just the QA engineer. Maybe there are multiple ways to resolve the issue - from the bare minimum all the way to a complete rewrite of a section of code. For now, you have set a fuzzy goal that will be defined in a later conversation.

How does your team handle stories? Who writes your stories and how do they get added to a sprint?

Interested in what I'm reading? Here is a sampling:

• http://www.agileforall.com/2010/05/03/new-to-agile-remember-a-user-story-is-more-than-a-card/
• http://xprogramming.com/articles/expcardconversationconfirmation/
• http://www.amazon.com/Gamestorming-Playbook-Innovators-Rulebreakers-Changemakers/dp/0596804172/ref=sr_1_1?ie=UTF8&s=books&qid=1296680487&sr=1-1