Weighing a Known Bug Against a New Feature When Team Capacity Is Tight

When fixing a bug and shipping a new feature compete for your team's time, how do you decide which goes first? ```hint Not every bug is equal Ask first whether this bug is the kind that no feature could outrank. If it is not, think about what each option costs users and the business for every week it waits, and whether you truly have to pick only one. ``` ### Clarifying Questions - How severe is the bug: does it block a core flow such as sign-in or payment, corrupt data, or create a security or compliance exposure, or is it cosmetic? - How many users hit the bug, and do they have a workaround? - Is the feature tied to a hard date, such as a regulatory deadline, a commitment to a partner or customer, or a launch event? - Do both items need the same engineers, or could the fix be handled by someone else, such as the on-call rotation? ### What a Strong Answer Covers - A severity triage of the bug that separates the non-negotiable cases (security, data loss, money errors) from those open to comparison - A comparable estimate of each option's value, urgency and effort, using data where it exists - Ways to avoid a strict either-or: interim mitigations, a smaller fix or a smaller first slice of the feature, split capacity - How the decision is made with stakeholders and communicated, including when to revisit it - How to keep the same dilemma from recurring every cycle ### Follow-up Questions - The bug affects only a small share of users, but they are your largest business customers. Does your decision change? - Sales has promised the feature to a customer by a date, and engineering says the fix will take the whole next sprint. What do you do? - How would you set up the team so this trade-off does not have to be argued every sprint?