Prioritizing both functional and non-functional requirements in Agile

Question

Hi Everyone & Have a Good Day!!

I am doing research on requirement prioritization in Agile. I need to prioritize functional and non-functional requirements by integrating both them simultaneously. Although the non-functional requirements always been neglected during the requirement prioritization process, it has a serious impact on the quality of software being produced.

May I know any technique or approach that always been applied to prioritize both of the requirements in an Agile project?

Thank you.

Answer 1

There are two approaches I have seen for this.

1. The development team owns engineering quality

With this approach the non-technical stakeholders (and Product Owner if using Scrum) focus purely on functional requirements. The development team owns the non-functional side of things, will set their own non-functional standards and will add their own work items to the backlog in order to meet those standards.

For example a development team might say something like:

• Page response time on a representative server will not be worse than 4 seconds
• All key features will be monitored
• All data will be backed-up and can be restored in 8 hours or less

The team would then work on functional requirements, but all the time ensuring that their engineering standards are being met.

2. Create user stories for non-functional requirements

In this approach non-functional requirements are represented on the backlog. This might include stories like:

As a user I want web pages to return in under 4 seconds so that I enjoy my browsing experience

As a user I want to be confident my data will not be lost in the event of a server failure so that I don't worry about data loss

As a user I want to be sure that my product report is accurate and that the numbers reconcile so that I can confidently use the data in the report

These user stories would be prioritised alongside functional ones in the product backlog.

Answer 2

Scrum is based on the principles and foundations of the Agile methodology.

A key principle is the recognition that customers can, and probably will, change their minds (what they want, how they want it, and when they want it). This volatility means that requirements cannot easily be addressed in a traditional predictive or planned manner.

The Product Owner (PO) is one of three roles defined within the Scrum methodology. He is usually someone with a solid understanding of the business, organization and market that represents stakeholders in the project.

PO is responsible to create a prioritized list of requirements called a product backlog (can work directly with a product manager to be able to assess product backlog requirements). These requirements are organized by themes (requirements aggregation), epics (big requirements that have to be detailed) and stories (detailed requirements viewed from the perspective of the product user).

These requirements are then estimated by the team using techniques such as planning poker.

During sprint planning, the PO describes the team's priority requirements. This description allows for more detailed planning of the activities required to develop the priority requirements.

To answer you're question, prioritization of requirements happen in two different stages

• When creating the product backlog. Here we have the stakeholders with PO. Prioritization here is highly dependent in the objectives the stakeholders are trying to achieve. Let's say we are building two applications (one Android and one for iOS) and the stakeholders are giving a conference (for whatever reason) where they want to showcase the product to an audience using mostly iPhones, they will want to give priority to the iOS app.

• During Sprint Planning. Here we have PO and team. This stage happens after the one mentioned above, so the requirements have already a specific priority attached to them and agreed by the stakeholders. Nonetheless, priority for the sprint ahead can change due to constraints that come through. For instances, I've worked as a developer with a team it had to rearrange certain priorities because the mockups had still to be approved (it was a very unusual case where the solution had to be done for yesterday, the user stories were created without much information and predefined design but things had to move due).

P.S. you might like the following question I've asked.