The 3 C’s (Story Reminder, Story Elaboration, and Story Confirmation) are stages User Stories progress through to prepare them for building. Many organizations using a Lean or Agile approach to software development generally propose replacing “Stakeholder level IT requirements” with “User Stories”. User Stories are also quite often mentioned in connection with Design Thinking, a new paradigm that goes well beyond developing IT solutions. But what, exactly, is a “User Story”?

The User Story Paradigm Is Lean Requirements Engineering

Taken in the context of a lean or agile software development philosophy, the user story paradigm not only identifies the important questions, is also moves the timing for getting the answers to the last responsible moment when they are most likely to be correct.

User Stories, like Gallia, have 3 parts. For User Stories, the parts are often called the Card, the Conversation, and the Criteria (or Confirmation). This definition goes back to the origins of User Stories in a software development approach called “XP” or “eXtreme Programming”. At that time, User Stories were handwritten on a 3X5 index card.

Today, “the Card” can be in any form (electronic or hand-written). The purpose of the card is to serve as a reminder for an upcoming conversation with the developers.

“The Conversation” is a reminder that the User Story is not a requirement but a trigger for a conversation between the author and developers that should not be scheduled until the developers are ready to start coding whatever functionality the story needed.

“The Criteria” refers to Acceptance Criteria that used to be written on the back of the index card by the developer during the conversation to capture how the author would know whether the story worked once the code was delivered.