On most agile teams, user stories are a way of capturing requirements. They aren’t technical specifications – they are lightweight business-focused descriptions of functionality that should foster communication and shared understanding for a team developing a product or service. You may have heard of the “3 C’s” of user stories: Card, Conversation, and Confirmation. You also may want to add a fourth: Context.
CONTEXT
The Foundation of a Good Story
Every user story needs context. Without it, a story can lose its meaning. Context sets the stage: Who is the user? Why do they need this? What problem are we trying to solve for them?
A good user story always starts by identifying the user and their goal. This can be expressed using the following format: “As a [user role], I need [a feature or piece of functionality] so that I can [achieve a goal or business value]”. This structure gives the team a shared understanding of the user’s needs and keeps development focused on delivering real value. It also helps ensure that the feature or functionality is actually needed and not just a want.
EXAMPLE
As a frequent business flyer I want to save my business credit card in my profile so that I can book flights faster.
By establishing context, teams can empathize with the user and prioritize work based on real-world needs, not assumptions.
Context starts with the question “where are we in the roadmap of the solution?”
Let’s take an example from a real project I was on. I was on a team building out a new invoice processing system within a small start-up company. I built out a process flow (swim lane) diagram to show how we envisioned the future state to work, from a business perspective. It showed the steps and the major decision points we needed to consider. We built out our roadmap of features based on that flow. We used that diagram and the roadmap across the life of the project to help the team understand the context of each piece of the solution they were building. We broke each feature down into user stories as the project progressed.
Context also includes the scope of each user story. If we are building functionality in software, the context would tell us: where are we in the software? What is in place when this story starts (also called a precondition). What is in place when the story ends (also called the postcondition). Without a pre- and postcondition, the developers and testers will struggle to understand where the requested functionality happens.
Back to my invoice processing solution example: one of our stories was “as an Auditor I need to compare each invoice charge against the contract to ensure our client is being charged correctly.”.
The precondition for this story was:
- The invoice charges are loaded
- The contract details are loaded
- The Auditor is logged in and on the Home page
The postcondition was:
- Any charge that is different from the contracted charge is displayed to the Auditor
- Any charge that the Auditor marks for dispute is flagged (in the database).
The developer then knew where this story needed to begin and end. In a nutshell, the developer built out a page where the Auditor could analyze any discrepancies in the charges vis-à-vis the contract and mark the items that they wanted to go dispute with the vendor.
CARD
The Physical or Digital Placeholder
The Card represents the user story itself. When I first built user stories, we wrote user stories on physical 3 X 5 index cards, but today most teams use digital tools like Jira or Azure DevOps. Regardless of the medium, the card initially acts as a placeholder for the story, not the entire specification. It’s a placeholder for further discovery, discussion, and decision-making.
A card should be brief using a format like the one in the previous section above — just enough to start a conversation. It’s not a detailed contract, but a reminder that further discussion is needed to flesh out the details when the time is right. We often talk about “just-in-time and just enough” for requirements in a user story. I coach most teams to flesh out the needed details somewhere between 2 and 4 weeks ahead of the projected development time. This keeps requirements “fresh” – we haven’t forgotten what we already discussed and agreed upon.
The simplicity in the card helps with prioritization and flexibility. It allows the team to quickly adapt as needs evolve, because if we have to pivot, we haven’t wasted too much time detailing out stories that may never be implemented.
CONVESATION
Building Shared Understanding
The Conversation is where much of the real magic occurs. The discussions between the product owner, developers, testers, designers, and any other stakeholders involved take the card from a placeholder to a fully fleshed-out idea for the solution.
Through conversations, the team:
- Clarifies requirements: the look and feel of this piece of the solution, the steps the user will follow, and the data and business rules used within the steps
- Explores edge cases: those unexpected scenarios that occur that product owners don’t always think of. Listen for “usually” and ask what can happen that is unusual.
- Identifies risks: where can things go wrong? What dependencies are there within this story, with other stories, or with other applications or databases? What assumptions have been made? What constraints can impede a great solution or our progress towards one?
- Uncovers better solutions: good conversations should explore questions like “what if we did it this way” or “let’s make this better”.
Conversations ensure that everyone has a shared understanding of what needs to be built and why. They also provide an opportunity to question assumptions, surface hidden requirements, and agree on what “done” really looks like.
Importantly, conversations are iterative. They can happen when the story is first created, during refinement, and just before development begins.
I find that many teams avoid the good conversations. I recently heard a BA say “it’s in the documentation, just go read it.” I literally cringed. I had to have a conversation with that BA about having conversations! Documentation is wonderful, but talking through the problem, the details, and the solution options are what really matter. The documentation is important for referring back to, for organizational memory, and for knowledge transfer, but it’s not the best vehicle for the initial communication around needs and solutions.
CONFIRMATION
Defining Done for a User Story
- Clear
- Testable
- Focused on outcomes rather than implementation (the “whats” versus the “hows”)
- The auditor can choose the invoice to audit.
- Any charge that doesn’t match the contracted rate is displayed.
- Any charges the auditor decides to dispute can be marked.
Conclusion
User stories are much more than simple sentences in a list or on sticky notes. When teams consider the four C’s that are Card, Conversation, Confirmation… and Context, they unlock the real power of agile analysis: collaboration, adaptability, and delivering customer value.
By focusing on the C’s, you help ensure that every story is not a disparate request for things to do, but a meaningful step toward a better product. Then teams are building the right thing, in the right way, with the right level of collaboration, at the right time.
Ali Cox
LEAD EXPERT
Alison (Ali) Cox has experience since the mid-1980s in various areas, including business agility, business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunication expense management. She began her career in the financial services area, and then moved into systems development for accounting systems.
Ali has lived through IT and operational initiatives from waterfall to implementing agile in her own small business, then helping other companies do the same through training and mentoring. She believes that having the small business mentality (everyone has to pitch in on everything) is the right kind of mindset for all organizations, no matter the size or industry.
Ali is the author of Business Analysis for Dummies, 2nd Edition.
