Web Developer, Software Engineer and Mixed Language Artist
RSS icon Email icon Home icon
  • User Stories

    Posted on April 6th, 2009 Jamie 2 comments

    User stories are an integral part of Agile but how come?

    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.

     

    2 responses to “User Stories”

    1. I propose that in the business computing environment; communication is the key issue that faces development teams; not technology.

      Unfortunately, I think that the very personality types that are drawn to being developers naturally avoid communication.

      When was the last time you sent an email to your collegue sitting next to you, rather than just talking to them….

    2. Hi David,

      It’s certainly true that communication is one of the key issues facing development teams.

      I also think that developers are now becoming more open to the idea of communication but there is a long way to go.

      We’ve gone from the basement programming geek sterotype to a more open and agile environment in some places and I think it’s a step in the right direction.

      The gap between “the business” and “the developers” is slowly shrinking (or at least that’s what would be nice) and the more it shrinks and the more communication becomes the forerunner to good development practices, the more profitable it’ll end up being for the company overall.

      Emails to collegues can be good as reminders for conversations, especially when people are busy at the present moment. I think one of the main fears of developers is that if they start talking with people and communicating effectively, their workload will double or tripple.

      It’s easy to keep “the business” at arms length by not communicating with them and this is why good communication needs to promote negotiation skills as much as anything else.

      The business, including it’s developers, need to be able to discuss requirements and ensure that the customer and the business get what they need not only at the end of the project but during the project also.

      There will be more to come on the topic of communication since it’s something I’ve been studying in depth for the past 7 years or so.

      Thanks again for the comment David. :)

    Leave a reply