My overview about user stories (“Agile requirements discovery: Tell me a story“) evoked quite a bit of commentary, some complementary, some not. As with all challenges to the traditional, waterfall-style approach to project management, the idea of abandoning the detailed, front-loaded requirements phase of a development effort in favor of a process based on informal user stories (recorded on a bunch of index cards and lacking all technical details) sticks in the throats of many experienced project managers and developers.

Let’s dig deeper into the concept of user stories and look at how this approach to understanding users’ expectations works in a real development effort.

The three Cs

If one of the stories you capture is, “As a jobseeker, I can search for jobs,” most developers will agree that this is not enough detail upon which to build a system. Ron Jeffries, one of the signatories of the Agile Manifesto, offers a nice alliterative description of the proper use of the user story in his article “Essential XP: Card, Conversation, Confirmation.” These three words are highly instructive.

While the simple statement of a user’s functional requirement (e.g., “As a jobseeker, I can search for jobs”) can be captured on an index card, the card alone is not the requirements statement; it requires the additional two elements of conversation and confirmation to have any meaning. As is true in all agile methodologies, the interaction between developers and users is critical. The statement of intended usage is the beginning, not the end, of the requirements conversation; without that conversation, the sentence recorded on a card is pretty useless.

We apply agile methodologies to avoid the errors and traps of traditional development methods. One of the most notorious of these traps is the “thrown over the wall” requirement, gathered up front and handed to the development team with the mandate to “go build this.” Agile developers believe that the most important element of a successful development effort is the user’s collaboration and that collaboration is best enforced by requiring ongoing conversation about the expectations for the system’s look, feel, and function. It’s within the ongoing conversation that the additional details required to create a working system, such as “A jobseeker can search for jobs by specialty” or “A jobseeker can log in as a guest or can register as a member,” can be fleshed out.

In this incremental process of adding details, the development team and the users can make decisions about which details are elaborations of the original story and which details may require their own stories. For instance, if membership is a key element of the end product (for instance, sites where users pay to gain access to job postings), the membership story may require enough additional details to elevate it to its own story, with its own ensuing card, conversation, and confirmation. The details that emerge in these conversations can often take the form of additional documentation, such as screen mockups and storyboards.

The confirmation element tells us that it’s the user who defines how the system’s functionality will be tested. In practice, the confirmation part of the customer collaboration is also where many of the details emerge. If, as we noted earlier, our project is a membership site where jobseekers pay for the privilege of reviewing listings, then the obvious question is: How do members pay? This leads us to conclude that we’ll need to test for credit card acceptance and perhaps PayPal, check, debit, or other types of transactions by which members will sign up.

This incremental conversation with the client, in which we lead the customer down the path of specifying the details of their expectations, is the art of agile development. As I noted earlier, agile development is an effort to avoid previous errors in development, one of which is the programmer-created test. Developers often specify tests that their systems pass, only to see those systems explode on impact with real users. This is not because developers are trying to game the system; it results from the fact that developers will test the feature they programmed, which may not match the use case that the user envisioned.

User role modeling

Who, exactly, are we collaborating with when we collaborate with users to develop these stories? In our hypothetical membership job site, we’re probably not going to have access to actual members, because the site isn’t live yet, and those members don’t exist. In this circumstance, we apply a technique known as “user role modeling.” In our example, we clearly have both the job seeker and the job poster; within each of these categories, we may have many different user roles, from the internal HR employee posting a job to the external recruiter and from the casual job browser to the unemployed member seeking any gainful employment.

Part of our job as agile developers is to help the client sort out the possible roles that users might play during their use of the proposed system, and to see the expected functions and stories from their viewpoint. Again, this exercise of visualizing the potential users of the system and their possible different expectations goes a long way towards unearthing the details required to develop a useful system.


One key point about working with user stories is that you must manage the story’s size. In the agile community, long stories that are unwieldy and difficult to estimate are called “epics” and are to be avoided. We want stories that are short and concise enough to enable the team to estimate the effort required to develop them, and overly detailed epics don’t grant us this ability. This attribute of user stories (i.e., the ability for the story’s associated development effort to be estimated) is key to the stories’ usefulness.

As we’ll see in future columns, these user stories will be prioritized and selected for development iterations when we’re ready to start development, and the ability to estimate their duration of effort enables us to decide if they belong in the current iteration or a subsequent one.

A starting point

Many developers see the usefulness of a story-based approach as requirements definition, but fear that it can’t possibly elicit the complete set of requirements needed to guide them towards a full vision of the system. The user story is just the starting point; by delving into the possible users of the system by having deep conversations about those users’ expectations, and by determining in detail the types of acceptance tests that would validate our development efforts, we can create a highly specific picture of exactly what we’re developing.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track.
Automatically sign up today!