Balancing Quality and Risk: The Link Between Quality Indicators, Risk Thresholds, and Risk Appetite

The relationship between quality indicators, risk threshold, and risk appetite lies in how organizations balance quality expectations with risk tolerance in decision-making.

1. Quality Indicator

A quality indicator is a measurable metric used to assess whether a product, service, or process meets predefined quality standards. It helps in monitoring performance and ensuring compliance with quality requirements.

?? Example: In an FTTH project, a quality indicator could be the fiber optic signal loss (attenuation), where values above a certain level indicate poor quality.

2. Risk Appetite

Risk appetite represents the amount of risk an organization is willing to take to achieve its objectives. It varies based on business strategy, industry regulations, and stakeholder expectations.

?? Example: A telecom provider may have a low risk appetite for service disruptions but a higher risk appetite for investing in new, innovative technologies.

3. Risk Threshold

A risk threshold is a specific, measurable limit of acceptable risk beyond which an organization will not proceed with a project or activity. It is a more precise level within the broader risk appetite.

?? Example: If the risk appetite allows a 5% failure rate in fiber installation, the risk threshold might be 3%, meaning that if failure rates exceed this limit, corrective actions are triggered.

How They Relate

? Quality indicators help monitor if performance aligns with acceptable levels.

? Risk thresholds define how much deviation is acceptable before action is required.

? Risk appetite sets the overall direction for how much risk the organization can handle.

Practical Example in a Telecom Project

Imagine you're leading an FTTH rollout:

Quality Indicator: Signal loss should be ≤ 0.3 dB/km.

Risk Appetite: The company is willing to accept up to 5% of installations requiring rework.

Risk Threshold: If rework exceeds 3%, escalation to senior management is required.

Real-World Scrum Case Study: Digital Payment App Development

Background

A fintech company is developing a digital payment app similar to PayPal or Wise, allowing users to transfer money, pay bills, and manage accounts securely. The project follows Scrum with two-week sprints. The stakeholders include:

Product Owner (PO) – Sets priorities based on customer needs.

Scrum Master (SM) – Facilitates Scrum processes and removes blockers.

Development Team – Engineers, testers, security specialists.

Compliance Team – Ensures adherence to financial regulations.

1. Quality Indicator (QI) – Ensuring a Secure & Reliable App

? Quality Indicators:

Transaction processing time ≤ 1.5 seconds.

Less than 1% failed transactions per sprint.

Zero critical security vulnerabilities per release.

90%+ test coverage for all critical functions.

?? Measurement Tools:

Automated testing for performance (JMeter).

Security scans using penetration testing tools (OWASP ZAP).

Sprint reviews & user feedback.

2. Risk Appetite – Defining Tolerable Risk

The company has a low risk appetite for security issues but a moderate risk appetite for minor UI/UX bugs.

? Examples of Risk Appetite in Action:

Security breaches: Zero tolerance (must be fixed immediately).

Performance issues: Up to 2% of transactions can fail, but beyond that, backlog prioritization is adjusted.

UI glitches: Can be addressed in future sprints unless they affect user experience.

Impact:

Critical security bugs are assigned top priority in the backlog.

Performance enhancements are handled as part of ongoing improvements.

UI fixes are scheduled based on user feedback.

3. Risk Threshold – When to Take Action?

A risk threshold sets a specific point where action is mandatory.

? Examples:

If failed transactions exceed 2% for two consecutive sprints, the next sprint is dedicated to fixing the issue.

If a critical security vulnerability is found, the sprint goal cannot be marked "Done" until it’s resolved.

If customer complaints about UI issues exceed 10%, the backlog is reprioritized to focus on UX improvements.

?? Trigger Points:

Security test failure ? Emergency backlog update.

High transaction failure rates ? Dev team investigates performance issues.

Multiple UI complaints ? UX designers work on a patch.

Case Outcome & Lessons Learned

?? Before risk thresholds were enforced:

Minor security vulnerabilities slipped through sprints.

Transaction failures increased slightly due to scaling issues.

?? After enforcing risk thresholds:

Sprint reviews included mandatory security testing before approval.

A performance monitoring dashboard alerted the team when transactions failed above the set threshold.

The Scrum team adapted faster to critical risks while still delivering new features.

PMP Key Takeaways from this Scrum Case Study:

? Quality indicators help measure sprint success.

? Risk appetite defines what risks the company can accept.

? Risk thresholds trigger corrective actions before major failures occur.