Sure - my concern was that NFRs are not typically work items that are scheduled into a Sprint for development, many are underlying principles that drive how other stories are implemented. But just spoke to our resident Agile guru and he agreed that a good way was just to have them in as stories but colour-coded and deprioritised so that they're always there to be seen be everyone but don't actually get scheduled into sprints if it's not appropriate. Thanks.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Yeah, and it also lies in the hands of the Product Owner while doing Sprint Planning one sessions to keep reminding the teams not to forget these non-functional requirements everytime they do thier story implementation in their sprints.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Some weeks ago I read something interesting about this topic: non-functional requirements are only requirements for which the main stakeholder is not identified yet. ;)

As Renjith mentioned before, you can handle them as normal requirement. An alternativ would be, to create a new issue type for this type of requirements. if you have a lot of non-functional requirements which are related to the normal user stories, I personally prefer to see them as acceptance criteria: e.g. the response time of x should be under 10 seconds.

Thanks for this. Hm. In my case I know who the stakeholders for the non-functional requirements are :)

I like the idea of a different issue type - may do that.

Agree that in reality NFRs are often acceptance criteria for functional stories, I do want to keep them as a list of entities in their own right rather than buried in other stories - in case they get forgotten when new stories are added, for example.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.