When I was first introduced to the idea of using user stories in a commercial environment I didn’t really know what they were. I’d seen some other people using them and noticed that they seemed to be a breakdown of what was needed for a given system and then the developers would pick up one story at a time and work on it. “Marvelous!” I thought, but what’s the point?

A brief introduction to user stories

www.agilemodeling.com define User Stories as being:

User stories are one of the primary development artifacts for XP project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP project stakeholders are called customers).

Ron Jeffries Three C’s:

Ron Jeffries of xprogramming.com has identified three many components that make up User Stories:

Card

• Stories are traditionally written on note cards.
• Cards may be annotated with estimates, notes, etc.

Conversation

• Details behind the story come out during conversations with product owner.

Confirmation

• Acceptance tests confirm the story was coded correctly.

Source: XP Magazine 30/08/2001, Ron Jeffries

So what’s the point in all of this?

For those of us who have worked in AGILE environments  before it will seem obvious to say that communication is the key to any succesfull project however for many, this idea can be quite a new concept.

But what is communication? When we talk about communication as a noun (nominalisation) it’s easy to “think” that you’re communicating effectively and as long as “communication” is “done” then you’ve done all that’s required. In my experience, that’s not what really happens and the necessity to de-nominalise the term “communication” is of huge benefit.

Depending on who you’re communicating with determines how you communicate. When working between teams, whether it be between technical teams or between techies and the business, there are certain parts of the communication which are vital:

• A common language that everyone can understand
• Clarity in communication eliminating as many ambiguities and nominalisations as possible
• Flexibility, not only for negotiation but also flexibility in what you say, how you say it, and what your intent is with the things you say.
• Language to experience map-across (re-connecting the words said with the actual experience they describe)
• Clear intent for the communication it’s self (what are we all here for)
• The ability to accurately gather information (ask targeted questions, listen in an information gathering way etc)

These are just a few of the things that I consider necessary for good communication and I’ll be covering many of them in more detail, plus more, in a new series of posts about communication.

User Stories are one step in the bigger picture of communication. By reminding ourselves to discuss things with real people, by chunking information in such a way that it becomes more easily estimatable and trackable and by promoting a transparent work ethic, we all win.