Differing definitions are a lot like swimming without a lifeguard!

A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word user story gets mentioned or even by people that understand (or care to understand) the concept of a user story.  

The basic life cycle of a user story includes the following states:

Business Idea or Needs reflects the definition of business goals in relations to customer needs. Organizations define what they want to do or deliver. This might require many different types of analysis including market, enterprise and strategic analysis.  Many organizations put a huge amount of effort into identifying and defining business needs.

Products describe a cohesive set of features and functions that satisfy a business idea or need. Microsoft Word is a product.

Realistically, it is easy to agree on the definitions of ideas, needs, and products and their place in the user story hierarchy.  This level of definition typically occurs once in a life cycle (or a few times in the case of reinvention).  The next steps get less well defined in an agile environment.

A feature, sometimes called a theme, typically refers to a part of a product (or application) that provides a specific set of business functionality.  The functionality addresses an end-user need.

Epics describe a large piece of user functionality that can be broken down into smaller parts.

User stories are individual pieces of work that can complete quickly and deliver a coherent piece of user functionality.   User stories are the base of the agile requirement hierarchy.  User stories can be written for business requirements, non-functional requirements, and transition requirements.

The definitions of features and epics are often flipped.  Some practitioners in the industry define features as global functionality broken down into epics and then into user stories. While others, Mike Cohn (Mountain Goat Software) for example, defines a theme or feature as a collection of related stories while an epic is a large user story.  I am in this camp.  Whether a feature or an epic is larger is a bit of “chicken or the egg” discussion. What is more important is consistency.  Consistency is important because it allows teams and organizations to have a conversation without tripping over terms.

 Defining a hierarchy and a set of terms to describe that hierarchy is delivers the ability to talk the same language within and across teams.  Defining a hierarchy acknowledges that people typically begin thinking about a product or function in general terms and then becomes more specific over time.

Note:  We will draw a picture after the process discussion.  Needless to say, there are a LOTS of entry points for user stories of all sizes into the hierarchy and the process which makes the discussion of user stories and agile requirements exciting.

Next: Agile Requirement Process Flow