Meditating is very helpful but when it comes to dealing with non-functional requirements I have a better idea 🙂

Scrum teams deal with non-functional requirements by addressing them in the product backlog in the form of independent tasks or by constraining product backlog items with an appropriate definition of done or acceptance criteria. 

Non-functional requirements (NFRs) define the system’s characteristics – not its functionalities.

They refer to how the system behaves in certain circumstances – not how you can use it.

Addressing a non-functional requirement can be a job that is a fully independent task unrelated to any functionality.

However, they can also influence how functionalities are implemented.

It all depends on what a specific requirement is.

In this article I will focus on how to organize around NFRs, not how to define them – that’s a different topic.

If you have a list of requirements you can then choose to address it accordingly with your backlog.

Let’s find the simplest way to manage all the work related to NFRs.

Why NFRs in the backlog?

Scrum teams work with the product backlog. It defines all work needed to be done.

There are functional requirements in the product backlog. They take the form of features or user stories and they are decomposed into tasks that are added to the sprint backlog.

We can use the same approach when dealing with non-functional requirements.

Everything will be held in one tool. Everything will be easily traceable – depends of course on the issue tracking tool that you are using.

Backlog items constraints

The idea is to give a task some limitations or constraints that derive from non-functional requirements.

It would be obviously a definition of done or acceptance criteria of this particular job. It can be written in a task description or you can use a checklist of some kind if available in your issue tracking tool.

If we work on backlog items only, we should have a link to the specific NFR that is constraining this task.

It is convenient to have the definition of done and/or acceptance criteria in the form of a checklist that enables progress tracking.

Independent backlog items

In the product backlog, you can define any issue type.

We have to distinguish tasks that address non-functional requirements from others. Those tasks enable the system to behave in a certain way – that is why I like the term ‘enabler’.  As described broadly on safe-enablers those issues are often the result of architectural arrangements and if not specified as NFRs – they can in time become one.

For example: at a certain point, we decide that we should make our app responsive. The team plans an RWD enabler for the sprint, and the team does its job exceptionally well. This enabler represented the work that needed to be done to make an app responsive.
We now want all the features developed beyond this point to be designed as responsive. That initial enabler becomes a constraint on the whole product backlog – a non-functional requirement.

However, the enabler is marked as done at the end of the sprint – it vanishes with all other resolved issues until it is found.

Non-functional requirements as product backlog items

“Hey, Michael – we already have enablers in our backlog why do you want to add another issue type that does the same?”

Well… not exactly.

The concept is to have a transparent list of requirements in a form of issues that is easily manageable.

Enablers and constrained tasks represent the work that we can finish. We can’t finish an NFR. That may seem a bit confusing because I am proposing to add backlog items that won’t ever flow across the scrum board. But that’s exactly how NFRs behave – they are always up to date until they aren’t.

Those NFR issue types will never be worked upon and done. They provide insight into desired system standards. Many NFRs will be addressed by the development team more than once. It is nonsense to create precisely the same issue many times just to mark it again as done. Better have one that is constantly in power to constrain or cause different tasks.

I advise giving this NFR issue type a unique workflow to reflect what state it is in. I recognize three phases of an NFR life:

• NEW – a preparation phase in which the requirements are specified and not yet approved so the development team shouldn’t adhere to them
• VALID – a phase in which the requirements are specified, approved, and should be followed
• CANCELLED –  this requirement for some reason is not valid anymore, it has been replaced by a different requirement

If we implement this kind of workflow then on our list we can easily see which one should we consider during the planning. Thanks to this we have transparency in one issue tracking tool. We can more often make the right decision about the scope of our sprint.

We can also see how certain features meet non-functional requirements. You can easily obtain information about how subsequent versions satisfy NFRs. Link tasks or enablers with NFRs they address. If NFRs have comprehensive descriptions,  a link could be enough to help the team to remember how they should develop the system.  It would be best if you discussed this with the team.

If I have let’s say 14 NFR issue types in my backlog I can easily find them, aggregate them and link them one by one to any other related issues I desire.

NFRs on sprint planning

I am still assuming that NFRs are defined, in progress, or both.

We have a separate issue that aggregates single NFR issues. The linked issues are the list to check on sprint or PI planning if there is any work related to non-functional requirements.

The status will tell us whether we should meet a certain requirement during the development or not.

At this point, we can create enablers or other task acceptance criteria to ensure that the NFRs are met. I highly advise linking those created enablers or tasks to the NFR issues that spawned them.

For more details about a specific requirement, we should be able to check inside the NFR issue and read its description. Below a simple example of a password requirements description:

When the application is in its infancy the product backlog will be obviously enabler heavy.

In time, when the system is operating at a certain non-functional standard, the functional requirements will dominate the backlog.  The constraints in form of definition of done or acceptance criteria will be more common.

If as a scrum master you will help the team to organize around and consider NFRs on sprint planning then it will be a massive contribution to the team and the product. That is another thing you can support the team with besides what was pointed out in How scrum master supports sprint planning.

Inherit organization standards

If we work in a big organization then NFRs can be a tool to ensure certain standards are met across the whole organization.

For example, we can take a large solution structure from SAFE.

Every organization level has its own backlog. We can put an item in the highest level backlog that will influence every related to it item in the lower level.

NFRs are present in every layer of an organization. The trick is to describe higher-level NFRs in a higher level of generality. This way the requirements are inherited to lower level NFRs but in a sort of elastic way. They can be further defined in more detail when describing a certain product.

In conclusion

Using backlog to store and use NFRs is one of many ideas on how to work this out.

In my opinion, it is good to use a tool that is used during planning. If we add a different tool then we will probably complicate the system in which the team operates. That can lead to shortcuts and oblivion.

What we want is a process that enables the organization to define standards, propagate them, and ensure the teams have access to non-functional requirements in the most effective way possible.

For me – NFRs in Your backlog is the answer.