The concept of user stories is a well-known tool for describing requirements. In a simple format, it captures the ‘who’, ‘what’ and ‘why’ of a requirement. User stories have their roots in Extreme Programming (XP) and are an often-used tactic within Scrum. In 2001, Ron Jeffries proposed the Three C’s formula as a guide to capturing the essence of user stories: Card, Conversation, and Confirmation.
A card is a physical token giving tangible and durable form to what would otherwise only be an abstraction. A conversation is taking place at a different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation. The confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally[1].
The concept of user stories can be very powerful when the Three C’s formula is respected. Especially within a complex environment it’s crucial to understand the idea behind user stories and use it properly. The problem however is, that quite often this isn’t the case. The cards become digital tokens (hidden in tools like e.g. Jira, TFS) that remain an abstraction. The conversation hardly takes place via face-to-face communication. The valuable dialogue between the customer, users, Product Owner and Development Team often doesn’t occur. Therefore it also lack the exchange of thoughts, opinions and feelings to truly grasp the essence of the user story. The confirmation often is surrounded with misunderstandings, because of the lacking conversation. This causes the stakeholders and development team not having a shared understanding of the ‘done state’ of the requirement.
The essence of a user story is to discuss the story with the user. Ideally it’s the Development Team that discusses the desired functionality with the actual user. The more concessions you do to this ideal state, the less powerful the concept of user stories will be.
What is your experience with this? Do you recognize the pitfall I describe?
[1] https://en.wikipedia.org/wiki/User_story