The 3 C’s of User Stories are Missing a C-EN

Anyone familiar with user stories should also become familiar with the 3 C’s of User Stories. Whether you are a newbie or a seasoned veteran, the 3 C’s of User Stories help keep the purpose of the user story in perspective.

• The first C is the user story in its raw form, the Card. User stories are manually written on index “cards” to keep them concise. The standard format has 3 basic components: As a [user type], I want / need [goal] so that I can accomplish [justification/business value]. The Card is a just a place holder.
• The second C is the Conversation. The Conversation is necessary to get further details about the Card. The conversation promotes the incremental and continuous collaboration among the agile team needed to build a shared understanding around the problem and potential solution.
• The third C is the Confirmation. Confirmation is the acceptance criteria which captures the essential requirements and translates them into the test criteria so that we know when we’ve successfully delivered the user story.

While all of this provides great value, there is still something missing…I would like to introduce what I consider, the missing C. I identified the missing C through feedback and gap analysis received from the many different agile implementation teams that I have taught and consulted. A majority expressed that they were struggling and not being successful using agile to build their solutions.

When teams start getting frustrated with agile, the first thing they usually point to as the problem is the user story. When I hear this, I ask them why they think the user story is the issue. Answers typically fall into 1 of 4 response groupings:

1. “The user stories aren’t getting completed within the sprint.”
2. “We aren’t building the right things.”
3. “We aren’t sure how to test the solution.”
4. “We aren’t sure if they captured everything for the complete solution or if there are gaps.”

When hearing these replies, I immediately redirect the team’s thought process away from the user story. User stories tend to be the scape goat, but really they’re a symptom of a bigger issue. So I start my root cause analysis by stepping through their pain points and applying techniques and models (like the 3 C’s) to address their concerns. If people followed the 3 C’s method when developing their user stories, most of their challenges would be resolved. However, there is still one area that doesn’t get addressed by the 3 C’s – Context, a.k.a. the 4th C.

The chart below shows how most of these symptoms can be address by the 3 C’s and additionally, how the 4th C is used to address the symptom not covered by the existing 3 C’s.

Pain Point

Application of the C’s

“The user stories aren’t getting completed within the sprint.”

Application of the C’s

Card: Remember the story itself is a placeholder. The acceptance criteria must provide the team with the right amount of information to support the level of effort (sizing estimate).

Pain Point

“We aren’t building the right things.”

Application of the C’s

Conversation: The Card is not a substitution for frequent conversations and check points throughout the hours and/or days that make up the sprint.

Pain Point

“We aren’t sure how to test the solution.”

Application of the C’s

Confirmation: The acceptance criteria and examples are not complete if the test team has question or needs clarification on how to test the successful story. The test team has to weigh in and engage fully throughout the story development life cycle. As a team, the acceptance criteria drives the scope of the testing.

Pain Point

“We aren’t sure if they captured everything or if there are gaps.”

Application of the C’s

Context: Provides the circumstances that form the setting for an event, statement, or idea. It is expressed in such a way that it can be fully understood and assessed.

One thing to keep in mind is that the user story itself is not the starting point for defining an agile solution, nor is it the end point. Many teams think that they can rely on knowledge of the business domain or process to come up with a list of what they want or need. Without context, you have no traceability, no way to reconcile, and no way to evaluate where there might be gaps in requirements.

In the cases where I was talking to teams that were frustrated with the user story, I could look at how they currently approach the backlog and immediately see the lack of context. The user story backlog can’t just be a collection of random pieces of features and functionality no matter how knowledgeable your product owners and subject matter experts might be. It’s not a lack of knowing your business, it’s just that people don’t walk around knowing their primary and secondary process flows or their rule families and dependencies across the process steps off the top of their heads. And even if they have this knowledge, it must be socialized at a high level so that the whole team is working from a shared understanding of the big picture.

Determining the context of the user stories means creating a skeleton, a framework, or a strawman that the user stories get attached to. The items in the backlog for a project must be related and have some context if your end goal is a cohesive solution. The exception is for a backlog that has random work requests such as a shared services team. In this case, the individual stories should have certain notes related to context.

Many agile teams start and end their elicitation process by brainstorming user stories. User stories are in the center of the diagram.

The questions and discussion around the context should start on the front end and from iteration zero all the way down to the acceptance criteria and examples. Each level reinforces and builds on previous identified impacts, constraints, risks, and assumptions.

While brainstorming is great for creative output, it won’t get you the whole story – only part of it. There are circumstances to be considered that tell how the story will be used in its production environment:

• What is the user’s work environment like?
• What will they be doing immediately before or immediately after the request in the story?
• Are there any parallels or dependencies to any other activities?
• What is the impact if this story is used out of context?

Adding the 4th C to Your 3 C’s Arsenal

How are you capturing context?

A tell-tale sign that you aren’t considering the context of your user stories is that there is no mapping or traceability of the stories. Be sure you can identify the following:

