How to handle Non Functional Requirements in Scrum Rapid Board

Paolo Furini September 18, 2012

Hi to all

I'm trying to manage my product backlog with the new Rapid Board but, among several other issues, I find very difficult to handle my NFRs stories.

In my project I'm using an approach that uses Stories to map NFRs in my backlog, as Mike Cohn suggests (see: http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories).

I created an issue type called "Constraint", as NFRs are usually this, just constraints put on the whole system (for example Performance, Security, Internal standards compliance,..). Then I'm able to visually differentiate them from regular user stories, assigning a different color in my backlog.

Now I have a bunch of "Constraint" stories in my backlog, and I want to estimate the initial cost of compliance (see http://www.mountaingoatsoftware.com/blog/estimating-non-functional-requirements).

Ok, I can write the story points for initial compliance, and add the story to my sprint. But this isn't a "normal" story... It has to live and show in the backlog forever!

So, when the initial work for the story completes, the issue can't be closed, and it has to return to the backlog. I can end the sprint without transitioning the constraint to Done, but how can I log the story points I've spent on the story?

In addition, a constraint usually has a cost (called by Mike a "tax") that has to be added to every sprint, or every N sprints... How can I manage this with Greenhopper?

My initial thought is to add subtasks to the Constraint story to handle separately the initial cost of compliance, and the onogoing cost (tax) of compliance.

The first subtask (the initial work) is effectively done (and closed) on a specific Sprint, and this is fine.

The problem remains with the subtask that represents the ongoing cost: if I add the Constraint story to every sprint, the team have to pay attention NOT to close it, and the sprint has to be closed when all stories BUT the constraints are transitioned to Done.

Other approaches are impossible to achieve too: for example I can't add constraints to my user stories, because the Rapid Board doesn't give me the ability to customize what I see on the board. So using custom fields is not an option...

Any ideas? How are u dealing with NFRs in GH?

PS: By using GH in real word scenarios, it feels like a "patch" added on top of JIRA, rather than a complete agile product. I found JIRA a good bug tracking system, but IMO Atlassian has to rethink other products philosophy like GH: to make it a really competing product has to overcome the limitations of being too tied to JIRA...

1 answer

0 votes
Lucas Molenaar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 18, 2012

We add NFR to the DONE/DONE criteria of our stories (if applicable) and try to create an automated test for it.

Paolo Furini September 18, 2012

@Lucas: that makes sense.. but what if u want to keep constraints always visible in your backlog, as a permanent reminder for the team? In addition u can't visualize them on the planning board, for the lack of customisation that Rapid Board has...

The only approach we've found is to keep them as separate issues as said, but doing so they enter in the sprint as if they were "normal" stories...

I definitely think GH must provide first-class support to constraints, 'cause every other approach is simply a hacky workaround!

Suggest an answer

Log in or Sign up to answer