How do you balance feature development with bug fixing when working on a product?

Felize Silva
16 replies

Replies

Rick Radewagen
if the features you ship are not working well, you should fix them. :) Nobody likes using a buggy product. Always fix important bugs. Remove functions, until nothing breaks.
Igor Lysenko
It is necessary to fix important errors and errors that can be corrected later. And of course I give more attention to those errors that are critical.
Mei
How serious are the bugs? If they interfere with the product experience, it would help to prioritise those. If they are background tasks, I would use the 80-20 principle and spend no more than 20% of development time on them.
Neal Woolery
Balancing feature development and bug fixing requires a constant cycle of prioritization and reassessment, ensuring new features add value while maintaining the overall stability and quality of the product. It's like a tightrope walk, but with clear communication, agile methodology, and user feedback, we strive to achieve this delicate balance, creating a product that continually evolves and improves.
Fidel Avendano
Balancing feature development with bug fixing is crucial for a successful product. By prioritizing clear communication, planning dedicated bug-fixing sprints, and implementing a well-defined feedback loop, we can ensure a smoother development process, address critical issues, and steadily progress towards an enhanced product experience.
Eugene Bennett
Balancing feature development with bug fixing is all about setting priorities based on user feedback and impact, ensuring a smooth experience for our customers while also introducing exciting new features to enhance their journey!
Lawrence Scott
When it comes to juggling feature development and bug fixing, what strategies have you found effective in maintaining a harmonious balance and ensuring a top-notch product experience?
Ruby Bryant
Prioritize based on user pain points and revenue impact. Balance is key, but customer satisfaction trumps all.
Diogo Quintas
I use the following rules of thumb: - Is the bug causing the experience to degrade to an extent the user can't accomplish the task they want to accomplish? FIX IT - Is the bug affecting more than 10% of users (i.e. a large number of users will encounter it)? FIX IT - Is the bug affecting more than 10% of sessions (i.e. the bug occurs repeatedly)? FIX IT - Is the bug exposing a reputation risk for the product/company (typically security related)? FIX IT The bug does not match any of these? 80-20 rule: 80% of effort devoted to FIX IT bugs and feature development - 20% devoted to tech debt / minor bug fixing
Ruslan.D
I can't balance it, if there are bugs, then it won't give me any peace and I'll deal with them first
Praneet chandra
In last 10 years i have followed following golden rule and has worked with both large enterprise like Udemy to small startups under 50K revenue 50% - Feature Development - Backlog, Bugs, New Features 25% - Customer Request 25% - Tech Debt/Refinement.
Kien Nguyen
I often break them into 3 category: P0, P1, P2 P0: which is the highest priority, this is the bug / feature in which if it break, then users could not use your software. Let 's imagine you build a chatbot like ChatGPT. If user could not login, then it is P0 If user chat to system, but could not receive response, than it is P0 P1: which is feature / bug related to P0, but it not happen with a group of users, but not all. P2: other bugs / features Other people will use other terms like Tier1, Tier2, Tier3, or "critical path" - which is the path users have to use if they want to get benefit from your product. Basically, we want to focus on P0 related items - either they are bugs for features
Chuck Alvarez
It's like walking a tightrope – you want to add new features to keep users engaged, but you also need to fix bugs to keep the product stable and reliable. One approach is to prioritize bugs that impact the user experience or core functionality. For less critical bugs, you can schedule them alongside feature development, allocating time in each sprint for bug fixing.