Prioritizing Defects And Enhancements In Agile Development

Understanding Defects and Enhancements

Defining Defects and Enhancements

Defects refer to issues or bugs in an existing software system that cause it to produce incorrect results or behave unexpectedly. Defects stem from errors that were introduced during earlier stages of the software development life cycle. Common sources of defects include missing or incomplete requirements, errors in software design and architecture, mistakes in coding implementations, and gaps in testing coverage.

Enhancements represent new features or functionality that aim to improve an existing software system. Enhancements extend the capabilities of a system beyond its current state to provide added value to end users. Examples of enhancements include implementing new business requirements, improving performance or scalability, adding integrations, modernizing the user interface, and supporting new platforms or devices.

Differences Between Defects and Enhancements

While defects and enhancements both lead to changes in the software, there are some key differences between the two:

• Timeframe: Defects refer to issues in the current live system, while enhancements relate to future capabilities.
• Cause: Defects originate from oversights or errors within earlier development stages, while enhancements are driven by new business needs and technology improvements after system release.
• Impact: Defects negatively affect system behavior and can disrupt user workflows, while enhancements aim to add business value and improve user experience.
• Effort: Diagnosing and fixing defects requires investigation into root causes, while building enhancements focuses effort on expanding capabilities.

Prioritization Factors

Business Value

The business value of a defect fix or enhancement measures the expected gain it will bring to achieve strategic organizational objectives and satisfy user needs. Higher business value items directly translate to tangible impacts like increased revenue, lower costs, improved customer conversion and retention, and faster user workflows. Quantitative techniques can estimate values tied to these outcomes for numerical comparison across items.

Risk Reduction

Both defects and enhancements carry risks if left unaddressed. Defect risks include reduced customer satisfaction, data loss or corruption, security issues, compliance failures, and other compoundingproblems from ongoing unstable system behaviors. Enhancement risks come from missed opportunities to better meet user needs, falling behind competitor offerings, and inability to support new technologies or platforms as they emerge. Prioritizing based on risk evaluation minimizes exposures in these areas.

Dependencies

In large, complex systems, there are often constraints around what order certain changes can occur in due to dependencies between capabilities. Defect fixes or enhancements may have hardcoded prerequisites stemming from architectural, data, integration, user experience, and other linkage across modules or components. Understanding the dependency networks is key for logical sequencing of priorities to line up all the pieces.

Effort Required

The level of effort entails the estimated engineering and testing resources needed to successfully analyze, design, implement, validate, and release a defect fix or enhancement. Simple fixes or enhancements take less effort than complex ones involving intricate diagnostics, coordination across teams, extensive code changes, sophisticated validation, security hardening, scalability testing, and elaborate release planning. Factoring in effort levels across priorities prevents overburdening teams.

Common Prioritization Methods

MoSCoW Method

The MoSCoW method categorizes priorities as:

• M – Must Have: Critical items without which the system would have no value
• S – Should Have: Important items with high business benefit or risk mitigation potential
• C – Could Have: Nice-to-have items that add value but are less critical
• W – Won’t Have Now: Items deferred to future releases due to lower priority

MoSCoW enables declaring certain defects or enhancements as mandatory, while allowing trade-offs around other less essential items based on factors like business value, risk, effort, and dependencies.

Kano Model

The Kano model looks at potential customer sentiment toward capabilities to guide priorities:

• Exciters: High customer satisfaction when present but no dissatisfaction when absent. Low priority.
• Linear: Customer satisfaction proportional to capability presence. Medium priority.
• Thresholds: Extreme dissatisfaction when absent but no added satisfaction when present. High priority to meet baseline expectations.

Kano modeling reveals if defects significantly threaten meeting threshold expectations around reliability or security versus enhancements that push beyond what customers already tolerate or expect.

Weighted Shortest Job First

Weighted Shortest Job First (WSJF) scoring compares defects and enhancements across factors by assigning multiplier weights. Common weighted calculation:

WSJF Score = (Business Value x Weight) / (Job Size x Weight)

The highest WSJF scores surface as highest priorities based on that blend of quantified business value, weighted importance, and relative job size or effort.

Business Value vs. Cost Ratio

To maximize return on investment, the net business value anticipated from an item can be divided by its estimated cost to give a ratio for comparisons. Higher ratios indicate bigger bang for the buck on spend for that defect fix or enhancement over lower ratio items.

Best Practices for Prioritization

Involve Stakeholders

Incorporate perspectives from product owners, customer support, user experience designers, business analysts, engineers, and other stakeholders when evaluating business impacts, risks, dependencies, and effort sizing. Drawing on diverse internal viewpoints balances priorities across the needs of the business, users, and development teams.

Re-Evaluate Priorities Frequently

In agile development, the priority landscape can shift rapidly. Defect root causes may turn out simpler or more complex than assumed once investigation begins. New customer needs or competitive offerings may change business values for enhancements. Frequent revalidation of backlogs keeps priorities dynamically realigned to the current reality.

Balance New Features and Technical Debt

If all priority goes toward pumping out new features, the accrued technical debt from shortcuts eventually hinders velocity and quality. Legacy defects and infrastructure enhancements need regular balancing with business-driven items so creeping issues do not accumulate to unmanageable levels.

Consider Cost of Delay

The cost of delay estimates potential value lost over time if a particular defect or enhancement gets continually deprioritized and pushed to later. Factoring in accrued costs of delay counterbalances short term priorities against critical items that may not show immediate return but represent significant lost opportunity if perpetually deferred.

Setting Up a Prioritization Process

Define Criteria

Document guidelines for assessing business value, risk levels, dependencies, and effort sizing to anchor scoring factors. Standard criteria enable consistent evaluations of defects versus enhancements within those frames of reference when justifying priority designations.

Establish Repeatable Process

Institute regular backlog grooming sessions with fixed cadences to systematically revisit, discuss, score, and align priorities against defined criteria. Consistent application of an established process minimizes bias, assumptions, or emotions swaying priority decisions.

Review and Reassess Process Periodically

Evaluate how well defined criteria and priority processes hold up over time relative to actual business outcomes. Revisit and adjust criteria and processes to incrementally improve alignment of priorities selected versus organizational results achieved from pursuing those priorities.