Third World Agility

When you're telling a story about something that's supposed to happen just once -- or something that happened already, once in your life, someone else's life, or something you saw in a movie -- how do you do it? Do you talk generally, or do you talk in specifics?

The answer could be it depends on who you're talking to. If you're telling a story to a friend, then you'll be telling the relevant parts and even the details that are needed for her to understand the story. If you're telling a stranger about it, then maybe you'll tell them about the really general things -- and maybe even exaggerate or obliviate some aspects of the story. Or maybe when you're telling someone about something that you already told that someone about, then you'll use a reference to your earlier story.

It's true that it really depends on the audience -- but there are undeniable reasons why there are some really important parts of the story that have to be there. There are elements to a story that give it a concreteness, even if the details aren't mentioned literally. There are a few important things that all stories will require:

• Setting. A story should be set in some location or circumstance for things in the story to make sense.
• Timing. A notion of time will make a story more believable -- words like meantime, while, after, and before give you a sense of order so that the sequence of events will make sense (or not make sense).
• Actors. Stories without participants or actors wouldn't make too much sense, since there are no participants to the story. It will be hard to visualize a story, and even construct a sentence (that makes sense) without using nouns or pronouns.
• Action. Stories wihout action can't be stories -- action doesn't necessitate violence, but rather an occurence involving actors. Action that doesn't make sense doesn't make a good story.

These are the same elements that User Stories should contain. Usually the Setting is well defined in the context of the project, and each story should contain a sequence (if it's required), the actors, and the action in short concise 3x5" index card scribblets. The simpler and understandable (and clear) a story is, there's a less chance of confusion -- and it enables the customer to communicate precisely what they require.

If you look at the stories that need to be made reality, usually these are functional stories. A short example follows:

User Registration

A User enters his personal information into a form. The information is validated, so that the required information is entered. The data is then stored, and made available for future use.

This story is short, concise, and complete in its own right. This can be part of any project, and it doesn't have to be a web based project -- it can be a paper form, a verbal form, a virtual form, or some other form I don't know about. What this allows the customer to do, is define the setting of the whole project -- so that these stories are set in a common setting.

Keeping stories really short and simple allows the developers to ask the most important details from the customer, so that this information can be noted properly, and communicated and discussed in detail. This is done so that all the developers involved in the development process will have a common reference, and so that the customer and the developers are on the same page.

Creating these stories allows the customer to define the functional requirements from the system without having to burden himself of the technical details. This also allows the developers to isolate the customer from the technical details of a system and focus on delivering the functional requirements.

A well said story is one that usually gets told again. A well understood story is one that doesn't need repeating.