When interviewing people for a Scrum Master position, one of the questions I usually ask a potential candidate is this simple, straightforward question: How have your Scrum Teams handled Non Functional Requirements (NFRs)?
In my experience more than half the candidates struggle to provide an acceptable answer. How deep a person goes with their response can tell you a lot about their experience and provide you with some good insights, because there could be several valid ways a Scrum Team chooses to handle NFRs. Scrum does not prescribe solutions, and what works for one team may not work for another.
In this article I discuss how you might answer this question, share a few examples of NFRs, and provide you with some ways for your Scrum Team can handle them.
What is a Non Functional Requirement (NFR)?
Let’s start by revisiting for a moment what the Scrum guide states about requirements in general:
[The Product Backlog] is the single source of requirements for any change to be made to the product.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
The Product Backlog is an ordered list of everything that is known to be needed in the product.
Non Functional Requirements (NFRs) describe system behaviors, attributes and constraints, and they can fall under multiple categories. System performance, security, failover, capacity, scalability, usability, and reliability are just a few categories.
I once worked on a web product at a large financial firm, which managed over 5 trillion dollars of investor’s assets. The last thing anyone at the company wanted was to end up on the front page of the Wall Street Journal for a security vulnerability. This firm also had multiple products, built in silos over the years by different development teams, and needed a way to keep its company branding (color, fonts, images, etc.) consistent as customers navigated from one application to another (e.g from their IRA account to online banking). In other words, even though the firm sold many products, they needed a seamless experience for their customers. Let’s look at a few specific examples:
All source code must be run through a static security testing tool to be analyzed for security flaws, with all issues remediated (security).
Every web and mobile web pages related to brokerage trading transactions (stocks, bonds, mutual funds) must load in under 2 seconds (performance).
If a customer has logged into our site and the session is idle for more than 10 minutes, automatically terminate the users session and log them off the system (security).
All customer facing web pages will use the corporate style guide colors, fonts and corporate approved logos (branding).
All web pages must support our visually impaired customers through our department Accessibility guidelines and best practices (UX Accessibility).
What Are My Options?
Now that you know what an NFR is, there are at least three ways you can explain how to handle the NFRs in Scrum. This is where experience comes in to play. You won’t find the term Non Functional Requirement, or NFR, in the Scrum Guide, because it is up to the Scrum Team to figure out the best way of describing them.
In the definition of “Done”
For NFRs that apply to the entire product Increment and across all Product Backlog items, the most common solution is to describe the NFR in the definition of “Done”.
From the Scrum Guide
If the definition of “Done” for an Increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
If “Done” for an Increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product.
As an example, I was working for an insurance company who provided auto insurance quotes for mobile web users. Our Product Owner, who was deep into analytics, discovered that mobile web users abandoned the site at a high rate if a page did not load in two seconds or less. Therefore this is what we included in our definition of “Done”:
For customers using iOS and Android on a 4G network, all mobile web pages must load in under 2 seconds.
This requirement made sense to be placed in the definition of "Done" because it applied broadly. In fact we had multiple Scrum Teams working on this product, and they shared one common definition of "Done".
In the Product Backlog
Sometimes an NFR won’t apply at the macro level for every Product Backlog item or at the Increment level, therefore it isn’t a fit for the definition of “Done”. It is then perfectly acceptable to describe it in in the form of its own Product Backlog item (PBI), making the work visible in your Product Backlog.
Let’s go back to the auto insurance quote example. A report was created and made available for Sales reps to make follow up calls to customers who did not make an online purchase. It was fairly common for customers to drop out of the sales funnel for various reasons. During the Sprint Review feedback was given that the report was displaying NPPI data, which was an issue. In the web site's interview process Non-Public Personal Information (NPPI) was asked for to provide an accurate auto insurance quote, such as social security number, date of birth, and drivers license number. To remedy the situation, a Product Backlog item was added by the Product Owner to mask the fields on the report, and the team fixed the issue next Sprint.
In the Product Backlog Item’s Acceptance Criteria
Adding Acceptance Criteria to a Product Backlog item is a third way to describe your NFR. The Scrum Guide does not mention Acceptance Criteria, but it does call out test descriptions.
Product Backlog items often include test descriptions that will prove its completion when “Done.”
I was once working with a Scrum Team who was building a feature to handle online credit card payments, and one feature they were implementing was to send an email confirmation once a customer’s credit card was authorized and payment was made.
The email server software was set up to send batches of emails every 10 minutes. The NFR was that the email had to be triggered and sent from the email server within 30 seconds of a processed payment, and it was expressed using Acceptance Criteria.
Closing
If you use this question in your next interview, assuming the interviewee provides an adequate answer and shares some examples, a related follow up question might be to ask them to explain the difference between the definition of "Done" and acceptance criteria.
The Scrum Guide is not a 'how to' guide with prescribed answers, and there are usually multiple ways to solve problems when dealing with complexity. I've offered three common ways to describe non functional requirements (NFRs), and I am sure there are more. I would encourage teams to experiment to determine what works best for them.