I've been blogging lately about a couple of topics pertaining to 'agile' methods. Along those lines, I wanted to consider one suggested practice that I think is worth reflecting on, that is; the treatment of NFRs (non-functional requirements) as stories.
Let's draw back for a moment. Regardless of process approach, be it traditional or agile, poor treatment of NFRs is one of the highest risk areas in IT delivery. For anyone who has been involved in even a half-way serious type of project, lack of adequate NFR consideration will royally bite you in the bum. In my experience, it is probably the single biggest cause of lost sleep, likely I suspect accounting for the highest rate of ulcers for project & program managers. This applies to stakeholders at all levels, from project managers to executives. Executives as they realise in horror that the $70 million integration project due to go into production in 2 months time is behind and is not scaling according to plan and the business is looking for a release date or that the production system is down periodically for long spells due to scaling issues.
Many stressful roads lead back to NFRs and if the NFR horse has bolted on your project, get ready for some serious stress. That said, let me get back to the point of this post, NFRs as stories.
So, I'd like to challenge one of the sacred cows for some in the agile community; namely that 'everything is a story', including NFRs.
A number of blog posts argue for representing NFRs as stories, including this one. Not everyone in the agile community agrees. The excellent Scott Selhurst blog is a notable example of extremely balanced thinking in that regard. Tom and kai Gilb have a lot to say on the matter here irrespective of whether you're in traditional or agile settings or a mix.
Let's get a definition or two out there, so we're on the same page. Firstly what is an NFR? I will take the definition I first spotted in the 'HP Fusion' process oh about 18 or so years ago, that is we have basically two types of NFRs; Qualities and Constraints. Qualities are generally very clearly measurable and represent things like performance, uptime, data load etc, the classic 'ilities'. Qualities will tend to be associated with strands of functionality or with the system as a whole. Constraints tend to be exactly that, statements of constraint, for instance 'we must support IE 6' (at VisibleThread this particular one pains me considering the variations on service pack OS etc. but as we do have customers on IE 6 we need to satisfy this constraint). An example of a second constraint is: 'Must have a legal disclaimer on every page of the web interface' or 'we must code in Java on JDK version x.y'
You may not agree with the qualities or constraint delineation or have differing views but that's fine, work with me, whatever you choose to call them, most people agree that both styles of NFR exist, regardless of your definition or terminology.
Let me offer a few reasons for why agile analysts & team members should consider avoiding representing NFRs as stories.
-
Communication: NFRs often have a heavier impact than stories on core design foundations. Ask any tech architect or design lead for war stories on challenged projects they know and you are highly likely to be able to attribute the issue to lack of ability to satisfy one or more NFR as it's root cause. Therefore the act of calling out NFRs as something that is not a story is of immense value from a communication standpoint. As an architect seeing a clear delineation of NFRs (particularly the qualities) from stories helps identify incompleteness.
-
Cross-cutting scope: NFRs tend to come in two broad 'namespaces', those that apply universally across the project and those that may be associated with 1 or more strands of functionality, (a story in Agile-land). Handling both types of NFRs as stories does not easily allow us to map 1 NFR to multiple stories
-
Elicitation: NFRs are by their nature, the most difficult class of requirements to elicit. Having explicit categorization and expectation that not only will they exist, but that they are measurable and verifiable forces serious questions to be addressed upfront in iteration-0. By forcing a clarification of measures early in the process around NFRs such as security or scalability, key design and architecture inputs may adjust trajectory
-
Quality type NFRs are assertions with properties: NFRs are not functional in nature, stories are a functional artifact. Whilst it can be a useful device to use a story persona as a way to drive elicitation of NFRs, in normal complex systems where you need to put in multiple additional associated attributes; boundary values, max, min, mean, load etc., a tabular format tends to be more comfortable for people to read & document.
-
Testing: Having 1 NFR, particularly Quality oriented NFRs, represented in tabular fashion with each row outlining testable measures for instance, leads to a better ability to conduct test planning. It also means that we can incrementally knock off specific rows as part of particular sprints, yet have the more general NFR in place so it's pervasive and front of mind. Even the best intentioned team members may forget the NFR obligation unless it's kept front of mind.
-
NFR Lifecycle: Non-trivial NFRs in many cases can affect multiple sprints and have a life-cycle that lasts far longer than a 2 week sprint. Artificially closing them and re-opening them to suit sprint management is not following a principle I try to stick with, that of 'common sense'.
Finally, the agile manifesto really says nothing about NFRs having to be represented as stories. That particular idea is really a vestige of specific agile methods. The true spirit of agile is as much about common sense and 'fit for purpose' as anything else. So, don't be too afraid to stand up and say no to NFRs as stories.
Of course, if you find that NFRs as stories work for your context, excellent. It's just that in my experience, it's really pushing a square peg into a round hole, when we could just as easily fit a square peg into a square hole!