What's Your Story? User Stories Instead of Technical Documentation

Oh, technical requirements documentation. So fun to read and so fun to write! All kidding aside, it seems to be a necessary evil. Otherwise, how do you know what to build?

Well, what if I told you that there is an alternate option? Interested? Good, then let’s talk about User Stories!

What is a User Story?

How is a user story different from a typical technical requirement?

• User stories are in everyday language
• User stories are short (1-2 sentences)
• User stories should be written by the customers who will use the product
• User stories provide a quick way to handle requirements without a big, giant, annotated document that is difficult to read
• User stories reflect exactly what the name implies — they tell stories about users using the product

Who are the User Stories for?

Basically, the whole team building the product:

1. Developers, information architects, project managers, the whole bunch.

Write: You can all work together to write some concise user stories for your product.

Verify: When the developer accepts the user story, it’s considered final.

Refer: You’ll need to keep track of the user stories so you can refer to them later. As you’re building the product, you will inevitably encounter new developments (e.g., Surprise! That module doesn’t work the way you expected it to!) that require you to remember the original user story and figure out a new plan of action. The great thing about user scenarios is that they capture the goals of the user, not the actions. So, as long as your solution achieves the goal, you’re good to go and major revisions are not needed.

2. Customer representative/client

Ideally, the developer can meet directly with a customer, but that’s not always a possibility. It is also possible to meet with someone who can represent the customer’s work.

Write: The “build team” and the customer will write the user scenarios together. More on this in the “How to” section.

3. Future staff

Refer: When new people are brought onto the project, the user stories are a good place for them to start - it will help them understand the product and the basis for its creation.

How do I create User Stories?

Supplies

• Index cards
• Sharpies

People

• Build team (facilitator)
• Customer representative / client (participant) 

Activity

As a member of the “build team,” you will walk the customer representative through this activity.

1. Segment the product
   This will help you tackle the product, one piece at a time. For example, if the product is a website, consider segmenting by section on the website or types of content. Pick a segment to start with.
2. As a [role/audience], I want [feature] so that [reason].
   The customer representative should complete this sentence on an index card for each story.
3. Assist and discuss
   The “build team” should probe the customer representative with questions to better understand the user story and ensure that is is concise.
4. Post it on the wall
   You need to get out of you chair and stretch a little.
5. Prioritize
   This will help the “build team” understand what is most important. You will likely have a wall-full of index cards. Group and prioritize them on the wall for all to see. (Example: group the index cards in an Affinity Diagram).

Example Stories

• As a researcher, I want to download documents so that I can complete my research.
• As a teacher, I want to filter the list of lesson plans by grade level so that I can find ones appropriate for my students.
• As a journalist, I want to get the RSS feed so that I can keep up with the news and get story ideas.

Helpful Hints

• Make your stories testable.
• Keep your stories short.
• Stay focused on the user/customer.

More resources

Check these out for more details and examples:

Agile Modeling: Introduction to User Stories

Sticky Minds: Write a Blockbuster Using User Scenarios

Codesqueeze: The Easy Way to Writing Good User Stories