My current team has an issue with non-functional requirements, NFRs or ‘-ilities’, if you prefer. Where do they go? How do we bake them into the work being done?
We looked at which ones were important to the business and involved the architects in the initial backlog collation, but there was a nagging doubt that kept raising its head – where are these things catered for? And how do we know we’ve done them?
This was my self-assigned task – to find out how to make sure the quality ‘requirements’ were being handled. So what did I do? Read! And what did I find? Everyone recommending handling them in the same way I have done it on previous projects! Whew! Thank God for that. My experience, backed up by such luminaries as Mike Cohn, is that there are two steps to implementing non-functionals:
- The initial work to set the standard
- On-going application of the standard
Usually, there’s no point in trying to implement all the non-functionals in the first sprint. There is very little application up and running – although there has to be something delivered otherwise we’re not Agile. Discuss as a team what you think is important and what you will have in your Definition of Done (DoD). Add some stories to the backlog to make sure that the initial set-up work gets done at the right time and edit the DoD to include each –ility once you’ve done it.
Obviously, non-functionals depend on the nature of the application you’re building and where you’re putting it – is it internal, external, going to be used straight away or will it not have enough functionality to be useful yet? So it makes sense to get to a certain point, maybe three or four sprints in and then do the initial NFR work.
In this instance, good old Agile had brought to the surface within the first sprint the issues of getting the right software and environments up and running. So, although we delivered working stuff and we had an agreed DoD including some NFRs, it was nowhere near production – meaning there were more stories to be added to the backlog – technical debt – straight away.
Sometimes there’s nothing for it than to make the impossibility of product-delivery transparent and make sure everyone knows that this means there’s more work to be done to streamline the process so that we can build in the performance/security/your-favourite-ility test automation later. In previous projects, NFRs have taken a couple more sprints to become pertinent.
So the lesson here is, don’t forget them, but get the team up and running (delivering working stuff) and the non-functionals will rise in priority in their own time.