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.
Latest Articles
Comments on all Articles
