Software Development

Agile requirements discovery: Tell me a story

Having trouble gathering agile requirements from a nontechnical client? Rick Freedman says you might consider asking for user stories. These stories, which are short and written in plain English, outline what tasks users plan to do when they sit down at the keyboard.

Discovering exactly what users, stakeholders, and sponsors want you to create is often the most difficult part of an IT project. Communication between IT experts and nontechnical clients can be fraught with misunderstanding and misinterpretation. As I discussed in previous columns, users often don't know what they want until they see it, and they frequently can't articulate their expectations in language that IT experts use to design systems.

Technicians often frame their requirements questions in technical language, such as, "Must it work in a browser?" or "How will the data be validated?" and clients may not have the technical background to respond to these questions. Users often explain their expectations in vague language, such as "fast" or "responsive," which lack the specificity designers need to develop solutions.

Volare Requirements Specification Template

The IT community has submitted many ideas to solve these problems. The Volare Requirements Specification Template, created by James and Suzanne Robertson, authors of the book Mastering the Requirements Process, is one example of a tool developed to aid system professionals in deriving user requirements. This template, which has gone through 14 versions since its inception, offers a thorough set of specification categories, from concrete components such as "Goals of the Project" and "Implementation Environment of the Current System" all the way to highly subjective ones such as "Cultural Requirements." The template also includes technical elements such as "Speed and Latency Requirements" and "Data Model."

I've often recommended the use of this template to students and clients I counsel, as it brings discipline and consistency to their requirements efforts. In my years of recommending and training IT professionals in its use, however, some of its limitations have become clear. Few clients will know what the terms "Speed and Latency Requirements" or "Data Model" mean, so expecting them to be able to define those expectations is an exercise in futility; also, expecting clients to define "cultural requirements" or "political requirements" borders on the hallucinatory. The expectation is that experienced IT professionals can elicit this information through clever questioning and facilitation, but, in my experience, the number of IT pros who have a deep understanding of cultural or political dynamics within an organization is, to be charitable, limited.

UML and Use Cases

Other methods of defining requirements, such as Unified Modeling Language (UML) and its associated Use Cases, use natural language and simple graphics to document user-described system interactions and activities. Use Case diagrams captured in UML can get quite complex when describing large systems. The result can be baffling and undecipherable to nontechnical users and managers.

User stories

Some agile proponents, such as Alistair Cockburn, advocate a Use Case model for documenting requirements in agile projects, but Mike Cohn, author of User Stories Applied, supports user requirements with even less formal structure. Cohn calls these short, pithy descriptions of a system capability or function "user stories."

The use of the word "story" is telling; rather than asking a user to describe the "speed and latency requirements" of a system, we ask them what tasks they plan to do when they sit down at the keyboard. In keeping with the "barely sufficient" concept of agile documentation, user stories are short and written in plain English as a simple narrative. So, for instance, a project sponsor asking us to develop an online job site would tell us the following stories about how different users might interact with their proposed system:

  • "As a jobseeker, I can search for jobs."
  • "As a company, I can post job openings."

From here, as in many other system development efforts, it's a matter of stepwise refinement and of digging incrementally deeper. The agile team may then ask the sponsor or user for more specificity on the jobseeker's actions, eliciting information such as the following:

  • "As a jobseeker, I will search for jobs by attributes like location, salary, title, company, and posting date."
  • "As a jobseeker, I will drill down to more info on selected jobs."
  • "As a jobseeker, I will learn more about the company posting the job."

One way to add detail to user stories is to ask the sponsor to describe their criteria for judging the system; how will they know if it works as expected? This technique, applied to each individual story, sets the agile team up with a good understanding of the broad boundaries of performance and quality the customer is expecting.

User stories used in agile environments have no formal structure. If the user community can visualize how they intend to use the system and describe that in simple English, the resulting stories give the agile team someplace to start. Since agile theory contends that users must see something before they can start to visualize the complete system in detail, starting with a simple set of stories kicks off the collaborative process of experimenting towards a solution.

As Cohn reminds us in his book, there's another reason for applying the user story technique -- it forces the customer to remain engaged throughout the process. While a huge, comprehensive requirements template like the Volare Spec can collect voluminous specifications up-front, it also enables the sponsor to look at requirements as an opening phase he can walk away from once "the requirements are done." Since the user story approach requires constant refinement and builds upon itself from prototype to prototype, there's no other option but engagement for the sponsor.

Conclusion

User stories connect with the philosophical threads of agile methods by reminding us that we don't need formal templates or special graphical languages to have a conversation with the customer about what they want. User stories reinforce the "barely sufficient" mindset that keeps us from being diverted into low-value administrative tasks. Most importantly, user stories help us stay engaged with the customer throughout the project, and require that the customer do so as well. The conversations that ensue from that collaboration are the core of agile engagement.

