Agile Non-Functional Requirements
Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint. See one way (that is working) for managing non-functional requirements with an agile team.
Product Backlog Stories
Every article* I can remember reading that explains how to manage a product backlog talks about user stories. Those articles are necessary, but not sufficient . You’ll create better products by developing them from the outside-in, with a user-centric point of view.
*One loophole – scheduling refactoring (or the payback of technical debt). A lot of articles talk about the need to do this, and refactoring is pretty much the opposite of a user story, since by definition, refactoring improves the software without introducing new capabilities. The best idea I’ve come across for incorporating refactoring as part of a sprint is to write a user story, with the system as the user, and the lead architect / developer as the primary stakeholder. This actually works really well, but it works by treating the work as a user story.
Atomicity
What is really important, when scheduling sprints (or releases, if you are not doing scrum) is that you are scheduling solutions to atomic, measureable, valuable problems. Atomicity is the reason for breaking epics (really big stories) up into smaller stories. It is also important that you communicate them unambiguously. That might mean writing user stories or writing use cases instead of user stories, when things are complicated.
The problem is, not every atomic requirement can be represented with a user story. Some things that must be, are not stories.
Non-Functional Requirements
Non-functional requirements always seem to be under-emphasized when writing requirements. The Twitter fail whale has become famous, because twitter could not scale to meet the demands of a rapidly growing user base. Maybe the Twitter team planned for scalability, but demand simply outstripped it. Or maybe they failed to plan for it. Either way, they failed to meet the non-functional requirements of supporting the growth that they did have. (Un)Luckily, this type of problem self-corrects. Scaling failures drive away users, reducing the need to scale, until balance is achieved.
Product managers and business analysts tend to neglect non-functional requirements. Unfortunately, this is especially true when managing with a focus on users and their goals. Not because goals don’t drive non-functional requirements – they do. I believe this has happened because historically, non-functional requirements were treated as an after-thought. In reality, they are explicitly driven by goals. I proposed an equal rights amendment to the structured requirements domain model almost three years ago. In short, it explicitly calls out the relationship between goals and non-functional requirements.
Agile Non-Functional Requirements
Getting non-functional requirements into your sprint planning is actually not that hard. You only have to make two tiny adjustments to get from the waterfall world to the agile world.
The first adjusment is that you have to treat non-functional requirements incrementally. Non-functional requirements often affect all of the other requirements – so they seem massive and unweildy. You have to decompose them. Consider the platform-compatibility requirements for a web application. You may have to support IE6,7,8; Safari on Windows, Safari on OS X, and Firefox on Windows XP and Vista. That could be incredibly daunting. So break it down. Your first group of users (key persona) are primarily Firefox/XP users. So the first platform you support is that one. The next big platform for your persona group is Safari on OS X. Add support for that next without breaking the previous support for FF/XP. With each release, you add a platform (or two, or none). You are conspicuoulsy addressing the needs of your target users. The key is that once support is added for a platform, all future development is required to “not break it.”
Each non-functional requirement is cumulative. This is the second adjustment. All development, once a non-functional requirement is in place, must continue to honor it. You wouldn’t break a previously released capability (functional requirement), so don’t break a non-functional requirement. You have to determine, in each sprint, if additional functionality is more important than additional platform support. And add in the platforms as they become the most important “next things to do.” In waterfall projects, I’ve seen many teams break and re-break platform support throughout the development process, with the knowledge that it only has to work “at the end.” Include platform-specific support in your continuous integration tests.
You have a launch event coming up in six weeks. You have an established user base. You’re also developing a key new set of capabilities for your product that you believe will be a big hit and drive significant growth for your product. You have a small group of people in a private beta, providing you with feedback about the new development. If you believe the launch will cause your customer base to double very quickly (maybe over a month), how do you plan for that? This is a serious scalability non-functional requirement.
Break the non-functional requirement up into cumulative requirements. Assuming your plan is to add 10,000 users “at once” – have your implementation team brainstorm what that could/would mean for the system. [Also, make sure you coordinate with your community manager and marketing folks, both to validate the anticipated growth, and to device any contingency strategies in advance.] After talking with your development team, perhaps you learn that “at once” is a nuanced proposition. Literally at once is very bad. Spread out over a few days, not so bad. OK – you can deal with this too.
Imagine you already have the following non-functional requirements in place:
- The system must be available 24/7, with no more than one hour of down time per day, and no more than one outage per day.
- The system must respond in under 2 seconds for >95% of uses [ in key user story].
- The system must respond in under 20 seconds for 100% of uses [in same key user story].
Based on what we’ve said above, these non-functional requirements must not be broken. They essentially define the acceptance criteria for our scalability requirements.
Consider the following as the non-functional requirements that must be deployed by the time of launch (six weeks, or three releases from now):
- The system must support 10,000 additional users added in the month following SXSW.
- The system must support 500 new users signing up and initiating [troublesome user story] within the same hour.
Your dev team does not really know exactly what needs to be done – they just know that the current solution won’t scale – it barely meets the existing non-functional requirements. They propose a couple redesigns that may get the job done. But they point out the need to actually test that the designs work. Schedule the following for the first release:
- The system must support 100 additional private beta users.
- The additional users will all have [troublesome user story] initiated within the same hour.
The second one is really a pragmatic solution – artificially creating a spike in demand, to test out the scalability of the new code. From that data, we can determine what we need to do to hit 10,000 additional users, and to support 500 concurrent [troublesome user story] instances. By managing expectations of the new users (that you’re queuing them up to test scalability), you can get the data you need. And you have a couple more iterations to improve if needed.
As a benefit, you get to completely avoid the fail whale. The other half of this is making sure you can constrain the rate of new-user sign-ups. Work with your community manager and marketer to make sure you position this effectively. You are creating scarcity, which may increase demand. A crashed server won’t. If your team can’t support 10,000 in time for the launch, plan on 2,500.
Conclusion
You can plan and schedule more than just user stories. And your product will be better for it. Give those non-functional requirements a chance.
February 10th, 2009 at 10:20 am
I like to attach the nonfunctional requirements to user stories. If you’re using index cards for user stories, you include acceptance criteria underneath the natural language description of the story. These acceptance criteria express the nonfunctional requirements.
And you’re right that you can spike or iterate on the stringency of the nonfunctional requirements. It’s very much like basing iterations on constraint-based use case versions.
February 10th, 2009 at 10:52 am
Thanks Roger! I agree when the context of the non-functional requirement is scoped to the single story, then it really is an acceptance criterion. But too many non-functional requirements affect all stories (support screen readers, scale to 100 concurrent users, be PCI compliant, encrypt traffic, etc). I guess I’m trying to call out the difference between “verify that [story operates within parameter X]” and “all stories must operate within parameter X.”
February 10th, 2009 at 11:18 am
One of the ways you can iterate is by relaxing the nonfunctional requirements for a subset of the user stories, even if those nonfunctional requirements will apply to all of the user stories as the product matures.
February 10th, 2009 at 3:06 pm
From your description of the scope of the impact of non-functional requirements, they sound like “cross-cutting concerns.” Aspect-oriented programming (AOP) was developed to deal with cross-cutting concerns.
AOP works by intercepting interobject messaging doing some processing, and then sending the message to the original target object. It’s a system of sideband consumption.
You can use it as a means of extending your testing budget. To do this, you could code the core, and never change it. Instead, when you need it to change, you would build the change as an aspect. Since you didn’t change the core code, you don’t have to do regression on it. You might still do that until you are convinced, but most of the testing would be focused on the new code.
In terms of non-functional requirements (NFR), you would write your core at some level of “how well”. Then, when you wanted to increase your “how well” by some factor, you would write an aspect to do that. It wouldn’t effect the full scope of the non-functional requirement. It would effect only some small portion. You could then write another aspect for the next small portion. There is no need to break the whole thing, or to have the whole thing comply with a single metric NFR.
There might even be a business case for tiered compliance with the NFR. Sure, it’s nice if everything is operating on the same NFR levels, but it’s more important that the premium functionality meets it, or maybe the base functionality depending on your pricing scheme, and segmentation.
It might sound like a nightmare, but your NFRs would be encapsulated in an AOP approach where they are spread throughout your code today.
February 10th, 2009 at 3:34 pm
Agile Non-Functional Requirements http://tinyurl.com/bkk5az
February 10th, 2009 at 4:09 pm
RT @sehlhorst: Agile Non-Functional Requirements http://tinyurl.com/bkk5az new Tyner Blain article. prv link was broken, sorry!
February 10th, 2009 at 4:23 pm
New blog post by @sehlhorst on how to be agile with nonfunctional requirements. http://tr.im/fm6v
February 11th, 2009 at 2:52 am
I can’t say I fully agree with approach of adding one or a couple of non-functional requirements to each sprint. To keep the example with browsers, I would definitely think from the very beginning that application should support all target browsers. Win/OS X platform it’s a bit easier since capabilities are pretty similar. However if you think of having a site accessed from mobile devices too it all becomes tricky. If you base mainly on javascript, well, it won’t work on many terminals to throw just one example.
Pretty much the same is with performance-related non-functional requirements. Let’s say our goal is 20k requests per hour (whatever a request is – it doesn’t matter). At the moment application at the peak gets about 7,5k requests. If we put our milestones at 10k, 12,5k, 15k, 17,5k and finally at 20k for each consecutive sprint we risk that our current architecture will die in the middle of the march and whole work was useless. I would rather spend some effort in one of early sprints (possibly the very first) or at the beginning of a project to do extensive load testing and learn how far current performance can be pushed. If results weren’t satisfactory I would start working on major changes enabling performance improvement from the beginning (hopefully the second iteration) instead of somewhere in the middle of process.
Non-functional requirements are always tricky to deal with, no matter if your project is done agile-way or you’re waterfall zealot (are there any of them still?) because they’re hard to pack into frames we use for functional requirements.
February 11th, 2009 at 8:09 am
Bookmarked… Agile Non-Functional Requirements (Implemented as User Stories) http://tinyurl.com/bkk5az
February 11th, 2009 at 2:24 pm
rt @sehlhorst Agile Non-Functional Requirements http://tinyurl.com/bkk5az new Tyner Blain article.
February 12th, 2009 at 12:08 pm
[...] mit zwei Artikeln, die sich mit dem Product Backlog befassen. Hier geht es einmal darum, wie sich Non-Functional Requirements praktisch mit Agilen Methoden managen lassen, denn diese passen normalerweise nicht sonderlich gut in irgendwelche User Stories. Die Idee ist [...]
February 13th, 2009 at 9:21 pm
New Tyner Blain blog entry. Scott suggests incrementally making nonfunctional requirements more stringent. Great idea :-) http://tr.im/g5hj
February 14th, 2009 at 11:01 am
[...] Agile Non-Functional Requirements | Tyner Blain Addressing non-functional requirements in Agile development (tags: agile development) [...]
June 16th, 2010 at 11:49 pm
Late to the party, but the Cranky PM likes…
June 17th, 2010 at 4:46 am
Just a follow-up regarding nonfunctional requirements and whether they apply to the entire system or just a subset of user stories. Let’s take one of the examples:
“The system must be available 24/7, with no more than one hour of down time per day, and no more than one outage per day.”
When you think about it, this availability requirement likely shouldn’t apply to all – or even most – of the user stories of the system. Likely, there is system functionality for which it would be acceptable if it weren’t available more than one hour per day.
For example, imagine it’s possible for the user to rename a system configuration profile. Would it really be a significant problem if this functionality were not available for an entire day? Maybe, but maybe not.
As a general rule, a product manager should treat a system-wide nonfunctional requirement with skepticism and probe to determine the subset of user stories to which it applies.
June 20th, 2010 at 7:36 am
Wow – some great conversation here that I haven’t participated in – my bad!
@Pawel – There’s value in drawing a distinction between “when do we need it?” and “when do we build it?” when expressing more is better non-functional requirements. As a former code-slinger, for your “increasing support for # of requests” example, I agree with your inclination to build the initial solution such that it can support all of them. However, I also appreciate the trust that is implicit in having the needs expressed to me in priority order, leaving the implementation sequence up to me – so that I can choose to build a solution however.
When I put my agile hat on, there is really clear guidance to only build “just enough” – satisficing the needs of the moment (or of the iteration). This can be really tough as a developer, where the costs of discarding an earlier implementation are very visible, but the benefits of doing so are often hidden (from development). Here’s how I think about it.
Think about the model that bugs cost 10X to fix in the field (versus QA), and 10x to fix in QA (versus dev), 10x to fix in dev (versus design), and 10x to fix in requirements (versus design). This is true not just because of the cost of change, but because of the opportunity cost of change. The same model applies to capturing value. Delaying a properly prioritized requirement (story) to implement the “full solution” of a more is better non-functional requirement follows a comparable cost curve. The cost of refactoring is far lower than the cost of lost opportunity of delaying the other, valuable functionality.
Completely agree about the trickiness of this!
June 20th, 2010 at 7:37 am
@Cranky – thanks for the props!
June 20th, 2010 at 7:44 am
@Roger –
GREAT point. A particular non-functional requirement does not necessarily apply to all of the stories. Your system availability requirement is a fantastic example.
I haven’t done the math, but I think the bias is towards applicability to “most stories” for examples like this one. Most stories will be end-user stories (versus other stakeholders like sysadmins). So uptime requirements will tend to be applied to most stories. I’m basing this purely on hazy memories of past projects, and a quick view at a current project.
Other non-functional requirements (like platform support), will also apply to “most stories”, again, because most stories bias towards end users (or primary personas among end users).
I completely agree that the default should not be “all”, now that I think about it more (thanks again!), but the expectation I will approach non-functional requirements with is an assumption of “most” and a look to see which stories can be excluded (versus identifying the ones that can be included).
Great stuff.
June 20th, 2010 at 8:51 am
Scott, I agree that many nonfunctional requirements will in a sense apply to most stories. However, I’d clarify to state that most attributes (e.g. availability or, more specifically, uptime) will apply to all or most stories, and that what Weinberg calls constraints (the measurement tied to an attribute, e.g. uptime >= XX%) will often vary by story.
For example, for most web sites, it’s much more important for it to be available to visitors than it is that the administrator can change the content or formatting of the web site.
June 20th, 2010 at 10:48 am
Wouldn’t an NFR impact implementation, rather than just design. Who picks the algorithm, and why would that choice affect the architecture of the system?
If you want to further develop the notion that an NFR applies to some, but not all features, look at the frequency of use of all features. It should be a power law distribution. Where a feature network extends into deeply into the long tail, that’s where the opportunity lies to live with a lower service level.
June 20th, 2010 at 1:47 pm
Really great convo @pawelbrodzinski @crankypm @rcauvin on #Agile non-functional requirements http://bit.ly/9DOwHH #prodmgmt
June 21st, 2010 at 8:31 am
@Roger – Great distinction! I’ve always approached it as understanding the constraints that truly apply to the user’s context, so alignment with stories makes a ton of sense. Pages on an eCommerce site may “need” to load under two (generally), but search results may “need” to be presented in under a second – or vice versa.
I put “need” in quotes because response time (an attribute) leads to a constraint (under two seconds) that is a (current) manifestation of a more-is-better requirement, which has to clear a must-be hurdle, then exhibits diminishing returns.
I love the nuances of this stuff!