Defining good

Within non-trivial technical projects, it helps to have a common language to describe "good":

• It enables cross-feature comparisons and prioritization.
• It facilitates conversations between stakeholders, business and developers.

This page suggests a feature quality scale, along with how it can be applied.

Quality scale

A quality scale can be applied to:

• Business goals, stakeholder needs, features, quality, schedule, maintenance, and more ...

	User experience	Description	Requires
Qx	Over-deliver	* Functionality cannot be noticed or used by the user.
Q5	Delight	* Anticipate user desires, and provide it.	* Understand the user’s desires and passions.
Q4	Impress	* Anticipate user unanticipated needs, and provide it.	* Analyze the user behaviors and needs. * Understand the product capabilities. * Establish critical user journeys.
Q3	Satisfy	* Meet user’s known wants.	* Listen to the user’s asks.
Q2	Underperform	* Under specified or poorly implemented. * User experience includes many micro-frustrations.	* Meet purchasing authority’s specification. * Cost saving implementation. * Minimal testing.
Q1	Not practically functional	* While the product “works” the experience is so poor that the user chooses to use something else if available.
Q0	Broken	* Functionality doesn’t work at all.

Possible quality scale

Quality categories for each feature

For each feature, a project can define quality categories.

Feature	Delight	Impress	Satisfy	Underperform	Not practically functional	Broken
On/off button			Works			Fails
Waterproof to		> 100m	> 10m	> 1m		< 1m
Uptime	> 99.999%	> 99.99%	> 99.9%	> 99%	> 90%	< 90%

Example quality criteria

Note: Many features won't need the full scale.

Phase exit criteria

The importance of each quality criteria will vary depending upon:

• Different products.
• Different features.
• Different development phases: alpha, staging for test, production/stable release.

Phase: Alpha release

Feature	Priority	Should	Must	Error tolerance
On/off button	P1	Satisfy	Satisfy	Satisfy
Waterproof	P3	Impress	Underperform	Broken
Uptime	P2	Impress	Satisfy	Underperform

Example phase exit criteria

As requirements

The criteria can be converted into traditional requirements:

The device	should	be waterproof to 100m.
The device	must	be waterproof to 1m.

Example requirements

Bug severity levels

Terminology from the quality scale can be aligned with bug severity levels. Severity can be driven by impact to the user, or impact to the business.

Severity	User Impact	Business Impact
S4 Trivial	* P3 feature underperforms	* Person days to fix.
S3 Minor	* P3 feature is broken * P2 feature underperforms	* Person weeks to fix.
S2 Major	* P1 feature is broken, with work-around * P2 feature is broken, no work-around	* Person months to fix.
S1 Critical	* P1 feature is broken. No work-around.	* Upcoming releases blocked until fix provided.

Example severity scale