Card
The card is important in that User Stories are meant to be written on Cards. My interpretation of the card metaphor is that Stories need to be short and concise enough so that they can fit on a single card. It's imperative that Stories are small enough such that they can be estimated and completed in a single iteration. When teams struggle to come up with estimates, this is usually a good sign that the story is too big and should be broken down. It's good sometimes, however, for longer term planning to have large stories i.e. epics or themes. But these need to be broken down into small enough chunks as they get closer to being prioritized into a sprint. Another great feature of the Card metaphor is that it's meant to be very visual. It's always great to walk into a Scrum room and see the cards on the wall. At a glance, you can see the story, the estimate, how much time is left, and what state it is in (open, in-progress, in-test, accepted). Cards also provide the sense that they're dynamic i.e. they can be changed, updated, moved, and trashed. That's the whole idea behind the Agile philosophy - to accept and embrace change.

Conversation
What makes the Conversation so important is that the conversation is much more important than the story itself. That being said, it's still important to get the story right. Another thought on why Conversation is one of the 3 C's is that conversations are usually understood by all parties i.e. developers and customers alike. It's important that the story description is written in the customers eyes as this is most easily understood by everyone and so as not to get confused by technical jargon.

Confirmation
The C in confirmation is all about identifying up front what is going to make the customer happy and accept the story as completed. By definition, user stories must be testable. By providing the test cases up front, the team is properly setup to succeed. This really helps to prevent churn and back and forth with the customer at the end of the sprint.

Capture
There are many ways in which to capture (dare I suggest this is the fourth C) user stories. The best way I find is by way of User Story workshops. The reason I like workshops is that it's cross functional and it generates lot's of "Conversation". And especially if you're trying to capture a lot of user stories in short while, this is by far the best approach. There is nothing like a good brain storming session to get the creative juices flowing. Other ways include interviewing end users, watching users use the software, competitive analysis etc.

Backlog
An interesting article I saw recently on user stories asked the question "is there need for an Idea Log?" i.e. a separate log for ideas to be formulated before going into the backlog. My opinion on this is that you never know when and where the next great story is going to come from. Every idea is probably a good one and should be considered. I still believe in a single backlog to manage all user stories. Even if it get's a little out of hand. In this case, one can consider initially grouping multiple user stories to make it more manageable. And then, when the story is considered high enough of a priority, the story can be dis-aggregated into smaller ones. There's a certain importance suggested when telling customers "it's on the backlog". If it doesn't go on the backlog, folks are going to stop coming up with ideas.

Story template
Finally, when you write user stories be sure to include the benefit, i.e. "As a frequent flyer, I'd like to redeem my air miles because they're about to expire". The reason for the benefit is that it adds color to the story and helps the developer to understand the intent a little better.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com