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.  (more…)

Advertisements

Some states are entrances!

User stories are a way of stating requirements.  Ron Jefferies coined the meme, the Three Cs to describe a user story.  The 3 Cs are:

  1. card,
  2. conversation, and
  3. confirmation.

The idea of a card was to keep the user story short to avoid making the requirement overly complex and to avoid analysis paralysis. Because the card was a short statement of the user story, conversations are required to expose the nuances of the user story (note: nowhere does it say NOT to document your conversations. If someone tells you not to document your conversations, forget them!).  Finally, the third C, confirmation equates to testable statements that allow the team to know when the user story is satisfied. User stories might begin as nebulous statements, however, when groomed, a well-formed story provides strong guidance on the business need to be addressed.

User stories pass through four basic states. (more…)

The current is just below the surface!

Where do user stories come from and where do they go?  Agile or not, the requirements, needs, and nuances of users and customers need to be collected, written down, prioritized, and groomed.  Even though this process sounds linear it usually happens over and over again during the cycle of value delivery.  The of techniques for gathering requirements and translating those requirements into products, features, epics and user stories are varied, and we will explore them. However, first, we need to define the typical path.   We will pick the journey up after strategic definition/vision (described in our article on hierarchy)  has been identified just as or before product definition.  Here is the basic flow: (more…)

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: (more…)

Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done. (more…)

Identify the risks before you start with a premortem.

Storytelling generates the big picture to guide a project or to help people frame their thoughts. A story can provide a deeper and more nuanced connection with information than most lists of PowerPoint bullets or a structured requirements documents. Storytelling can be used as a risk management tool.  Premortems are a useful tool for helping project teams anticipate risks.  Premortems were described in the Harvard Business Review, September 2007 by Gary Klein.  The basic premortem approach can be can be customized with storytelling to increase the power of the technique. (more…)

Stories help you visualize your goals

Stories help you visualize your goals

In the Harvard Business Review article, The Irresistible Power of Storytelling as a Strategic Business Tool by Harrison Monarth (March 11, 2014), Keith Quesenberry notes:

People are attracted to stories because we’re social creatures and we relate to other people.

The power of storytelling is that it helps us understand each other and develop empathy. Storytelling is a tool that is useful for presentations, but also to help people frame their thoughts and for gathering information. A story provides both a deeper and more nuanced connection with information than most lists of PowerPoint bullets or even structured requirements documents. Here are just a few scenarios (other than presentations) where stories can be useful: (more…)