Not all parts of a system are equally risky, so quality gates should reflect domain importance rather than arbitrary, uniform thresholds. A risk-based approach sets stricter conditions for critical components and allows more flexibility for low-risk areas.
Setting Risk-Based Thresholds
Instead of a single coverage target for the whole codebase, you can define higher thresholds for modules like payments or authentication and lower ones for admin tools or internal scripts. Similarly, you may treat a single critical security issue as a release blocker, while allowing some low-severity code smells temporarily.
Example risk-based gate ideas:
- Payments module: >= 90% coverage on new code, no critical issues
- Auth module: >= 85% coverage on new code, no open security vulnerabilities
- Internal admin UI: >= 70% coverage on new code, limited minor issues allowed
- Overall: no increase in critical debt sprint over sprintRisk-based thresholds make your gates feel fair and aligned with business priorities rather than arbitrary obstacles.
Common Mistakes
Mistake 1 — Applying a single global threshold everywhere
This ignores risk differences.
❌ Wrong: Demanding 90% coverage on every module regardless of impact.
✅ Correct: Set stricter gates on high-impact areas and more relaxed ones where appropriate.
Mistake 2 — Never revisiting risk assumptions
This freezes gates in time.
❌ Wrong: Keeping the same classification even as the product and usage change.
✅ Correct: Re-evaluate risk periodically based on new features and incidents.