A non-functional requirement (NFR) is a system-level (or product-level) constraint. NFRs do not relate to functionality but instead refer to attributes, such as performance, accuracy, portability, reusability, maintainability, interoperability, capacity, platform fan-out, and so on, that product backlog items must possess in order to be fully accepted by the stakeholders
Example NFRs include:
- Product must be available 99.99% of the time
- All UIs must be in English, French, and Chinese
- Must operate on Windows 10, Mac OS X, and Linux
Non-functional requirements affect the design and testing of all (or at least many) of the other items in your product backlog. As I explained in the blog post “Nonfunctional Requirements and Your Definition of Done,” every nonfunctional requirement you have is a candidate for inclusion in your definition of done.
With all that in mind, I have a question. Do you think you should be able to put a size estimate on an NFR? Here’s an example to better elaborate that question.
On a previous website development project we had the following NFR.
As a user I want the features to work using Internet Explorer 7, Safari 4, and Firefox 3.5 (Chrome didn’t exist at the time).
How big is this story? If you use planning poker as an estimation technique, do you think you should be able to put a size estimate on this item? If so, what might it be?
It’s a tough question to answer, isn’t it? Using the aforementioned website NFR, let me describe a situation we encountered and how we addressed it.
We had already developed the website to work with the specific browsers mentioned in the NFR, one of which was IE7. At the time our site went live, we knew that Microsoft was about to release IE8. And we also suspected that not all of our users had upgraded to IE7; some were likely using older versions that we didn’t specifically support. For example, one day I received an email from someone who was using the services of our website with IE6. He complained that his experience using our site with IE6 was horrible. I immediately booted up an older computer that had IE6 on it and went to our site. He was not exaggerating; our site looked really bad and was nearly impossible to use in IE6.
Curious about how many other people might have this problem, I checked our web logs and saw that about 11% of the people who came to the site were visiting with IE6. That was enough people for me to at least investigate the cost of supporting IE6.
Now for the part most relevant to this blog! I asked the team, “If I change the Browser Support NFR to include IE6, what would that cost (basically how much effort)?” In other words, I wanted them to tell me the change in size of the NFR if I added IE6 to the list of supported browsers.
So, now back to the original question. Do you think the team should be able to directly size the new (revised) NFR?
The answer turns out to be no, the team members can’t do this. Why? Because the NFR affects the size of all other stories in the backlog. So, you can only “indirectly” measure the size of the NFR.
In our example, calculating the answer to my question involves a two-part algorithm. First, the team needed to review already-implemented features and determine which ones would have to be changed in order to work with IE6. Then the team needed to estimate the effort associated with those changes. That was only the first half of the algorithm.
Second, they needed to revisit each item in the product backlog that hadn’t yet been implemented to determine if the sizes of any of those items would change if we decided to support IE6. The final size was then the sum of the two costs.
To summarize, NFRs are not something you would try to directly size at a planning poker session. They are, however, critical to consider when estimating the size of the other, non-NFR product backlog items. When you are trying to determine the cost of adding or removing an NFR, however, it is possible to indirectly calculate the size of the change. You do this by adding two estimates together: 1) the effort required to update already-implemented items and 2) the effort required to comply with the change on any future, already-estimated features. The sum of these two estimates gives you an approximate size for the new NFR.