User Stories and why we love them

Recently, I had the opportunity to train a group of Marketing professionals on writing User stories. At the end of the session, one of the attendees remarked that I seemed to be very enthusiastic about something that is clearly just old wine marketed in a new bottle. While it is true that I am enthusiastic about using User Stories, I  had to disagree – User Stories are much more than just a gimmick.

When you were first taught about writing requirements, more likely than not, you would have come across the IEEE standard. Those requirements looked like these two examples:

Requirement ID 5.1.1 The system shall provide Users with a drop -down that will include all names of all countries ( using ISO codes)

Requirement ID 5.1.2 The system shall provide Users with the ability to select a Zip code ( all US and Canada codes)

The IEEE standards are comprehensive and  very structured. They assume the luxury of having a long “Requirements phase”  where a Business Analyst ( who has “Subject knowledge”)  has all the time needed to meet with  the business users, understand their requirements in depth, document the same, get the requirements reviewed and finally signed off.

These days, this approach might be possible but not very probable. It has been years since I have worked on a project where the Business Stakeholders knew exactly what they wanted and the Project Sponsors agreed to a lengthy requirements gathering phase.  Instead, increasingly the Business Stakeholder demands instant results. With the spread of Web 2.0 technologies, there is increasing pressure  to quickly  demonstrate glimpses of the final product.  And marketeers are keen to have the “first to market” advantage.  That is why Agile Project Management methodologies are so attractive to so many development organizations – they dramtaically increase stakeholder confidence   by delivery of working software in weeks, not months or years !

Its obvious that this fast – paced environment required a new way to  discover, document and communicate requirements needs to change too and “User Stories:” became my ( and other people’s) “tool-of-choice”. A User Story is literally just this : A Story of a particular functionality that is desired by the Business, narrated in simple language and de-linked from implementation details. User Stories help to establish a common language for the team as a whole – including developers, UI designers and the Business stakeholders.  Time is a precious commodity and  User Stories get requirements out  to developers fast. Since User Stories focus on functionality and not technology implementation, they allow the Developers to creatively suggest solutions, rather than being constrained by what the Business thinks they want technologically( which is very often completely different from what they really want!).

Revisiting those  IEEE requirements mentioned earlier , the User Story version is simply :

“As a User , I want to be able to enter my address so that I can complete registration on the Website.”

The Business Stakeholder has told the Developers what they want and why. The Developers are now free to suggest solutions which maybe a form-like interface or maybe a visual representation of a map where the User can select their State and then drill down further to add address details (which maybe a solution that the Business finds far more appealing than a drop -down!)

When we write requirements with implementation details, we close ourselves off from other possibilities. Developers are free to begin working on the story without worrying about requirements that are yet to come. The Business can proceed with writing the next set of stories while the Developers work on getting this functionality out.User Stories also help to defer detailed decision making till later on in the project. They can help to uncover risks earlier in the project.

Consider a story “As a User, I should see the lowest price depending on the length of my membership in the website so that I can be sure that I am getting the best deal”. Once again, the Business has clearly stated what they want and why. The Developer who sees this story can immediately start thinking about dynamic pricing and how that could be achieved. This may end up being a technical risk for the project that our simple story has helped uncover.

I like working with User stories because they are inherently simple and brief. Coupled with “Acceptance tests”, they form a complete description of the desired functionality. In the past, there have been projects where I labored on requirements for months and at the end of the “Requirements phase” discovered that changes in the market forced us to rework lengthy requirements documents. In fact, on almost every project I’ve worked on,the requirements were never really “frozen”. User acknowledge the reality and minimize the amount of rework .

In conclusion then :

User Stories :

  • Are small and simple
  • Are de-linked from implementation details
  • Help to establish a common language
  • Help uncover risks early in the Project

2 Responses to “User Stories and why we love them”

  1. Agile Scout says:

    Thanks for sharing this story with us. User stories make sense. The best part about user stories or shared user stories is that you collaborate when you make them. User stories are the starting point for a discussion, and you build out the details through the process.

  2. Aruna says:

    Thanks for stopping by. I agree that the collaborative aspects of User Stories make them so valuable.

Comments are now closed for this article.

About FitForProjects

Based in San Francisco, we specialize in dramatically improving organizational performance by utilizing pragmatic analytics and advanced project management techniques.

Contact Us

Need to contact Us? You can send an email to via LinkedIn or Facebook