• feature that a user story addresses
• estimated weighted business value (BV) rating for that story
• percentage of business value that is addressed when you complete the story
• dependencies (Dep)
• total cost/benefit of the feature relative to other features (this is achieved by identifying the sum of the story points (SP) compared to the sum of the business value (BV))

These references will help determine the priorities and give you a baseline point of reference during planning. However, there should still be conversations before deciding the order to build and deploy your stories.

Make it a point to have a conversation with your team about where you are in your user story maturity. Perhaps you are already doing the 3 C’s and don’t know it, but, now, you need to focus in on the 4th C to really take your user stories to the next level of maturity.

What tools are you using to manage context?

Be sure to have the team address and agree on what tools to use and when the conversation about context will take place. The key here is to stay lean and use lean tools during your sprint. The 4th C’s intent is not to get back to heavy front-in documentation of requirements and design. Be sure to identify who has ownership for creating, socializing and leveraging the content of one or more of the following light-weight tools used for context:

• SMART Objective Worksheet
• Feature Map
• User Story Map
• Decomposition Diagrams
• Traceability Matrix

Who is responsible for tracking and tracing context?

Assign someone to track and trace the context who knows how and when to use all the tools listed above. Furthermore, he or she should know when to use the tools in the context of a lean and agile approach. Your team may not have a formally trained Agile Business Analyst, but I recommend using someone with the training, skills, and/or experience to facilitate the team’s need for lean requirements documentation with just enough to ensure a common understanding of the final solution. The right resource will know that the 4 C’s method is not just an exercise in filling out documentation; they should be able to recognize when context is necessary and how deep of a dive is needed.

Card ►

What is the need?

Conversation ►

What is essential for the solution to fulfill the need?

Confirmation ►

How will you recognize and measure success?

Context ►

How will the solution be used?
What are the dependencies?
What are the pre-conditions?
What are the post-conditions?

If You Don’t Consider Context (examples of what could go wrong)

These next few scenarios are prime examples of the impact of a user story developed without any context.

How will the solution be used?

A request for a screen was identified. The developers met the needs of the data and the behavior for the screen, but based the available white space of the screen size on their own 21″ monitors. However, the context in which the end user would use the screen was actually on a 4″ mobile device. If this isn’t discovered early, this could cause a lot of rework.

What are the dependencies?

A project was initiated to create an online system to renew driver’s licenses. The project depended on an existing database of drivers’ records. It was discovered that the customer database had duplicate records, i.e. Jamie L. Richmond and James Lee Richmond might have the same birthday and social security number. The new system would need to know the correct record. It became clear that duplicate records needed to be consolidated. Clerks at the DMV had ways to identify duplicates, but with a system being used in the context of a self-serve venue, the business rules and logic needed to be embedded in the new solution.

What are the pre-conditions?

A very common pre-condition is the login, validation, and verification of the person attempting to use the feature or functionality. The login is a separate user story from the activity, but the user story containing the activity must check to see that the pre-condition is met. In the short-term, some stories can be developed before their pre-condition stories but there must be a way to manage that the story does not get deployed without the high impact dependencies. In other words, you can develop out of order based on your sprint, but make sure you are reconciling the context and the relationship among the stories before deploying.

The key is that agile development and planning allow you to build things out of context, but the person helping manage the various aspects of the context must ensure that they are deployed based on their contextual dependencies.

What are the post-conditions?

A user story was created that impacts when a product requested by a customer can be shipped. The rule is related to things like alcohol and tobacco laws and shipping them out of state. This rule could be inserted in the code in many places, but it’s actually part of a larger rule family. Even if a state allows the shipping of these products, each state has supplemental rules, such as proof of age or a quantity limit. You can quickly see where a story board or map showing the relationships would ensure that partial implementation does not create a violation of the law because the post-condition was a false positive as a result of something being deployed out of context.

Look for Signs of Missing Context

In your retrospects and reviews, if you see how similar gaps in requirements are impacting your project or initiative, then the 4th C – knowing the Context – needs to be a part of your conversations and confirmations. Much of the context should be discovered during iteration zero, but any analyst knows that the discovery of context is iterative throughout the feature and user story elaboration and refinement. Also know that small enhancements or fixes can have big impacts. Just because it’s not a big initiative doesn’t mean attention to context and conversations about context don’t need to take place.

Even when a shared service team is engaged, they need to know the context in which their work will be used. A seasoned business analyst will know when the context needs to be general or concise and when there is enough risk or impact involved to do a more in-depth definition of context. A good agile analyst will know whether the context needs to be addressed at the feature level, the story level or both.

Understand how to elicit context and advance your skill set in developing user stories by taking our Advanced Agile User Story course.

Next time you are developing user stories, consider that the 3 C’s now has a complimentary 4th C – the Card, the Conversation, the Confirmation and the Context.

Thank you,

Jacqueline