Skip to content

Demystifying Agile – Rants of a Madman – Requirements and Acceptance Testing Should Not Be Akin To Pornography

March 31, 2012

There is a saying that was made famous by Potter Stewart, who at the time was an Associate Justice of the US Supreme Court, when he gave his definition of pornography.  It went something akin to: “I cannot tell you what pornography is, but I’ll know it when I see it.”  In the world of software the measurement of whether something meets the requirements or acceptance criteria can often match that very same definition.  When I’m being more politically correct I often share an example of the game “Bring me a rock.”

Bring me a rock.”  You run off and go find a rock and bring it back.

That’s not what I wanted.  I need it to be rounder.”  You run off and find one that is rounder in shape.

No.  It’s too big.  I need it smaller.”  You find a rounder, smaller rock and bring it back.

No I say!  It’s not flat enough!”  You find one like the latest rock but flatter.

Geez are you thick in the head?  I need to be able to hold it between my thumb and my first finger!”  You head out, find another, and try again.

Finally!  If you took any longer I’d be eligible for social security.  Still not quite right though.  See how it sinks when I throw it?  I need it to skip…”  Good grief…  You get the point though.

How many projects have you been on where the customer, product owner, or product manager has told you or your team something akin to “That’s not what I asked for; it’s wrong; it needs to be this other thing”?  How many projects have you been on where you didn’t have clear requirements or clear acceptance criteria?  How many times have you asked for clarification just to be told that you just don’t know how to read what is already there or that “it should just be obvious”?  You end up hating those who are not smart enough to tell you want they want and they think you couldn’t code your way out of a paper sack to save your own life.  Both sides point to the other as being “at fault”.

In traditional waterfall software development you often end up with a tome as thick as a phone book called the requirements document.  It often fails to articulate the requirements such that my mom could understand them (I use my mom understanding something as my personal acceptance criteria especially when it comes to technology and user interfaces).  This documentation, or lack thereof in many cases, also often spawns more questions than it is designed to answer in the first place.  Teams run off and then try to build this thing that is described and the authors get very annoyed when asked clarifying questions given how much time was put in to documenting the requirements in the first place.  Both sides get annoyed after a bit and then we end up waiting months to even years as a bulk of the team “goes dark” to interpret the masterpiece and create what it is they thought they were asked to deliver.  The problem is that until the development team comes out of the locked room, participating in great fanciful thoughts around being “almost done”, nobody really knows if this is what was requested in the first place.

Agile iterations help break this cycle of insanity in several ways. One advantage of the cadence provided by an Agile sprint (or iteration) is that every three weeks (or the cycle you picked) you have the sanity check of “Is this what you asked for?”  Even better, you have discrete requirements which are broken in to what Agilists call Stories.  Instead of writing a tome that nobody reads or understands, stories are short artifacts which focus on delivering experiences and outcomes that meet well defined exit criteria.  One of my favorite formats for a Story is based on the influences of Test Driven Development:

I as a <name the role>

Want to <what is it I want to do/ accomplish>

Such that <what is the benefit / outcome>

Acceptance criteria <this story is completed when these measurable conditions are met>

Some would contend that if you want to start with a quality up front initiative, one of the first places to start is with the stories and their acceptance criteria. 

Now there are many Agilists out there who will try to sell you a bag of goods as they point to the Agile Manifesto and claim in a very inclusive way that “Documentation is bad!”  They’ll use the phrase “Working software over comprehensive documentation” from the manifesto as an excuse to not to create required documentation.  Some will even use this excuse not to put enough effort in to Story cards to make them useful (note that these are probably the same guys who don’t put comments in any of their code either).  I always have to point out to them that the word “comprehensive” was used in the manifesto item vs. the word “all”.  If it is useful and helps save time in the long run then put it in the story card!

Agile iterations are also designed to foster communication amongst the team members.  Those who are working on the story should be in regular and as needed impromptu conversations with the author of the story to nail down ambiguities and to ensure mutual understanding.  Even better, those who are working on test plans and/or automated tests for a story should be working on these at the same time while collaborating with the same people.  No?  I’ve even seen some very high performing teams where the automation / unit tests are written before the code behind the story is written such that the acceptance criteria is truly well understood and can be part of a test harness leveraged in continuous build and integration environments (see this post for more on that example).

So here is my challenge to you at this point if you are adopting Agile and easing in to it (details in previous posts):

Requirements and acceptance criteria should never be a mystery to a team.  If your team’s stories and acceptance criteria remain vague until you see the story demo (or worst yet have entered in to acceptance testing at the end of the project) then your team might have a lot in common with Potter Stewart…

About this series:  I love Agile; I also hate Agile.  I love how it can free teams to truly delight customers while delivering high quality products on time.  I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size.  My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.

Advertisements

From → Agile, Quality, Software

2 Comments
  1. Kirk Augustin permalink

    Very good. Instead of making programming better and easier, what a lot of people have done is just added techo-babble to sound more sophisticated or knowledgeable in the arcane. The reality is that programmers enjoy programming so much that if left on their own, they will run off and create something totally useless, so they need some sort of methodology to keep them grounded in reality. And that requires the best possible description of how it is finally going to be used. Stories do that, so are good. But we should not make up new words. The reality is that good use descriptions are what is really called for. Story is not a good word to use.

  2. We have full PhD programs on the study of how to make software. But for some reason people think asking for what they want software to do is easy and a skill everyone has. They need to start adding this skill building into Business degree’s and people that want to ask for software to be built need to start treating it as a discipline that they study and work to improve.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: