Kitchen remodeling is an epic comprised of many stories.

Kitchen remodeling is an epic comprised of many stories.

A user story is a brief, simple requirement statement from the user perspective… sort of.  In the wild, user stories come in multiple sizes, can be grouped many ways, and can be used to represent more than just functional requirements.

User stories come in many sizes.  The term epic is often used as a label for large stories that will be broken down into smaller pieces. Conceptually an epic is group of closely related user stories that have not been explicitly realized. A rule of thumb for identify epics is that they generally can’t be completed by a single cross-functional team in a single sprint. As teams breakdown epics into user stories, typically, the story can be completed by the team within the sprint.  The level of granularity should be as small as possible (thin slices of usable functionality) in order to reduce the chances of a story creating a bottleneck. Mike Cohn (SPaMCAST 43 and 45) coined the acronym: INVEST to describe a user story. A user story is:

  • Independent: they stand alone
  • Negotiable: they are a conversation
  • Valuable: they deliver a benefit
  • Estimatable: the team can determine how long it will take to complete the story
  • Small: or sizeable, and
  • Testable: the story can be proved

Themes are a common mechanism to describe high-level objectives, products or sub-components of products. Themes can include many epics (or in extreme cases only one) and user stories, and may be implemented across multiple programs.  Themes act as a convenient mechanism to group functionality so that stakeholders at different levels of the organization (executive to developer) can conceptually understand what is being requested. As with any grouping, once a hierarchy is established someone with rush to identify steps along the continuum. Some tools and theorists talk about themes and sub-themes. An example one of the themes for developing an interview based podcast would be to prepare an interview for podcasting.  Stories and epics would be needed to schedule the interview, record the interview, edit the interview and package the interview for the podcast.

What can be described as user story?  Many proponents of the concept of user stories would suggest that stories can only be developed for functionality targeted only toward user, i.e. any person or “thing” that interacts with the software. Many pieces of work like issues, risks and infrastructure would be documented using a different mechanism.  However, the world has moved forward since the early days and now the discipline of the user story can and is many times applied to all types of work.  For example, a mature Agile organization I spend time with documents project and program risks as user stories and incorporates those stories into their backlog.

User stories are a means to an end.  They help stakeholders and Agile teams understand what needs to be accomplished.  Using the standard structure of a user story (persona, goal, benefit) to organize all of the pieces of work facilitates conversations. Grouping mechanisms like epics and themes help stakeholders at all levels understand the project and groups of functionality conceptually, which again facilitates conversation. More conversation leads to a greater probability of delivering what is needed and wanted.