User Stories have proven to be a great structure for expressing Stakeholder Requirements whether your projects follow an Agile, Iterative, or Waterfall SDM. A complete User Story has three primary components, namely the “Card”, the “Conversation”, and the “Criteria”. The “Card” expresses the business need. In this KnowledgeKnugget™ you will learn what User Stories are, where they fit in an Agile or Waterfall methodology, and how you should express User Story Cards.

User Stories Define Stakeholder Requirements

There are two fundamental roles in any business transaction, a customer (one who wants or needs something) and a provider (one who has or can acquire that same thing). Bringing these two roles together has been a challenge mankind has faced since before civilization began. If the something in question is an Information Technology (IT) system, the terminology is more current but the basic challenge remains. Since we invented IT, the single biggest challenge has been communicating what the customer wants in a manner that the developers can deliver.

Until recently, “requirements” have been the answer. Requirements define the behaviors and qualities that the IT solution has to exhibit to meet the customer’s need. How we express requirements at various levels of detail is a topic about which there is an on-going (and seemingly eternal) debate. The IIBA® (International Institute of Business Analysis) has identified four distinct “levels” or “layers” of requirements, namely “Business, Stakeholder, Solution, and Transition” requirements that describe the solution in layers of detail. By this definition, “Business Requirements” are the basis upon which the organization initiates projects. The individual project then flushes out the detail in the remaining three levels.

Organizations using an Agile Software Development Methodology – aka SDM (in particular the SCRUM/XP flavors) propose replacing in particular the “Stakeholder” level with a concept called “User Stories”.

But what, exactly, are “User Stories”? In summary, a “user story” is:

• A mechanism for describing an IT system from the usage perspective
• A statement expressing the desired outcome of a single interaction with an IT system
• Written from the perspective of a specific role the person initiating the interaction is playing
• Justified by the business objective or value the initiator is trying to achieve
• Replaces up-front documentation of “software requirements” with an ongoing dialog between users and developers

… [end of excerpt]