Quality Criteria Recommendations

{EPIC_TITLE}

{EPIC_ID} {DATE} {CRITERIA_COUNT} Quality Criteria Identified {ANALYZED_COUNT} of 10 HTSM Categories Analyzed Omitted: {OMITTED_CATEGORIES}

How can this report help you?

▼

"Quality is value to some person." — Jerry Weinberg

This report is generated by the Quality Criteria Recommender, one of the core agents based on the QCSD (Quality Conscious Software Delivery) framework. The QCSD framework recommends conducting Quality Criteria sessions early in the development lifecycle — ideally during PI Planning or Sprint Planning — to align the entire team on what "quality" means for each feature before a single line of code is written.

This analysis uses AI semantic understanding to identify relevant Quality Criteria from James Bach's Heuristic Test Strategy Model (HTSM) v6.3. Unlike simple keyword matching, it understands the meaning and implications of your requirements to surface quality dimensions that may not be explicitly stated but are critical for user satisfaction.

A guided discussion based on this analysis helps teams uncover hidden quality risks, define testable acceptance criteria, create clearer development plans, identify gaps and dependencies early, improve estimation accuracy, and most importantly — avoid costly rework caused by discovering quality issues halfway through development. Research shows that defects found in production cost 30x more to fix than those found during requirements. If we want to save time and cost while still delivering quality software, it is always cheaper to do things right the first time.

Quality Criteria help answer fundamental questions: What aspects of quality are most important for this feature? Where should we focus our testing effort? What risks exist if we neglect certain quality dimensions? How do we build quality in rather than test it in later?

When to generate this report?

▼

During PI Planning & Sprint Planning (QCSD Recommended): The QCSD framework recommends generating this report as soon as Epic/Feature requirements are available — ideally before Sprint Planning begins. This enables teams to conduct a Quality Criteria Session where programmers, testers, Product Owners, Designers, and Architects align on quality expectations before development starts.

Shift-Left Quality Engineering: The cost of fixing defects increases exponentially as they move through the SDLC (1x in requirements → 5x in design → 10x in coding → 30x in production). Use this report to shift quality discussions left — informing architecture decisions, refining acceptance criteria, identifying non-functional requirements gaps, and allocating appropriate testing effort before the first commit.

Before Three Amigos / Refinement Sessions: Share this report with the team before refinement sessions to facilitate meaningful conversations about quality trade-offs. When everyone understands which quality dimensions matter most, the team can make informed decisions about scope, risk acceptance, and technical approach.

As a Living Document: Regenerate this report when requirements change significantly. Quality criteria priorities may shift as the feature scope evolves — what was medium priority may become critical based on new information.

How to use this report?

▼

In this report you will find:

☐ Executive Summary - Key message and critical priorities at a glance.

☐ Quick Reference Table - All quality criteria with priorities and HTSM questions.

☐ Priority-Based Recommendations - Detailed analysis with evidence-based reasoning.

☐ Actionable Tasks - Engineering tasks, User Stories, and Testing activities.

☐ Cross-Cutting Concerns - Quality aspects spanning multiple criteria.

☐ PI Planning Guidance - Sprint-by-sprint quality focus.

Executive Summary

{KEY_MESSAGE}

🚨 Critical Priorities

⚡ Quick Wins

Quick Reference

Quality Criteria	Priority	Key Question	Primary Focus
{CATEGORY_NAME}	{PRIORITY_LABEL}	{HTSM_QUESTION}	{PRIMARY_FOCUS}

Priority Levels

P0 - CRITICAL

Failure causes immediate business/user harm.

P1 - HIGH

Critical to core user value proposition.

P2 - MEDIUM

Affects satisfaction but not blocking.

P3 - LOW

Nice-to-have quality improvements.

Critical Priority Quality Criteria

{CRITICAL_COUNT} criteria

These quality criteria MUST be addressed immediately - failure poses unacceptable risk.

{CATEGORY_NAME} {CONFIDENCE}% confidence

"{HTSM_QUESTION}"

💡 Why This Matters

{SEMANTIC_RATIONALE}

Business Impact: {BUSINESS_IMPACT}

📊 Evidence Analysis

Source Reference	Type	Quality Implication	Reasoning
`{SOURCE_REF}`	{EVIDENCE_TYPE}	{QUALITY_IMPLICATION}	{REASONING}

⚠️ Risk Warnings

⚠️ {RISK_WARNING}

📋 Recommended Actions

▼

{ACTION_TYPE}

{ACTION_TITLE}

{ACTION_DESCRIPTION}

High Priority Quality Criteria

{HIGH_COUNT} criteria

These quality criteria SHOULD be addressed to ensure product success and user satisfaction.

Medium Priority Quality Criteria

{MEDIUM_COUNT} criteria

These quality criteria enhance product quality and should be planned for upcoming sprints.

Low Priority Quality Criteria

{LOW_COUNT} criteria

These quality criteria are nice-to-have improvements for the backlog.

Cross-Cutting Concerns

These quality aspects span multiple criteria and require coordinated attention across the implementation.

{CONCERN_TITLE}

{CONCERN_DESCRIPTION}

{AFFECTED_CATEGORY}

PI Planning Guidance

Suggested sprint-by-sprint approach to systematically address quality criteria.

Sprint	Quality Focus	Key Activities	Criteria Coverage
{SPRINT_NAME}	{QUALITY_FOCUS}	{KEY_ACTIVITIES}	{CRITERIA}