Tech & Work

User stories: The starting point in agile development

Rick Freedman explains how user stories can help agile developers understand users' expectations. He also discusses the three Cs, user role modeling, and epic stories.

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.

Epics

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!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

21 comments
andreweast
andreweast

Back at under-grad I remember being told "the first student to start writing code is always the last to finish". Surely if you dont take a view of the whole requirement at the start you run the risk of the finding that the work you did early is incompatible with the requirement revealed at the end.

Dr Duke 2000
Dr Duke 2000

How does this differ from use case analysis? Identify the use cases in the subject business process = Card. Working with the user or a SME, develop textual descriptions of the essential scenarios = Conversation. Review with the appropriate stakeholders = Confirm.

peter.stevens
peter.stevens

Epics are not be avoided. They are simply high level stories, which are useful at the road map phase. As you get closer to implementing them, you need to break them down into smaller pieces. These smaller stories are small enough that you can estimate them and define acceptance criteria for them. These stories can also be prioritized for implementation. Low priority stories might get dropped or postponed in order to achieve a release date. You may have to break the stories down yet again, to make them small enough to implement in a single sprint. The epic is completed when all the (prioritized) individual stories which comprise the epic have been implemented.

dogknees
dogknees

Given this approach, when do the "epics" get included in the system design? One of my pet peeves is the dumbing down of software. I don't want simple, I want deep and rich functionality. I'm happy to learn, but for a start, I'm keen to know how you meet the hard requirements.

Tony Hopkinson
Tony Hopkinson

"fear that it can?t possibly elicit the complete set of requirements needed to guide them towards a full vision of the system." And waterfall can? Even if it were true that you did, unless it's something extremely static, like say power plant control, it is most definitely not going to be true when you finished. Waterfall's failure was that you have do know everything before you started and that change of any description was resisted due to cost, so you ended up late, over budget and with a product that was probably no longer fit for purpose. Couple that with underbidding to get the job, on the basis that the real money would be made in the 'maintenance' phase, and you ended up with low quality mis-specified crap. If you want (and you should !) iterative development MoSCoW and Spiral have been about for ages. Agile has one benefit over other methodologies, you can (if you are doing it properly) re-priorititise your allocated resource, based on a change to your initial requirements, however those changes were triggered. If that is not what you are doing all you have is QAD with some different BS dogma. Write this down somewhere in big letters. We do not make software to give the customer what they want. We write sofware to make a profit satisfying the customer's needs. User stories, corporate fairy story, would be more accurate.

Tony Hopkinson
Tony Hopkinson

Implementing requirements changes them. The longer the delay between analysis and implementation the more surprises you get. I've seen projects where the aproach your tutor implies would work, somewhere it would sort of, and some where it would and did fail horribly. I got given a requirement once, an all singing all dancing predictive control system for feeding a manfuacturing process. Initial estimate was it would cost a fortune, something like six months effort, changes all over the place and a huge set of risks. I did a month's work, put in step 1, projected savings were 200K a year.... So by doing what he wanted, intead of what he thought he wanted I saved them a 100k give or take a quid, in the estimated original project lifecycle.... That other five months were spent doing things with a greater ROI from where they were now, not then. Four assumptions in the know everything before you start approach. They know what they want. You understand what they say they want. They understand that what you say they want is what they thought they said they wanted. None of that is going to change. Best of luck with that 'idea'. This is why you shoouldn't be allowed to teach IT, if you haven't done it.

Tony Hopkinson
Tony Hopkinson

as a Calvinist scripture differs from a Catholic one. In ways that are critically important to believers, dogma replaces reason.

Tony Hopkinson
Tony Hopkinson

Do as much of the known as you can in small modular steps, that minimise rework if you got it wrong. Decouple. An Epic is just over-documented RAD.

sclutner
sclutner

Well said...."Write this down somewhere in big letters. We do not make software to give the customer what they want. We write sofware to make a profit satisfying the customer's needs." That is why we have Business Analysts. Sandra Yukon, Canada

pscjskirk
pscjskirk

