Agile Methodology

Catching a Cloud, Pinning it Down: How to Capture Non Functional Requirements in Agile

Max 9 min read

Catching a Cloud, Pinning it Down: How to Capture Non Functional Requirements in Agile
Start Reading

Click the button to start reading

Catching a Cloud, Pinning it Down: How to Capture Non Functional Requirements in Agile

You’ve probably heard the expression that “the best things in life aren’t things at all.” Some of our favorite things, such as nights out at the movies, evening walks in the snow and road trips to national parks, wouldn’t mean a whole lot if they didn’t include “things” like laughter, connection, friendship and love.

What do warm fuzzies have to do with non functional requirements in agile? As it turns out these two things are very much alike.

Not a few agile teams have banged away on a big project–planning iterations, completing user stories, producing increment in every sprint–only to discover during testing (or even later) that the product is not in line with the client’s expectations.

The client ordered a pizza, and the team delivered it, exactly to specifications: 16”, pepperoni, piping hot. Yet it lacked something fundamental. Maybe the service was lousy, the restaurant too noisy, the delivery time too long. The team thought it provided just what the customer ordered, yet it wasn’t what they ordered at all.

This leaves the team frustrated and flummoxed. When you play by all the agile rules, such as meet requirements, hold retrospectives and study the burn down chart, how can things go wrong? And how do you change things going forward?

If you’ve learned the hard way that non functional requirements cannot be ignored, even while they cannot be measured, then this post is for you. We’re going to look at how these hazy requirements butt heads with agile, and how to capture and measure their “uncapturable” qualities each iteration.

Agile Functional & Non Functional Requirements

The Definition of Functional & Non Functional Requirements

Let’s start by defining just what functional and non functional requirements are.

Functional Requirements

A functional requirement is a measurable quality or characteristic in a completed project. It’s concrete and often can be seen.

For example, if the project is building a website, a functional requirement may be to build a registration page that includes inputs for both name and email. If the project is to write a song, a functional requirement may be that it includes four stanzas and a chorus.

Since they’re quantifiable and measurable, it’s easy to tell whether or not a functional requirement has been met. It’s as simple as checking something off a list.

Non Functional Requirement

A non functional requirement is a quality or characteristic of a completed project that isn’t directly related to its functionality. It’s neither tangible or measurable, but related to overall qualities the project possesses, or the conditions under which the project must be met.

Non functional requirements (NFRs) include characteristics such as usability, scalability, security, compatibility and performance.

For example, a non functional requirement of “usability” for a website would affect several facets of the project. Copy that’s easy to read, pages that load quickly and a layout that makes navigation between web pages intuitive all contribute to “usability.” However, each of these requirements is quite diverse, and none of them has measurable specifications.

Since they’re nebulous and indefinable and bleed into all parts of a project, then, it’s difficult to determine when a non functional requirement has been met. It’s not so simple as checking a box on a list and pronouncing it “done.”

Further Distinctions between Functional and Non Functional Requirements

Non functional requirements are executive level, big picture goals, whereas functional requirements are easily measurable, definable goals that get into the granular and specifics of the project at hand.

Requirements in the real world aren’t always so cut and dry as to fall into either of these two categories. Many exist in a grey area between the two.

Another distinction between these two requirements is that there are multiple ways to meet an NFR, whereas meeting a functional requirement is clear and straightforward. For example, say a project has a NFR to “increase sales.” This increase may be achieved in one of several ways, including improving the software, increasing the hardware capability or by hiring more employees.

Now that we’ve defined each term, let’s look at how capturing NFRs in agile iterations is a bit like fitting a square peg into a round hole.

The Problem With Mixing NFRs and Agile

The Problem With Mixing NFRs & Agile

Agile teams work efficiently. The agile method is brilliant in part because it ensures a team dedicates its time and energy to increasing the business value of the end project. To this end, each iteration produces increment that meets specific, measurable criteria. Many scrum teams have even developed a “definition of done” that covers all the criteria a task must meet before the user story is complete.

