Proposal: Define Work Item Taxonomy (Bugs, Features, Risks, etc.)

[collisdigital]

The Problem

Our engineering handbook currently lacks a formal "Taxonomy of Work." This ambiguity leads to "classification drift" across teams, which manifests in several ways:

• Feature requests are often logged as Defects, which artificially inflates our "bug count" and creates a false perception of low software quality.
• Stakeholder preferences (UI/UX polish) are confused with Bugs, making it difficult for engineers to prioritize "actual breaks" over "subjective improvements."
• Risks are frequently confused with Impediments; for example, a stakeholder might raise a "Risk" for something that is already broken (a bug) or a "Bug" for a potential future problem (a risk).

Without a shared language, our velocity tracking, DORA metrics, and sprint reporting are inconsistent and we end up tracking things in systems that shouldn't be causing an overhead (e.g. risks in the risk system that aren't actually risks etc.) and involving stakeholders where not needed.

Benefits of Standardization

• Accurate Quality Metrics: Distinguish between technical debt, regressions, and new value.
• Streamlined Triage: Items can be easily classified based on the agreed taxonomy and definitions.
• Objective Prioritization: Helps the business understand the trade-off between fixing known issues vs. building new features.
• Improved Reporting: Allows leadership to see exactly where engineering effort is being spent (e.g., "We spent 40% of the sprint on Chores vs. 20% on Features").

Proposed Taxonomy and Definitions

I propose adding the following definitions to our Engineering Handbook. These represent industry best practices for high-performing product teams.

Category	Definition	Key Question to Ask
Defect (Bug)	A failure to meet existing, agreed-upon requirements. The system is behaving in a way it was explicitly built NOT to behave.	"Is this a regression or a failure of existing logic?"
New Feature	Functionality that does not currently exist. It introduces new capabilities or solves a new user problem.	"Does this add new value that wasn't there before?"
Improvement (Enhancement)	An update to an existing feature to make it better, faster, or easier to use, without changing the original core requirement.	"Is the feature working, but could be more efficient/usable?"
Task (Chore / Tech Debt)	Necessary technical work that provides no direct user-facing value but maintains system health.	"Is this for the developer's benefit or system stability?"
Risk	A potential future event that may negatively impact the project or product. It has not happened yet.	"Is this something that might go wrong later?"
Issue (Impediment)	A non-technical blocker or a current problem that is stopping progress but isn't a code bug.	"Is something outside the codebase stopping us from moving?"
Spike	A time-boxed research task to investigate a technical approach or reduce uncertainty before implementation.	"Do we need to learn more before we can estimate the work?"

Proposed Implementation Path

1. Handbook Update: Merge these definitions into the appropriate section of the repo.
2. Tooling Alignment: Update our project management labels (GitHub/ADO etc.) to match these categories exactly.
3. Training: Conduct a 10-minute walkthrough during the next Engineering All-Hands or Sprint Demo to ensure everyone is using the same definitions.

Success Criteria

• Documentation is merged into the handbook.
• A "Triage Guide" is created to help non-technical stakeholders categorize their requests.
• Reporting dashboards are updated to reflect these categories.