non-functional requirements

Dear Piotr,
You're right!
It's wise that teams try to include as many of the nonfunctional requirements in their definitions of done (DoD) as they possibly can. As regards adding nonfunctional requirements to the Product Backlog (PB), it depends.
If you have a requirement such as "System must support Firefox, Chrome .. browsers", put it in the DoD. If you have a story that delivers no perceived end-user value but does deliver important architecture or infrastructure needed to deliver future user value, put in in the PB as a technical story and involve the product owner in deciding how that new story should be positioned in the PB.

Piotr,

as Oleksii says, you are right. And as you said if the non-functional requirement affects all or almost all the PBIs, it should be added as a constrain to accomplish in your DoD. In the best case, the DT could write some tests that assure that the NFR is met. And of course the NFR can be in the PB, even you can express it as a User Story (Mike Cohn has written about it in his blog), anyway I think the most important thing is that the PO and the DT know that NFRs impact the code and have a cost that has to be taken into account.

Agree with adding them to the DoD; not so sure about adding them to the product backlog. NFR by itself cannot be delivered as an increment or prioritized properly. Unless you have special NFRs that depends only on a few user stories

I'm not agree @Sujith...

Imagine you have a system which generates anything... Some NFR can be that the system works on some specific platform or OS. Another NFR ca be that the system can generate X transaction per hour or the system can accept N request per hour. Those are NFRs that the PO can prioritize, she can think if it's more important for the product to have a new feature or to be full operative on... let's say GNU/Linux or she prefers a new feature or to refactor as needed to adapt the system to accept N request per unit time. These NFRs are constraints that the system have to accomplish and they can be matched to system quality tests. These new capabilities are part or an Increment in itself and can be checked in the future as a part of it.

When possible and logical, expanding the Definition of Done is great. Limiting the Product Backlog to proper user stories and functional requirements only certainly creates challenges. I disagree that non-functional requirements cannot be prioritized or delivered in an Increment; they probably shouldn't be the only value in an Increment.

With the browser support example, it sounds great to require it for a Done increment. However, if doing so requires a significant amount of effort (research, testing, development, infrastructure, addressing technical debt, etc.), then it probably makes sense to represent it in the Product Backlog . . .perhaps it is an "epic" or "theme" size initially and later refined into multiple, focused items. New work can be accomplished with the future Definition of Done in mind while the rest of the product is addressed.

Similarly with the other non-functional requirements noted above. Perhaps a software framework or component upgrade wold be beneficial to the users. While sometimes difficult to phrase as customer value, they can be important to delivering working and valuable software.

There's no need to express NFR as US indeed. As I pointed out before Mike Cohn wrote about creating US for NFRs, as I said there's no need to do it but if you do it you can get the benefit to understand who, what and the intention behind a NFR.

An NFR can be an attribute of either product quality or product scope.

If the NFR must apply to each and every product increment, then it expresses a quality concern which may reasonably be observed via the Definition of Done. Otherwise it may reasonably be held to constitute product scope, and ordered on the Product Backlog accordingly.

@Ian Mitchell, 

"An NFR can be an attribute of either product quality or product scope.

If the NFR must apply to each and every product increment, then it expresses a quality concern which may reasonably be observed via the Definition of Done. Otherwise it may reasonably be held to constitute product scope, and ordered on the Product Backlog accordingly"

Based on the above, is it then safe to conclude that NFR's need NOT be captured in the DoD but it should be captured in the DoD only IF it affects the quality of product increment?

I was oversimplifying a bit, because an NFR may need rewriting or refactoring into parts that apply to both. In other words there may be elements of a single NFR which apply to every increment (and are thus assertions which must hold for Done), and other elements of the same NFR which constitute scope.

For example, a life-critical system may require a certain level of resilience. No increment may be considered Done unless it demonstrates that resilience. However, building that resilience in the first place may require the implementation of fail-over components which would be a matter of scope. A DoD asserting such resilience could only be applied once a Sprint Increment (e.g. the first one) is available which implements that scope.

At the end of the day couldn't we just drop the N & F and call it a requirement? As with any requirement, it should be captured in the User Story as an acceptance criteria. Why add confusion and clutter to a tool that communicates to multiple people? 

In a banking application, some values related to a transaction or any other activity (e.g. account opening) must be logged. These values differ from functionality to functionality. This is a NFR, should it go in user story or DoD?

In a banking application, some values related to a transaction or any other activity (e.g. account opening) must be logged. These values differ from functionality to functionality. This is a NFR, should it go in user story or DoD?

Is that really a non-functional requirement?

However, regardless of whether it is an NFR, is it acceptable to release any product functionality without activity being logged?

I am very much sure that logging activities in financial systems are not NFR. In financial systems, audit trails are really required.

you say "Second possibility is to put them on a separate list on the Scrum board, available for all to see. " 

what is a scrum board?

what is a scrum board?

Short answer: Whatever you want it to be. ;-)



Helpful answer: Although the Scrum Guide makes no explicit mention of it, the Scrum Board is one of those good practices which most Scrum Teams use. Now, the specifics of what makes up a team's Scrum Board are up to the team. Usually there's a Kanban board at the heart of it, i.e. a Board which reflects the workflow which a work item goes through during a sprint. The work items are on a card or a piece of paper and are moved through the columns as they progress. Many teams also include their Definition of Done in the Scrum Board, as well as any other information which needs to be visible throughout the Sprint.

In short, the Scrum Board is an information radiator used by a Team during the sprint. It can be a physical board, or a digital one. Personally, I prefer physical ones.

I'm going to assume that your teams have some way of representing the Product Backlog and Sprint Backlogs.  Those are a form of Scrum Board.  As @Julian Bayer said, a Scrum Board is a way for a Scrum Team to radiate information. A wall full of sticky notes, an electronic list of things, a dry erase/chalk board. Anything can be a Scrum Board.  And you could have multiple boards that radiate different information. 

Scrum Boards are not an actual part of Scrum.  They are just a good idea that many teams have found to be useful. 

Non-functional features are normally added to the definition of "Done" because they apply to all functional features. For some non-functional features, such as performance, security, scalability and maintainability, it's possible to create non-technical, independent items in the Product Backlog. This is usually done when we have to make an improvement in the previously done features.