User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality.  That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!

All three concepts are important in order to use the concept of user stories in a dynamic environment where agile and lean work is pursued.  An example is helpful to see how a user story hierarchy, flow, and states fit together.    In the following example, we will follow an automotive example to highlight the user story hierarchy, how the item impacts the user story flow, and which user story states apply to the hierarchy. 

 

Business Idea or Needs reflect the definition of business goals in relation to customer needs.  As we have noted, business needs are at the top of the hierarchy.  An example of a business idea that Henry Ford might have once had is that as humans we need a method to quickly and safely get from point A to point B that isn’t a horse.

User Story Flow: _X_ Voiced  _X_ Documented  _X_ Managed N/A Built 

Business needs, at least as people begin to evaluate the idea, need to be talked about and refined (voiced), written down (documented), and evaluated (managed).  They are not built at this point in the user story lifecycle. Ideas are not built until they become more tangible. 

User Story States:  N/A Forming  N/A Not Started  N/A In-progress  N/A Done

User story states are not applicable to business needs.

 

Products describe a cohesive set of features and functions that satisfy a business idea or need. The concept of moving people from point A to point B the product can be solved by the product, automobile. I recognize that automobiles can be broken down into many different products ranging from subcompacts to sports utility vehicles.  Henry Ford began with one “product,” the Model-T.

User Story Flow: _X_ Voiced  _X_ Documented  _X_ Managed “Sort of”  Built

Products are similar to business needs.  They need to be voiced, documented and managed.  Products exist so it is easy to jump to the idea that they are built.  Arguably, products are the assembly of building user stories (which are the lowest level of the user story hierarchy).

User Story States:  N/A Forming  N/A Not Started  N/A In-progress  N/A Done

User story states are not applicable to the product level.

 

A feature, sometimes called a theme, typically refers to a part of a product (or application) that provides a specific set of business functionality.  An important feature (at least to me) on a modern car is the rear window defroster. For those of you that don’t live in an area that doesn’t have cold weather that results in frost or heavy dew on your rear window, the defroster heats the window to melt the frost quickly so you can see out of the window. A rear window defroster is important but only part of the automobile.  

User Story Flow: _X_ Voiced  _X_ Documented  _X_ Managed “Sort of”  Built

Features follow the same pattern seen as we transverse higher levels in the user story flow.  Features are voiced, documented, and managed. Features can and often do emerge over the entire lifecycle of the products.  Like products, features are often tangible so something has been built but it’s the user stories, not the feature.  

User Story States:  _X_ Forming  _X_ Not Started  ___ In-progress  ___ Done

Features are often placed on the product backlog.  Whether features Epics will need to be captured, researched, and triaged so that they understood — forming.  Before the development (including configuration) can be done epics will need to be groomed and broken down — not started.  Epics can only be in-progress and done by inheritance from the stories that are generated when grooming.

 

Epics describe a large piece of user functionality that can be broken down into smaller parts.  An epic that is part of the rear window defroster feature is the need to heat the rear window. The epic could easily be stated, “as a driver I want to heat my rear window so I can see out of the window.”  The rear window defroster is a complicated system made up of several components ranging from the dashboard components to the grid embedded in or on the rear window. Each of these could be epics (large user stories that can and should be broken down).

User Story Flow: _X_ Voiced  _X_ Documented  _X_ Managed “Sort of”  Built

With Epics are nearly at the level that work happens.  Epics follow the same pattern as features but at a more granular level.    

User Story States:  _X_ Forming  _X_ Not Started  ___ In-progress  ___ Done

Epics are part of the product backlog.  Epics will need to be captured, researched, and triaged so that they understood — forming.  Before the development (including configuration) can be done epics will need to be groomed and broken down — not started.  Epics can only be in-progress and done by inheritance from the stories that are generated when grooming.

 

User stories are individual pieces of work that can be completed quickly and deliver a coherent piece of user functionality.  Part of rear window defroster epic is that the heater for the rear window needs to be turned off after a specific amount of time. The story could be written, “as a driver, I want the rear window defroster to turn off after 15 minutes so that I am not draining the battery.”

User Story Flow: _X_ Voiced  _X_ Documented  _X_ Managed _X_ Built

User stories pass through all steps in the flow.  If user stories are not converted into functionality (built – regardless of whether coded or configured) epics, features, products, and ideas will never be completed.

User Story States:  _X_ Forming  _X_ Not Started  _X_ In-progress  _X_ Done

User stories pass through all of the states.  

 

User stories can pop into existence without decomposing an epic or feature; however, a user story will always be related to a product.  Capturing that relationship is important so that the team will understand who can provide input and why the story is important. The hierarchy, flow, and states provide a model to understand how ideas evolve into something that delivers value to the organization.