Suppose you're developing a product and want it to work in a new language, handle a minimum number of concurrent users, or work on specific browsers.
Should these qualities be on your product backlog?
These are known as non-functional requirements.
Unlike the more common functional requirements, nonfunction requirements describe attributes of a products rather than the functions it supports.
For example, one facet of a product could be that it works in English, Spanish, and German.
Users do things in the product in each of those languages.
A non-functional requirement describes the state of being of product or system.
Non-functionals present unique challenges for agile teams.
Agile teams emphasize getting small items done quickly.
Non-functionals are often not small, and as we'll see, they aren't really things a team can be done with.
It's as though non-functional requirements don't belong on the product backlog because they don' t cleanly move across statuses such as to do,
doing, done, because it may never be.
The trick to handling non-functional requirements on agile projects is to think of each as having two parts.
First is the need to bring the product into initial compliance with the nonfunction.
Second is they need keep it in compliance.
Separating these makes it easy to handle non functionals.
Imagine we'd like to extend our existing product to work in Spanish.
We add a product backlog item describing that quality.
It doesn't have to be in the form of a user or job story, but it could be.
If so, it would be something like, as a Spanish speaker, I want the product work my language so that I can use it easily.
The team then sets to work.
They translate screens, perhaps move user interface elements a bit to adjust spacing, add an option to allow a user to select a language of preference,
and so on.
Let's assume this bundle of tasks is not quickly completed and it takes a couple of iterations.
But once it's completed, the team calls that backlog item done.
The product now supports Spanish.
Let's see what happens next.
In the next iteration, some new functionality is added that requires a new screen, and maybe a button is also added to an existing screen.
These changes require some translations, but the team is done with the product backlog item of work in Spanish.
Should they add that item back onto their product backlog and do it again this iteration?
And then again, every time there's a need?
No.
When the backlog item is first completed, the team should add something to its definition of done.
If you're not familiar with a definition done, I've got a video linked in the description on definition and done In short,
it's a set of things that must be true at the end of each iteration for work to be considered done.
Once a team has translated a product to Spanish, no new backlog items should be consider done until they too have been translated into Spanish.
So, works in Spanish goes on to the team's definition of done, from now all new work will need to comply with that, just like items need comply other parts
of the definition done Each non-functional requirement has two parts.
A product backlog and it will bring the product into initial compliance and then in addition to your definition of done to ensure the products remains
in compliance.
As a quick second example, consider a website that has decided to support a new browser.
There will be some initial work to do that, minimally testing to make sure every page renders and behaves correctly.
So that's a new product backlog item.
And just as with the Spanish example, after the team is done getting all existing functionality to work in the new browser,
they call that backlog done and add the quality to the definition of done.
Most teams will estimate the work of the initial product backlog item to bring the product into compliance with a non-functional.
They don't estimate a new item on the definition of done.
A team's definition done is usually best thought of as a tax on productivity.
If a team has to support a product in 38 languages and nine browsers, that's a higher tax than a teams supporting one language and three browsers.
By the way, this should be no different than how a team thinks about its definition of done today.
If this video has been useful, please do me a favor and click the like button and subscribe so you don't miss out on future tips to help you succeed with Agile.
It really helps YouTube know to share this with others.
Also, in the comments, let me know what challenges your team has faced with non-functional requirements.
Thank you for watching and I'll see you next time.