The Art of Writing User Stories

User stories are the currency with which Product Managers communicate and sell the business idea they are advocating for.  They are one of the most important artifacts (other than the Product Roadmap) that a Product Manager creates.  Here's some suggestions for crafting user stories:

1. Follow the basic format
The basic format of a user story is:

• As a {type of user}
• I want to {goal}
• So that I can {reason}

User stories help to answer three questions:

• Who is this funcationality for?
• What should we create?
• Why is it valuable to the user?

Too often, I read user stories that don't include a good reason.  Think about it - for your last 5 user stories, did you have a good reason for why this was important?  This is critical because it helps your development team understand why they are building this.

2. Include your acceptance criteria
Acceptance criteria are hard to define.  I set the expectation that I can complete 80-90% of the acceptance criteria without the help of my developers, and I expect my development teams to help craft the last 10-20%.  This allows room to add AC to accommodate for any technical issues or existing architecture challenges.  Some people follow a formal format; I tend to fill them out ad-hoc.  
You can try this format:

• Given {context} and {more context}
• when {event}
• then {outcome} and {another outcome}

3. A few best practices
A common problem among agile teams is that user stories are too big, which makes them hard to understand, estimate and implement.  Keep the stories small so they can be incrementally released.  A good rule of thumb is for user stories at the top of the product backlog to be sized such that the team could complete 4-6 stories a week.

To help you achieve success...

• define the what not that how
• use understandable language
• group user stories by themes 
• don't be the bottleneck on your team; have a healthy backlog of user stories

A bit more about acceptance criteria

• typically written at the same time as a user story
• vary in number
• tests if the functionality meets the expectations before release
• includes both what the feature should do and the error states (most PM's forget this!)
• should include design, and possible reference wireframes

How are you at writing user stories? Do you follow a different format? What advice do you have for other Product Managers?