Some agile teams use a system known as “Elephant Carpaccio” which breaks down a long-term project into individual tasks, each of which can be completed in a day. This way, each and every day the team takes another step toward its stated goal.

Everything the team does is a step toward a measurable goal. It doesn’t spend a lot of time going down rabbit holes or building something that has no business value to the client.

A nearly exclusive emphasis on concrete, measurable goals, however, doesn’t jibe with NFRs. Just like two opposite personalities in a workplace, it’s tempting for the agile method to try and sideline NFRs, or even run them out entirely.

Because how can a product manager create user stories and groom a backlog around requirements as vague as “security”? And how does a team assign story points to a requirement as nebulous as “productivity”? How does a team produce increment if the entire sprint it’s working on the foggy notion of “usability”?

The acceptance criteria for a user story entails meeting the “definition of done.” It’s a tactical accomplishment that’s measurable. And non functional requests cannot meet this criteria.

Yet, as we’ve discussed, ignoring NFRs can mean entirely missing the project’s objective. Consider, for example, someone who seeks to improve their health by losing weight. “Overall health,” in this instance, is a non functional requirement, and “losing weight” a functional requirement.

If after a few months this person has lost 50 pounds, it may appear he’s achieving his goal. However, if you look at the larger picture and discover he continues to smoke five packs of cigarettes a day and eats mostly red meat and carbs, he’s not achieving the overall objective at all.

And so as difficult as they are to fit into a backlog or a sprint, ignoring NFRs isn’t an option.

Double-Edged Sword

All this is to say is that the danger of a team focusing only on NFRs is that they’ll go into a “black hole.” They have no increment to present at the end of an iteration. Since they haven’t achieved anything that adds specific business value, they don’t have any need to communicate with the client or with anyone.

On the flip side, the risk of a team focusing only on functional requirements is that they aren’t incorporating larger, big picture thinking into the project. They’re fixated on completing the daily tasks, on the minutia, and may well end up creating something that’s completely missed the mark.

How does a team mitigate both these risks, and marry these two extremes? Let’s go there next!

Steps to Capture NFRs in Sprint Planning

The Three Steps to Capture NFRs in Sprint Planning

Claiming to capture non functional requirements may seem like saying unicorns exist and that Bigfoot lives in the woods behind your house. But it’s not like that. It really can be done.

It starts by approaching NFRs differently from functional requirements. In a broader sense, NFRs are more like constraints than requirements. They’re the boundaries under which a project is executed, the parameters it works within at all times. The functional requirements are executed and completed within these constraints.

NFRs are like company culture in this sense. Although it’s difficult to see and sometimes to define, company culture in fact affects every aspect of the business: from the layout of the workplace, to the attire people wear to work, to the criteria for receiving bonuses and promotions, to the location where the holiday party is held.

Since they’re fundamental to the outcome of a project, NFRs are woven into the entire project, from the planning to the execution to the completion. Without them, something fundamental is missing from the project. And so NFRs are brought into consideration in every sprint planning session.

Yet how do you measure them and determine if they’ve been met? Here’s a simple three-step approach.

1) Prioritize the Non Functional Requirements

The first step is to determine what the NFRs really are. Don’t assume that usability is at the top of the list. Maybe the client values scalability first and foremost.

Completing this first step entails having an open discussion with executives and project stakeholders to get a clear idea of what they are looking to see in the end product.

2) Break the NFR Down

Recall that NFRs are so big and broad that they have many possible solutions. Once you know which NFRs are the most important, at this point it’s necessary to determine how they’ll be executed.

This is demonstrated more clearly with an example. Let’s say an executive wants to increase sales by 10,000 each day. This is a high-level NFR to increase productivity.

The team then determines if this goal is best solved by improving software, increasing the capacity of hardware, or hiring more employees.

Once a path is chosen, the team breaks it down further and determines the individual steps it needs to take. If it decides to hire more employees, this is executed by recruiting, interviewing, training, then hiring new people to do the job.

