In Scrum Agile, NFR stands for Non-Functional Requirements.
📌 What are Non-Functional Requirements (NFRs)?
These are the system qualities or performance criteria that describe how a system should behave, rather than what it should do (which is handled by functional requirements).
🧩 Examples of NFRs in Agile:
-
Performance: “The page must load in under 2 seconds.”
-
Scalability: “The system must support 10,000 concurrent users.”
-
Security: “All passwords must be stored using SHA-256 hashing.”
-
Usability: “The interface must be usable by visually impaired users.”
-
Availability: “99.9% uptime required.”
-
Compliance: “Must comply with GDPR.”
🧠 NFRs in Scrum Agile Context:
-
NFRs are often included in the Definition of Done (DoD).
-
They can be written as acceptance criteria for user stories.
-
For large or complex NFRs, Scrum teams may create separate technical stories or spikes.
-
Product Owners and stakeholders prioritize them alongside functional features.
✅ Best Practices:
-
Make NFRs testable: “System should respond in under 500ms” (not “should be fast”).
-
Document shared NFRs globally (across multiple stories) in a central place or backlog.
-
Involve architects/devops early if NFRs affect infrastructure or deployment.
Here’s how you can write Non-Functional Requirements (NFRs) in Agile Scrum — using user stories, acceptance criteria, and backlog integration.
✅ 1. Writing NFRs as User Stories
Even though NFRs describe qualities, you can still format them as user stories when appropriate:
🔹 Example 1: Performance
As a user,
I want the product page to load within 2 seconds,
So that I can browse quickly without frustration.
🔹 Example 2: Security
As a system administrator,
I want all user passwords encrypted with SHA-256,
So that user data remains secure.
🔹 Example 3: Availability
As a customer,
I want the application to be available 99.9% of the time,
So that I can rely on it for business operations.
✅ 2. Using Acceptance Criteria for NFRs
You can also include NFRs as acceptance criteria in a functional user story.
🧾 Functional Story:
As a user,
I want to log into the system,
So that I can access my dashboard.
✅ Acceptance Criteria (with NFRs):
-
Login response time must be under 1 second
-
System must log all login attempts
-
Passwords must never be stored in plaintext
✅ 3. Storing NFRs in the Backlog
🧱 Where to keep NFRs:
-
As individual backlog items (e.g., spikes or tech tasks)
-
As part of the “Definition of Done” — applied to all stories
-
In technical documentation linked to stories (e.g., a system quality matrix)
💡 Tips:
-
Tag NFRs in your backlog for visibility:
#NFR,#Security,#Performance -
Prioritize critical NFRs in early sprints to avoid technical debt
-
Collaborate with DevOps/QA to define testable metrics for NFRs
No comments:
Post a Comment