• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Low-value features are regularly reviewed and retired

Purpose and Strategic Importance

This standard ensures teams regularly review and retire low-value features, preventing bloat and maintaining a clear, high-impact product. It frees up capacity, reduces user confusion, and aligns development with measurable outcomes.

Aligned to our "Measure & Validate Value" policy, this standard drives continuous improvement and focus on what truly matters. Without it, products become cluttered, maintenance costs rise, and user satisfaction suffers.

Strategic Impact

  • Reduced maintenance effort and complexity
  • Increased capacity for high-impact development
  • Better user experience and product clarity
  • Lower cost of change and faster iterations
  • Clearer alignment to measurable business value

Risks of Not Having This Standard

  • Waste of engineering effort maintaining unused features
  • Growing product complexity and tech debt
  • Confusion and frustration for end users
  • Slower delivery due to legacy overhead
  • Difficulty demonstrating real product value

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Teams focus on delivery, not feature lifecycle. Once shipped,
features persist indefinitely, regardless of value.
Process & Governance No processes exist to review or retire features.
Decisions are reactive or avoided entirely.
Technology & Tools No instrumentation exists to measure feature usage
or value post-release.
Measurement & Metrics Feature-level metrics are not captured. Value is
assumed rather than verified.

Level 2 – Managed

Category Description
People & Culture Teams begin recognising legacy features as a problem.
Some attempt decommissioning informally.
Process & Governance Reviews occur sporadically, typically when driven by
performance issues or capacity concerns.
Technology & Tools Some tools are used to measure usage, but data is
incomplete or rarely actioned.
Measurement & Metrics Feature retirement is anecdotal and not tracked
against outcomes or value metrics.

Level 3 – Defined

Category Description
People & Culture Feature retirement is accepted as a normal part of
the product lifecycle. Teams participate actively.
Process & Governance A formal review cadence exists for all features,
supported by thresholds for value and usage.
Technology & Tools Usage telemetry, feedback loops, and feature flags
support analysis and controlled removal.
Measurement & Metrics Retirement decisions are based on defined metrics
and evaluated retrospectively for value impact.

Level 4 – Quantitatively Managed

Category Description
People & Culture Teams regularly use data to advocate for the retirement
of low-value or unused functionality.
Process & Governance Feature reviews are embedded in planning cycles.
Decisions are guided by objective thresholds.
Technology & Tools Feature value dashboards inform decisions at portfolio
and team level. Flags enable gradual deprecation.
Measurement & Metrics Impact of feature retirement on flow, cost, and UX
is measured and used to improve practices.

Level 5 – Optimising

Category Description
People & Culture Teams proactively identify low-value work and seek
to eliminate or consolidate features continuously.
Process & Governance Feature lifecycle governance is agile and adaptive.
Learnings from past decommissions guide strategy.
Technology & Tools Predictive analytics help identify candidates for
sunsetting before they degrade product quality.
Measurement & Metrics Value contribution per feature is monitored in near
real-time, guiding iterative retirement decisions.

Key Measures

  • % of features actively reviewed and evaluated per quarter
  • Number of features retired due to low usage or value
  • Impact of retirements on delivery capacity and cycle time
  • Reduction in system complexity or tech debt over time
  • Customer satisfaction or NPS improvements post-cleanup
Associated Policies
  • Measure & Validate Value
Associated Practices
  • Pair Programming
  • Swarming on Issues
  • Shared Learning Days

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering