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.
(4 votes, average: 4.50 out of 5)
Loading ...
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 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 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 14th, 2009 at 11:01 am
[...] Agile Non-Functional Requirements | Tyner Blain Addressing non-functional requirements in Agile development (tags: agile development) [...]