I've just grazed the tip of the iceberg regarding user stories. In future columns, I'll discuss using user stories to estimate the project, and explain how stories can be used to keep the sponsor informed and educated about the project status and progress.

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...

19 comments
johnfranks999
johnfranks999

Get the book I.T. WARS (Google to it). Very helpful on our projects and discovery process (referencing here the language barrier ref'd in the article). You may also like the author's blog, The Business-Technology Weave - again, can Google to it.

Dr Duke 2000
Dr Duke 2000

If the use case diagram gets too big - separate into packages. For presentation to users, stick with basics - don't use , , etc - most users don't understand them anyway.

angela
angela

Often the simple things work best What better way of engaging and learning from the end user than listening them? It seems obvious but would be so powerful!!!

a_vagga
a_vagga

Very informative. I would still like not to abolish the use of UML or other established methodologies of user requirement gathering ahd spec generation. Rather I would now want to club these 2 to make my job much more effective. Regards, Abhijit S. Vagga

Celeroo
Celeroo

Rick, You are right on as far as most, if not all, projects are concerned. This is a major issue, and, if I may summarize what you have nicely explained, the main problem with the solutions (templates, software, etc.) that help manage requirements is that they lack the collaboration and communication aspects combined with SIMPLICITY of the solution that makes it acceptable to both technical and non-technical audiences. What we have noticed is that the templates and documents get sent across in emails, etc., requirements clarified over phone calls and chat, and no single repository to easily manage all of that. And while software solutions tend to solve that aspect, as do (to some extent) the templates you pointed out, they either become way too complex or way too expensive. The complexity probably is needed in only 20% of the projects. The solutions need to have the flexibility to meet the needs of the mature Agile teams as well as of those that @anirbank2000 pointed out. In the end, if it is not simple, it will not be used by most teams. We have experienced all of what you pointed out and have launched a product, Celeroo Req 'n Spec, barely a couple of weeks ago to solve the needs of such teams. The power lies in its simplicity and flexibility to allow customers and development teams discuss any requirement or feature, while managing versions and changes and creating an automatic traceability matrix between the requirement and the detailed features written for each requirement. I would like to invite you to try the application at http://www.celeroo.com/reqnspec/requirements-management-software.html. I would certainly appreciate your insights vis-a-vis all the other templates, etc. that you have seen. Of course, there is a 15-day free trial for everyone and your readers can see if this helps them resolve any issues they might be facing. I do not want my response to be seen as a marketing ploy but given that it is such a major issue and we have launched a new solution recently on similar lines as this article, I wanted to put my two cents in...and certainly wouldn't mind getting a few dollars in return if people liked the application and saved thousands of dollars :-)

anirbank2000
anirbank2000

This is all fine, but the User Stories create a whole lot of complications for the Development team. Being in the business user's language they lack the clarity needed by the developer, and also this constant changes create more problems. So the formal requirement is still needed.

Triathlete1981
Triathlete1981

So, my company has this outdated, green screen ERP system that no longer fits our needs. Our COO, who runs the company, told me one day that he'd like to look at new systems. And that's all he told me, nothing more. Being in IT and only marginally involved operationally, I did not really know what our true business req'ts were. With just enough knowledge of ERP systems to say that new solutions for a company our size would cost about $250K, I tell him the costs along with the upgrade cost which is about $75K, though the upgrade would basically stink big ones. He says he's not scared of $250K but doesn't give me an exact budget to work with anyway. I did research online on how to evaluate new systems, and a lot of IT pros said to perform internal business analyses and talk to various users on what we really need and what our problems are. After doing a week of interviews, the COO told me I was not allowed to interview people as it took up too much of their time, although this was the only way to find out what our req'ts were. And if I couldn't handle searching myself, he'd find someone else who could. Now realizing he me incompetent, I say, no problem and I'll continue on my own. So, I started contacting ERP vendors and every one asked me what our needs are. I really don't know except generally speaking: inventory, shipping/receiving, reporting. I sit through dozens of demos, sometimes 2-3 hours long and narrow the number of possible solutions to 4. They each send me fairly accurate quotes, all from $220K to $270K, in the range I first stated. Our COO says fine, keep researching. I want to now schedule onsite visits with some of the vendors' customers to get a feel for how the implementation and usage is going. My COO says he can't let me leave the premises in case a fire breaks out. So, we're investing a quarter million in a company without doing proper due diligence. Without doing visits, he says I need to narrow the selection down to 2 possibles. My response is, since he won't let me visit vendors' references, let's bring in those 4 vendors to do demos with other people in the company which will help me narrow the vendors to 2. Plus, it's a good idea to get others involved as I only support the system but don't actually use it. He gives me the same old, too much time and if I can't handle it, he'll find someone who can. The latter part is a great morale booster by the way. I narrow it down to 2 vendors despite not knowing anything about our req'ts, not involding anyone else and not doing any visits, of which I'm fairly proud. I get more accurate numbers from the vendors and bring them to my COO, who says they're way too much (despite him saying months ago that $250K didn't scare him) and that the quotes need to be brought down. The vendors now bring down their costs to $180K and $195 with a firm written commitment to not go over this amount (economy, wow!). My COO mulls this over for a few days, without giving me any update on his thoughts. Then he calls me to his office last Thursday (Friday off) and says, "I talked to our current ERP people. Showed them the prices that we were willing to pay to replace them, and they knocked down their upgrade price to $50K. We're going with them." He does this all without telling me anything. It was his plan from the beginning to use those other quotes as leverage to squeeze out a lower upgrade price. The upgrade stinks big time and is almost useless and a waste of money. And, I wasted the last four months of my work life. God I love my job.

