Chris Belknap

In my role as an Agile coach and Scrum trainer, I get the chance to talk to a lot of Scrum Masters and teams.

When working with teams new to Scrum, one of the questions I usually ask is, "What are your plans to describe non functional requirements (NFRs)?". Typically the Product Owner already has a good handle on functional requirements (i.e. new product features), yet what about the product's performance, security, system availability, and usability? How should those types of items be described? Should NFRs be added to the Product Backlog? What if the NFR applies to most of the Product Backlog items, we'd be repeating ourselves. Scrum does not prescribe solutions, and what works for one team may not work for another. There could be several valid ways a Scrum Team chooses to handle NFRs. In this article I discuss what an NFR is, share a few examples of NFRs, and provide you with some ways for your Scrum Team to 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. Whereas functional requirements convey what features the Product Owner would like built, 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. There are hundreds of examples. 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, since customers navigated from one financial product 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 For Describing NFRs? Now that you know what an NFR is, there are at least three ways to explain how to handle the NFRs in Scrum. This is where experience and experimentation 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 after several Sprints, this is what we added to 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". All the Scrum Teams had to be "singing from the same songbook". In the Product Backlog Sometimes an NFR won’t apply at the macro level for every Product Backlog item (PBI) or at the product Increment level, therefore it isn’t a good 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. Once Sprint the Scrum Team built a report 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 a huge security issue. In the web site's interview forms, 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 (PBI) was added by the Product Owner to mask the fields on the report, and the team fixed the issue in the next Sprint. In the Product Backlog Item’s Acceptance Criteria Adding Acceptance Criteria to a Product Backlog item is a third complimentary way to describe your NFR. The Scrum Guide does not mention Acceptance Criteria, but it is a great practice to answer the question "I know that this feature is complete when...". By the way the Scrum Guide does call out something similar, using the term 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 the team was interfacing with was built 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. Otherwise worried customers would call the Help desk, thinking that their purchase did not complete. Closing In summary you now know what a non functional requirement (NFR) is, and how to handle these types of system requirements. I've offered three common ways to describe non functional requirements (NFRs), and I am sure there are more. 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 would encourage teams to experiment to determine what works best for them. I also like to use this for an interview question to get a sense for a candidate's experience and depth, so feel free to try out this question in your next interview. What alternatives do you use to describe your NFRs? Scrum on!