It’s often said that one of the virtues (and challenges) of an organization adopting an agile methodology is that it will highlight existing dysfunctions. (The challenge being not to shoot the messenger.) One of the dysfunctions that typically, quickly surfaces is how user requirements can get overly complicated. In an environment that relies on written specifications that are “thrown over the wall” it’s the natural tendency of everyone involved to be as thorough as they can be. And who can blame them? In one respect, it’s their job to think of every contingency and bring all of their experience to bear. Working in a vacuum, it’s only natural to want to err on the side of caution.

Unfortunately, this all too often means that a requirement statement will take on a life of its own. As it evolves and gets fleshed out, the original reason or impetus for the requirement becomes clouded. It is barely retained through implication, if at all.

Allow me to illustrate… Let’s say we want to develop an application to help Little League coaches manage their teams and that one need is to be able to gather the e-mail addresses of the players’ parents, so that updates to the game calendar can be sent out. So, our Product Marketing Manager interviews one of the coaches and, among other requirements, writes down, “The system shall maintain a list of the e-mail addresses for the parent(s) of the players.”

This statement, among others, is handed off to a Business Analyst who does her part to design a series of forms and workflows around it. Bringing her experience to bear, the workflows she designs include having each parent self-register and then the system will send out a verification e-mail with an authentication code to be echoed back.

This workflow design is then handed over to a DBA. Bringing his experience to bear, he splits out the name into separate fields for first name, middle name, last name, and suffix. He also decides that, even though it isn’t explicitly specified, he’d better add a label field next to the e-mail address field to identify if it’s a work e-mail address, or a home e-mail address. (Somebody will surely ask for that later, and it’s much easier to make sure the e-mail addresses are properly identified from the get-go rather than somehow determine them later.)

Next, finally, the bundle is handed off to a programmer who brings her experience to bear. For her part, she embellishes things to include exhaustive validation checks, including a check for what constitutes proper e-mail address syntax, etc.

All of this turns out to be overkill, and the little league coaches are not impressed. In fact, having to chase after the parents to get them to each self-register actually puts more of a burden on a coach than letting him just enter the information directly. Also, the DBA’s embellishment of splitting out the name into four separate fields gets in the way when all they want to enter is “Jason’s dad”. And, the programmers addition of a validation check on the e-mail address is fine, but unnecessary, since if the e-mail address is typed in wrong, it’ll simply bounce.

And we haven’t even gotten to how much more complicated it will be for QA to test a system that includes round-trip workflows with numerous fields some of which are required and others optional, some of which are open and others restricted to certain values — when all the user wanted was a standard set of CRUD functions against a 2-column table.

So, the lesson here is that, in the name of doing a thorough job, everyone has a tendency to make more work for themselves, and to make more work for their associates downstream. This drastically increases the cost of implementing a requirement, which, in turn, means the return on investment (ROI) is drastically decreased. This is compounded by the opportunity cost of not working on something else that is just as important because too much time is being spend on the first requirement.

Agile teaches us to do two things to alleviate this problem. First and foremost, we communicate with each other verbally, in real time (in parallel), and preferably in person. This ensures that the original reason/impetus for the requirement (the value) is not lost on anyone.

Agile also teaches us to write value-driven “stories” rather than isolated requirement statements. The standard story template serves us well in this regard:

“As a (role), I want (need), so that (reason).”

Add to that an acceptance test in the standard GaWaTa form…

“And I’ll know it’s done when, Given (condition) And (condition), When (action), Then (criterion) And (criterion).”

…and you have a complete description of the requirement with a clear understanding of the value to be derived.

“As a little league coach, I want to keep a list of parents and their e-mail address so that I can use it to send out updates to the game schedule whenever it changes. I’ll know the requirement is met when, Given a name like “Johnny’s dad” paired with an e-mail address like “jdad@example.com”, and perhaps another pair like “Johnny’s mom”/”jmom@example.com”, when I add them to the database, then I’ll be able to later list them all out (in a form that’s ready to be copied and pasted into the To: field of an e-mail being composed), and/or update a single entry, and/or delete a single entry.”