There are no ‘requirements’ in agile!!

It surprises me to hear staunch agile followers still using the word “requirement”.  When questioned, they will respond, “…a story is a requirement.”  It isn’t.  Early in my reading of agile I came across this analysis of the word “requirements”:

“Software development has been steered wrong by the word “requirement”, defined in the dictionary as “something mandatory or obligatory.”  The word carries a connotation of absolutism and permanence, inhibitors to embracing change.  And the word “requirements” is just plain wrong.  Out of one thousand pages of “requirements”, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system.  So what were the other 80%?  Not “requirements”; they weren’t really mandatory or obligatory.”

(I am leaving out the reference to this quote so there is no bias.  If you don’t recognize the quote or the style of writing it is worth your time trying to find the source.)

In agile, instead of requirements you have user stories.  It takes quite some time to make the transition from requirements to stories.  To me, after reading the previous quote, Mike Cohn’s statement about stories was essential: “A story is a reminder to have a conversation.”  Of course it is difficult to create stories.  Mike Cohn has written a book about that.

Alas, “requirements” are even more entrenched in the software testing world.  Interestingly, in 1999, a great tester wrote a wonderful article about requirements.  In that he wrote:

There are at least four alleged truisms about testing a product against requirements. Most  of the testing textbooks on my bookshelf promote these principles, and each principle reflects some truth about the dynamics of testing.

  1. Without stated requirements, no testing is possible.
  2. A software product must satisfy its stated requirements.
  3. All test cases should be traceable to one or more stated requirements, and vice  versa.
  4. Requirements must be stated in testable terms.

When we think in terms of risk, however, I believe a richer set of ideas emerges.

(I am again leaving out the source to avoid bias.  You can easily search for the pdf article. )

If you haven’t realized it by now, keep in mind there are no “requirements” in waterfall!!

In the “waterfall” world (pre-agile), there has been some good work on “requirements”.  Making the transition from that world to a world with “user stories” leaves many questions open.  I still believe, with a good agile coach, and a good testing coach, teams are better off making that transition.  However, writing stories and trying to determine what might go wrong can require a lot of work.


2 thoughts on “There are no ‘requirements’ in agile!!

  1. Yes and No. You make a good point about the value of stories in the agile process. I also agree that the term “requirement” overloaded – clearly some aspects of a system are more required than others and the english language could do with some refinement in this area. I also agree that many classical “requirements” are in fact statements about desirable qualities or attributes and the some in the “would be nice” category can and should be used as a part of a trade-off analysis done in agile terms by repeated prioritization of the backlog.

    However, I think your phrasing risks being misunderstood. I think that there are a subset of items worth writing down as true requirements – even within an agile project. These are just those elements that must be done and without which you have no product.

    I saw a horrible crash and burn in a project where agile methods and thinking much as you appear to outline was misapplied and led to a key system feature – the need for access control – being postponed to be done in a “later” sprint. Whereas it was, in that context, a key architectural element. Not recognizing what the “big-rocks” are, around which the rest of the system needs to be designed can be catastrophically expensive.

    So they way I would put it is that within an agile project of any size and commercial investment make sure you spend time with your most experienced developers considering the architecturally significant elements up front and record these to help communicate with the rest of the team. Think of this as sprint zero. It is not Big Design Up Front (BDUF) but the creation of a common sense based shared architectural framework.

Leave a Reply

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

You are commenting using your 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