Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,473
Community Members
 
Community Events
176
Community Groups

How can I best track non-functional requirements in JIRA/Greenhopper OnDemand on my agile project?

I am considering moving my product backlog into JIRA/Greenhopper OnDemand. How have people used JIRA to track non-functional requirements? How have they linked them to user stories, if at all?

3 answers

1 accepted

0 votes
Answer accepted

Non-functional requirements also should come in product backlog as stories. If you just refer the Scrum Primer by Craig Larman, it states the following.

Product Backlog Item

Functional requirements, non-functional requirements, and issues, prioritized in order of

importance to the business and dependencies and estimated. The precision of the estimate

depends on the priority and granularity of the Product Backlog item, with the highest priority

items that may be selected in the next Sprint being very granular and precise.

In that sense they are also just another story in Jira, right?

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.

Like Haris Selmanovic likes this

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.

Many Agile frameworks, including SAFe, define NFRs as constraints on functional requirements. Therefore they should not be as standalone stories, but instead as acceptance criteria.  Studies (https://arxiv.org/pdf/1711.08894.pdf) have shown that teams documenting NFRs as stories often lose the requirements and dependencies.  Another option is to document the NFRs in a centralised tool such as Confluence, and reference the NFR's unique ID into a stories acceptance criteria.

Like # people like this

We have exactly this problem now. We have 2 Product Backlogs : une functional and another technical. So I am interested on how you can link a NFR document in Confluence to acceptable criteria because to own 2 PB is just no manageable now?

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.

What should one do if there are multiple projects / backlogs which share certain non-functional requirements? Copy & paste them from one backlog to the others?

Consider a centralised repository (i.e. confluence) and reference the unique ID of hte NFR

Like # people like this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events