3) Include NFRs in Sprint Planning

When an NFR has been defined and broken down, it’s much easier to measure and achieve. In this final step, the team creates user stories around these individual steps and includes them in sprints.

For example, if the team decides to hire more people in order to achieve the NFR of increased productivity, then the user stories in the first sprint might be to define the job duties, write a job description and determine the pay. For the upcoming sprints, the team would create user stories around posting and promoting the job, then reviewing applications, and finally interviewing and hiring recruits.

It works the same with other non functional requirements as well. For example, if the NFR is security, and the team is building the registration page, then the user story might be to increase the strength requirement of the password. If the NFR is usability, then the user story might be to create a metric around how long it takes for a page to load. If the NFR is aesthetics, then a user story might be to coordinate fonts and colors within the website.

At this third step, a NFR starts to look very similar to a functional requirement. It can be evaluated per the criteria in the “definition of done” and checked off a list.

Although putting metrics around something like “user-friendly” seems vague, it is possible. As you can see, when broken down, NFRs have metrics and look concrete. This three-step method allows teams to incorporate NFRs into the backlog and assign them user points. They won’t be overlooked. Because they can’t afford to be!

Capturing Non Functional Requirements


Capturing non functional requirements in agile is a real conundrum. Agile and scrum are structured around producing clearly defined, measurable, visible results that you can touch and feel. However, NFRs are just the opposite of that: they’re huge, vague grand objectives that you can’t really “know” if you’ve met or not.

However, it is possible to catch a cloud and pin it down.

Although it may be tempting, the solution isn’t to ignore NFRs. Rather, it’s to get NFRs on the agenda at the beginning, so it’s baked into the entire project. Breaking down an NFR into small, measurable tasks makes it possible to capture them within a sprint.

After a while you’ll find that building a project around NFRs is as easy as “do re mi!”

Table of Contents

Manage Your Remote
Team With Teamly. Get your 100% FREE account today.

Get Teamly FREE

PC and Mac compatible


Teamly is everywhere you need it to be. Desktop download or web browser or IOS/Android app. Take your pick.

Get Teamly for FREE by
clicking below.

No credit card required. Completely free
Get Teamly For FREE

PC and Mac compatible

  • imageChat with your team in real-time
  • imageCreate tasks and workflows with ease
  • imageScreen cam video recording, audio messages and more
  • imageTrack and monitor employee time worked
Teamly puts everything in one place, so you can start and finish projects quickly and efficiently.

Keep Reading

Team Charter

Project Management

Collaborate, Communicate, and Conquer: Mastering Team Charters for Optimal Performance

Collaborate, Communicate, and Conquer: Mastering Team Charters for Optimal PerformanceThe secret to a high-performing and cohesive team often lies in the clarity of purpose, well-defined roles, and strong communication. Team charters provide this foundation, creating a shared understanding of the team’s objectives, expectations, and processes. A team charter serves as a roadmap for your team’s …

Read More

Max 8 min read

what is pi planning in agile

Agile Methodology

What Is Pi Planning in Agile? A Guide to Synchronized Success

What Is Pi Planning in Agile? A Guide to Synchronized SuccessBorn out of a need to break free from traditional, rigid project management methodologies, Agile offers a flexible, collaborative approach to the work environment. It’s not just a methodology, however; it’s a mindset that emphasizes rapid iterations, continuous feedback, and a relentless focus on delivering …

Read More

Max 12 min read

Design Thinking in Project Management

Project Management

How Design Thinking Can Improve Your Future Projects

How Design Thinking Can Improve Your Future ProjectsAnyone who’s been involved in project management for any length of time knows that it can be a real challenge to keep things on track and meet deadlines. Even the best-laid plans can go awry, especially when dealing with unpredictable variables like humans. But what if there were …

Read More

Max 8 min read

Get Teamly for FREE Enter your email and create your account today!

You must enter a valid email address