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