Non functional requirements are constraints on the functionality that the story represents. They are another type of acceptance criteria.
We typically separate out NFRs as constraints because they tend to be a cross cutting concern across many if not all stories, and don’t always relate directly to functionality. They constrain the system as a whole. The management of these in the backlog is still very important.
We don’t need to reproduce or rewrite the same NFRs on every single story or acceptance criteria. This would be repetitive and boring and just add noise. Instead, we can be record NFRs in a Wiki or other shared space. If we are using a visual board on the wall these can be made visible there. However, we are looking at stories at scale, and therefore, they are most likely going to be recorded electronically so that they can be accessed in multi-site scenarios across multiple teams.
NFR tests should still be automated where possible and this usually happens in the integration test environment. You may need a separate environment on a different network segment to run performance tests as these typically consume a lot of resources to run. These can be run overnight if it is not possible to run them on each check-in.
Other NFR tests include security pen testing, stability testing when network or service resources are not available, performance tests, load balancing tests and other ‘big system’ criteria that effects epics or features as well as multiple stories.
Things stories should not do
In Mike’s book, chapter 14 gives a number of common story smells (anti-patterns) that stories fall into.
- Stories too small
- Interdependent stories
- Gold plating
- Too many details
- Including the User Interface too early
- Thinking too far ahead
- Splitting into too many stories
- Customer / Product Owner wont prioritise
- Customer wont write the stories
I recommend reading his book to gain more information on these.
I would add to this story anti-pattern list by adding items that occur when scaling agile. They come directly from complexity in the architecture and team structure.
- Stories that cross more than one team
- Stories that are divided by technology stack or component
- Technical stories that have no clear value for the customer
- Stories that have ‘As a [insert component here]’ format
As a Product Owner
I want customers who have locked out their website access to identify their account in the website before we present them to the change password request function
So that we only allow genuine customers to request a password.
Who is the real person benefitting from the value the story will create? Is it other customers who are protected from someone accessing their accounts, or is it the company being protected from fraud?
As a Customer
I want to identify myself to the website before being sent an password request
So that I know my account is secure.
This allows the value to be obvious. The first is more of a requirement, the second is a statement of value.
Customers are to be able to request passwords at least once by selecting the request option (button, link) from the password request page.
Given the customer has an account
And the customer has identified themselves
When a request is received
Then the Customer will receive an password request
- At least once could be ambiguous. Is there a set number or is it really x > 1?
- The button, link is an implementation detail and not part of the acceptance
- I would think about how to automate this test and clicking buttons is quite hard. A call to the code is easier to automate.
- Writing the format in Given, When, Then gives access to automation and BDD style development and is less ambiguous or open to interpretation.
Coming soon: Definition of Ready, Definition of Done, Prioritisation