How does the development team handle non functional requirements?

I believe, documenting them in the product backlog with the PO and ensuring they are properly prioritized.

Agree with Steven that we should raise them to PO and document them in a PBI to prioritize

Standard answer : it depends, but usually, the NFR become an item in your DOD.

Let's say your NFR is "the webapp must scale up to XXXX users".
It will be very hard to pin this NFR as a PBI.
Instead, you will probably add your NFR as an element of your DOD.

My article on NFR's might help:

http://www.scrumcrazy.com/Handling+Non+Functional+Requirements+in+User+…

Essentially, you might need a PBI to implement an NFR when it first appears, and then you might want to add it to the DoD so that the NFR is adhered to in future. Another alternative would be to just add it directly to the DoD, but...

Any time you change your DoD, it's quite possible that all of the upcoming PBI's need to be re-sized too. Look at how the NFR affects future stories then decide if any of them need to be re-sized.

> How does the development team handle non functional requirements?

NFR's that constitute part of the product's scope belong on the Product Backlog. They can then be prioritized relative to other items by the Product Owner. This implies that they might not be necessary for every releasable increment.

NFR's that assert a product's quality belong in the Definition of Done. These will apply to each cumulative increment for which the DoD is observed. No work can be released unless those NFR's are satisfied...in other words they are an invariant assertion of quality. Many NFR's of this type may properly belong in the organizational DoD upon which other DoD's are founded.

In either case, the Development Team should handle them by making sure that the relevant work is planned on their Sprint Backlog. This may take the form of tasks, for example.

Ensure every Increment meets them.