paul.simmons
paul.simmons

Not everyone in IT can take stories and translate them into specs but this is a good idea.

viweed
viweed

Apparently you do not know anything about Agile Methodology, nor about what it takes to develop a successful application. Where did you get the idea that the USERS do NOT know what the marketplace wants? BTW, if your developers cannot write technical specs based on storyboards, etc. FIRE them. It's what I would do... actually I would not have hired such incompetents in the first place. Hmmm. Are you doing your development in, let me guess, INDIAN??

des.blueberry
des.blueberry

@Triathlete1981 Great example of "real life" and how management and textbook are opposites. Having worked in many multi-national organisations, I can vouch for the fact that irrationality and expediency rules. One bit of advice. Document your meetings with the COO. Explore other avenues of political counterweight CFO or CRO (if you have one). If you are a public company get the project onto the agenda of the Audit committee (major or strategic projects).


Yeah, I know this all takes time and hassle from your day job, but sometimes you win!

Kam Guerra
Kam Guerra

"My COO says he can't let me leave the premises in case a fire breaks out." a) You're the only person who knows where the fire extinguisher is b) Hid the fire extinguisher as job security leverage c) The only person there who knows the number to 9-1-1

NotSoChiGuy
NotSoChiGuy

Gazing into the ChiGuy crystal ball, I see the following events unfolding: Angst over the upgrade reaches a boiling point. In order to placate the screaming masses, the COO delivers a sacrificial offering---YOU! With the COO at the helm, the company begins exploring a 'partnership' with a competitor. That partnership leads to an out-and-out sale, and the firm is closed. The COO is given a golden parachute as he is kicked out of the corporate door along with everyone else. The two most destructive types of holes in the universe are black and @$$. This guy seems to fit the definition of the latter---don't get sucked into his gravitational pull! Get the resume together, and start searching!

PMPsicle
PMPsicle

Hate to say it but you just learned an important lesson. As soon as he threatened you, you needed to make a decision. Was staying around going to be worth more than getting out? You decided to stay and in return you got a point on your resume. Now you need to put that point to work and go find another job. Your COO has proven that he works by threat. And you've proven that you will cave when he threatens. So now you have to call him on it. You have to leave and let him find someone else who can do the job. Or alternatively, you can stay. And the next time he says jump you have to say "how high?". After all, you've already shown him that your job is more important to you than your profession. Glen Ford, PMP http://www.trainingnow.ca http://apps.learningcreators.com/blog

Jcritch
Jcritch

Now you know why he did not want to involve other people. I guess you now know how he operates. Great resume item- researched possible ERP replacement.

CharlieSpencer
CharlieSpencer

'My COO says he can't let me leave the premises in case a fire breaks out." Geez, what does he do when you go on vacation? When do you get dental or doctor's appointments? What if you need car repairs? Your COO is clearly an idiot. You don't say what your company does, but would he tolerate another department head dropping a quarter of a million on a tool sight unseen? Does he buy his cars without taking test drives? I wouldn't wait for him to find someone else. Get your resume together, use vacation time to go to interviews, and let him try finding a replacement willing to work with your antiquated system.

cherylstukey
cherylstukey

I love it when ignorant people show their true colors. INDIAN? I suppose you were trying to imply that the developers were in India? They don't speak 'Indian' in India you ignoramous (and yes that is a made up word)! BTW a lot of users don't know what the marketplace wants nor do they know the difference between what they WANT and what it is they truly NEED. It's the responsibility of the requirements gatherer to know when this is the case. This approach is a good way to bridge that gap when this is the case.

CharlieSpencer
CharlieSpencer

but is using the phrase as a euphemism for having an IT emergency, right?

Triathlete1981
Triathlete1981

how does my boss being a retard mean i'm a retard?

Kam Guerra
Kam Guerra

If his boss can be a retard, then so can he.

Editor's Picks