Non-Functional requirements are often associated with the state of the system and not with the functionality that the system has to offer. General 'ilities' of the system such as scalability, interoperability, maintainability, portability, performance and security fall under this umbrella. Agile teams usually struggle with defining and estimating the non-functional requirements in their projects.
Mike Cohn suggested that almost all non-functional requirements can be characterized as user stories. He gave a few examples to show that non-functional requirements might be able to fit into the standard user story template
Fortunately constraints / non-functional requirements can be easily handled as user stories. Here are a couple of examples:
- As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.
- As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain.
- As a user, I want the site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another site to use.
However, Mike did caution that the user story template should only be used as a thinking tool. It should not be used a fixed template for all non-functional requirements.
Jason suggested that instead of trying to address non-functional requirements at story level, teams should be better equipped to see them as a part of the big picture. According to Jason, in their team, they were trying to address the non-functional requirements at individual story level and that did not help. He mentioned,
I like the idea of writing these NFR user stories on the wall and posting them in the work area as a reminder that the team should factor those constraints in when giving estimates.
Mike also suggested a definite way to estimate non-functional requirements. According to him, non-functional requirements have two costs associated to them
- Cost of initial compliance – The amount of work the team would spend in satisfying the non-functional requirement. For example, effort spent on performance testing in sprint five.
- Cost of ongoing compliance – Amount of work required to remain compliant to the non-functional requirement in the subsequent sprints.
Once the team accepts a non-functional requirement into the project (as our team did here in sprint five) they need to remain in compliance with that non-functional requirement for the remainder of the project. I think of this cost as a tax. Doing performance testing (or staying in compliance with any non-functional requirement) creates some amount of overhead on the team (the tax). This overhead or tax must be paid regularly.
For the purpose of estimation, Mike suggested that both the costs should be considered separately. Cost of initial compliance should be estimated just like any other user story or product backlog item. For the cost of ongoing compliance, the team and the product owner need to decide on how often they need to work for compliance.
For example, suppose the team and product owner agree that they will do performance testing in every fourth two-week sprint. The team then estimates that it will take six points of work every fourth sprint. That’s about 1.5 points per sprint. If a team has a velocity of 30, 1.5 can be thought of as about a 5% tax.
Nick Xldis made a very interesting observation on the compliance cost. According to Nick,
If the tax has to keep going up over time you’ve got architecture or process problems that might need attention. This makes it a good barometer for technical debt.
Scott Ambler shared his thoughts on managing non-functional requirements by enabling an independent test team.
Kassab, Olga, Maya and Alain introduced NFR size measurement method (NFSM) to reduce the uncertainty in estimating the non-functional requirements.
Thus, handling non-functional requirements might not be a huge struggle. The key is to handle them early and be aware of the ongoing cost.
Note:- There are various opinions which debate the use of the term non-functional requirements. Mike Cohn would rather call them constraints, where as Tom Gilb would strongly call them quality requirements.
