The feature image for this article is several of the “Twelve Apostles” in Victoria, Australia. Having been there several times in the 1990s, while we were living in Melbourne, I can attest to their beauty and immense size. On our first visit my wife and I were accompanied by my parents who, in the early 1960s, got married but were not able to take their dream honeymoon to Australia at that time. This trip was, for them, a long delayed honeymoon.
A Quick Definition – User Story
Kent Beck, of eXtreme Programming (XP) fame, first introduced User Stories in 1997. They are meant to be told from the perspective of the users of a system.
“A user story is a promise for a conversation”.
Alistair Cockburn, 1998
The 3 key elements to capture when defining a user story are:
- Who: we need to understand who will benefit from this effort.
- What: define what they need to accomplish, often referred to as the “desired outcome”.
- Why: describe why this is important to them, what impact will be achieved.
User Stories should not include how of fulfill the request. That should be left up to the development team to define and then implement.
The 3 C’s
In 2001 Ron Jeffries introduced the 3 C’s formula for defining user stories. The 3 C’s are:
- Card: a “written” record of the objective. Before the creation of electronic tooling, the card was a physical 3×5 index card which was posted on a wall somewhere. The card was purposefully small, read on to discover why. Today these cards are created and managed in ALM (Agile Lifecycle Management) tools such as VersionOne or Jira.
- Conversation: discussions with users, stakeholders, developers and others as needed. These conversations elicit the story elements (who, what, why) which are documented on the Card. Various artifacts may be created to supplement the conversations. The conversations happen, as needed, during the lifecycle of the user story.
- Confirmation: define how the objectives, or goals, as discovered in the conversations, will be verified.
A Common Card Template
In 2001 an XP team created a template for recording user stories that is still very popular today. The format of the template:
As a <user role> I want to <do something>, so that <receive a benefit>
where the information between the braces are the 3 story elements: who, what and why.
While the template is very common its usage is not mandatory. For new teams it is a great way to get started with user stories and reminds them of the key information to gather.
A Misconception
I encounter many teams who use user stories as the “Agile way” to define and record the requirements of the system. Essentially a BRD is chopped up and recorded in the ALM tool as a bunch of user stories.
The expectation is that developers can understand everything they need from the written card. It is a complete record of everything they need to do and test. There is a hard handoff with perhaps a short conversation during Sprint Planning. “Throwing it over the fence” is often the perfect description.
If the development team is offshore this creates large delays when questions arise or misunderstandings are discovered. Wait times, due to timezone differences, soar.
This not only greatly reduces agility (BRUF) it misses the main point of user stories. User stories are meant to be told, they are not meant to be read.
Which leads me to state that the least important part of a user story is the card itself.
Vacation Photos
So why did I tell you that personal information at the beginning of this article? It’s to illustrate this concept – the written card acts as a vacation photo to remind people of the conversations.
For example, without scrolling up, can you remember where the Twelve Apostles are located? Who accompanied my wife and I when we first visited them?
How about if I show you the image again. Does it jog your memory at all?

The written user story can act as a “vacation photo”. They are not expected to tell the whole story. Just as with looking at a photo you won’t know the backstory. What was happening at the time the photo was taken? How did the photographer come to be in that place and why?
The user story card itself is to remind you of the conversations that have occurred to discover the objectives and goals of the user. The card reminds you to have additional conversations once development nears, begins and concludes.
The most effective, high agility teams I have ever worked with paired the PO with developers as work was happening. Real-time conversations, answering questions and providing guidance as the work was being done. You cannot get much better shared understanding than that!
One risk of user stories is having the conversations too far in advance. When that happens people will forget and then there is a high tendency to write too much on the story card as a remedy. Remember, initially user stories were recorded on 3×5 index cards for a reason. That reason was to stop people from capturing too much information on the written card and relying on the written words to convey understanding.
Shared understanding will be far better achieved using conversations where questions can be answered and clarification provided.
Wrapping Up
I see far too many teams who rely solely on the written story card to convey understanding. Often these cards are created weeks to months in advance of doing the work. Misunderstandings will occur at a far higher frequency when words are used to convey information in place of having just-in-time conversations.
When misunderstandings occur, teams will often spend an inordinate amount of time and energy attempting to “get better” at writing user stories. Many trainings, workshops and other activities occur.
If you want to improve value delivery, get better at telling user stories rather than writing them.
Having multiple conversations throughout the lifecycle of the user story will increase agility and correctness of understanding. As a result, accuracy will increase, rework will decrease and customers will be happier.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