Tony you have hit the nail on the head. I have seen many projects fail and where hundreds of thousands of dollars spent where a rigid, upfront detailed analysis is done and where by the time the actual coding starts, the clients requirements have changed, and are now bogged down with change control requests. Also, I have seen projects where upon completion the client's needs have changed, and thus never end up using the product once completed.

bergenfx
bergenfx

Take a proven, effective tool, model or technique; rename it, change some of the terminology, put a nice ribbon on it and you now have the recognition for creating something "original." It seems to be done over and over again in IT. I think this still belongs to Ivar.

dogknees
dogknees

Doesn't sound a lot different to traditional top-down design. Keep breaking things down until they make sense, then implement! I appreciate the differences, but in the case of complex apps and problems, it seems very similar. I tend to think in terms of large apps like Photoshop or a compiler when I look at this stuff to try and get a feel for how the different methodologies compare. They all work fine for the trivial 2 screens and three report type things, it's the big jobs that really demonstrate the power or otherwise of a methodology.

janhct
janhct

Surely, when we visit the doctor our purpose is to find resolution to a problem - NOT to help make the doctor profitable! Profitability is a measure of how well we meet customer needs. Customer needs satisfaction is NEVER a measure of how profitable we are as a business. Let's put the cart in the right place - please!

Tony Hopkinson
Tony Hopkinson

Business Analysts analyse the customer's business. I've seen more than a few cripple a project concentrating on some point that provides a trivial ROI, or near scuppers a potential oppportunity with a much greater one. It's the difference between customer focused, and customer led. Software development is a huge investment, so you reduce your exposure, spread your bets. Concentrate on the core revenue stream, not expend the entire budget because one customer you just talked to said he really liked purple.

Tony Hopkinson
Tony Hopkinson

Like finding an honest politician that. It's a near constant in IT systems, that quest for the "one right way", that any dumbass can use. There is no one right way, there is no one template that will work for everything. Commonality is generally misleading. Rule one the creation or change of any complex system. If you don't know why you are guessing. A lot of the time you have to guess, if you know why your guesses can be educated. I'm p*ss tired of an argument that basically amounts use this calculator so you don't need to know arithmetic. That's for people who don't know that 2 + 2 = 22, means + is &

Tony Hopkinson
Tony Hopkinson

A good process will help good people not miss things. Any process held up as "This is the way to do it", is a get out of jail free card for numpties. Worse still it's often used as an excuse for hiring them. Agile isn't about requirements gathering anyway. It's about analysing them in terms of business priority. That's as much the supplier's as it is the customer's. What they want is irrelevant if it can't be done, will stop something more important from being done, or cost more than they are prepared to pay. That's where Agile is, you can use use cases in any development lifecycle. Even waterfall is iterative in that respect.

bergenfx
bergenfx

In the context set in this thread by Robert Greiner where he said, "How does this differ from use case analysis?" ... I guess it depends on what your standards for "proven" are, Tony. Certainly, I don't know where you apply the rigor to something like use cases, but I, and many others, have found (or witnessed) use cases to be an effective method for gathering requirements. Okay, I will withdraw "proven." In any event I agree with Mr Greiner that what the article presents is a repackaging of Ivar Jacobsen's use cases, regardless of your point that it is religious dogma, or mine that it is a theft to pretend at some original innovation.

Tony Hopkinson
Tony Hopkinson

Not one thing in that article that said Agile to me, the junkie jitter that is QAD, I saw that, and it's a proven failure.

Tony Hopkinson
Tony Hopkinson

as it was with RAD/QAD, is you get really bogged down at the UI level. Photoshop loads an object from a file into memory, and lets you perform operations on it. Ten weeks later you definitely decided on the menu captions.... Six months later have the image operations are buggy mis-implemented and slow. But the colours and the text are so great, your customer starts selling it..... Chuck in the cookie cutter default of putting 'business logic' directly in an click event... Err Hello.....

Tony Hopkinson
Tony Hopkinson

You aren't working for the patient or the doctor. You are working for Tongue Depressors Inc. That means sterile smooth wooden sticks that fit in a patients mouth. The ones with a built in torch, mobile phone and stethoscope that come in 42 flavours, won't make a profit....

Editor's Picks