A question that often comes up: should we really use Nonfunctional Requirements (NFR) in Scrum projects? Before answering this question, we will begin by defining what this term means, not known to everyone.
In a scrum project, we often have a problem: how to manage technical requests that will be essential for several user-stories (US)?
For example, I need to add a table “offer” to create a product sheet, but also the cart, but also the back office …. For that, I will have to install a database. Basically I would have 3 user stories:
- As a customer I want to view the product in detail
- As a customer I want to add a product to the cart
- As a logistician, I want to list the list of available products
For these 3 users-stories, we will have the technical requirement (nonfunctional) of a database to realize these 3 user-stories. At first glance, nothing dramatic … However, this will have different questions:
- On which user-story, we will estimate the workload? The workload will be different if you include the installation of the database.
- If I put the installation of the database on 3 user-stories, will not I risk doing 3 times the work?
- If I put the workload of the installation of the database on a user-story, do not I force the prioritization of this one?
There are different schools to answer this problem and for my part I will advise you the following method.
The use of storyotypes
I had already talked about it in the past but I favor the use of storyotypes that I had already explained in a previous article. However, I do not favor it in all situations.
Article: Making user-stories of different storyotype
Nonfunctional Requirements (NFR) are for me technical tasks that really need to be differentiated from user-stories. I would not write “As a dev, I want to have a database to create a table offer” because I find that mixing user-stories and technical tasks tends to be disruptive. Leave this syntax to the user-stories and prefer the type “Set up a database” if we take the previous example.
A subtask remains a subtask
Now, let’s start on the creation of an offer table considering that the database is already installed; I would let the creation of the table “offer” at the user-stories step because the impact is minimal.
Our developers will split our user-stories into technical sub-tasks during the sprint planning. Knowing that there is a daily scrum everyday, a visual board (if possible with the technical sub-tasks) and that the team of developers rarely exceeds 7 peoples, the communication remains relatively simple intra-team.
In a team with a good agile maturity, the estimate is often done shortly before the sprint planning (in the product backlog refinement) or even directly in planning. The risk that the creation of the table is a problem remains minimal and doesn’t impose NFR.
Why complicate the work of the team by adding a NFR when this need is minimal? Are there really any risks in not doing a NFR for a table creation “offer”? Sincerely, I don’t think that … We imagine problems where the probability of having that is almost nil.
The spike to help
However, if a technical study is essential to create a part of the model around the table “offer”, then I would recommend in this case to use a Spike (a type of task different from user-stories).
Spike is a technique that allows you to research something that is still impossible to really estimate.
Article: What a spike in a scrum project?
Yes to Nonfunctional Requirements (NFR) in some cases
The essentials of the beginning of the projet
When we launch a project, it’s sometimes essential to install or put in place some essential things to start the project: a framework, a database, test tools …
In this case I strongly recommend to put a technical task called here Nonfunctional Requirements (NFR) because this type of installation has an impact on 100% of user-stories. Without doing these setups, no user-story would be feasible.
This type of work can be relatively long or even last a sprint.
Refactoring
Refactoring that doesn’t bring anything to the end user can be considered like a Nonfunctional Requirements (NFR) if it’s considered essential for the rest of the project.
Having old code and old tools can be detrimental to: stability, recruitment of new profiles, security … This is an essential point to process.
I remind you that a user-story must have a business value for key users.
In NoEstimate, it’s almost useless
When teams work in #NoEstimate, making Nonfunctional Requirements (NFR) becomes almost useless because the worry of not knowing where to put the load of the essential doesn’t exist anymore.
No need to bother adding NFR when there is no need in this context.
Nonfunctional Requirements (NFR) in user-stories?
In some cases, NFRs are considered by somebody to be part of the user-stories to indicate certain prerequisites such as:
- will work on IE 11
- responsive website
- function that display in less than 100ms
- activate the “geolocation” function on iPhone
However, when certain points are the same for all user-stories, I prefer to put the criteria at the level of Definition of Done in order to impose these expectations on the whole project.
Conclusion Nonfunctional Requirements (NFR)
If some people categorically refuse the Nonfunctional Requirements (NFR) and others impose them, for my part I’m part of those who limit them but using them.
If this use is questionable, my experience shows me that this is the case where there are less worries about the fluidity of developments. If the team totally refuses this way, as an agile coach, I can only advise them to use the method that seems most logical to it, whether or not to change afterwards.
No worries, according to their experiences, agile coaches don’t necessarily give the same recommendations on this subject of Nonfunctional Requirements (NFR). But it doesn’t matter, the team must feel better with the method they choose.
3 Trackbacks / Pingbacks