Discover more from Leading in Product
When to plan maintenance work
What should happen to all the bugs, support issues, refactoring...
You have a vision, you have a strategy, you have a roadmap, and you have quarterly goals: Let’s build something amazing!
Let’s move forward at half-speed!
Why half-speed? Let me explain.
You cannot spend all your time on new features. There are other things to be done:
Support issues requiring an engineer
Urgent security updates of third-party libraries
Many more unplanned activities
When are you going to do this?
Let’s make a plan.
You have several options
Prioritize all new feature development: Not a good idea, because there is always something new to be built. Bugs will never be fixed this way.
Prioritize all bugfixing: Indeed, some companies follow a “zero-bug policy”. This means that the product needs to be free of bugs in order to take on new features. This is reasonable in some cases, but you need to be clear on:
Are all bugs more important than your product strategy? Maybe yes, but maybe some bugs only occur in edge cases and can be tolerated, as long as you can continue to develop important new functionality.
Where does this end? Probably security issues would be classified as bugs. Will you also include refactoring, if not done while coding anyway? Will you also include support issues? If you include too many things, your roadmap progress might decrease to zero.
Alternate between features and bugs: This is a common approach. Teams spend two sprints on features, then one sprint on bugfixing, then again two sprints on features, and so on. This approach works reasonably well and you can even shift priorities if necessary: Sometimes, you’ll opt for a 2-1 allocation, sometimes for 2-2, and sometimes even 1-2.
Reserve a certain percentage of time for maintenance: You don’t alternate, but allocate x per cent or y hours per week to bugfixing and support. Some companies I’ve seen chose 20% or 1 day per week as their maintenance window. Mostly, this has been too little time.
I recommend using either approach 3 or 4 (unless you build a very exposed, security-centric product). However, if you want to maintain a constant pace indefinitely, it’s going to be more like 50% of your time. Sometimes a little less (new product development), sometimes even a little more (mature product, legacy code).
Be sure to include bugfixing, support issues, refactoring other than during coding (boy scout rule), or any other maintenance work. The other half of your time should be used for product progress!
Be sure to communicate your plan. This also includes explaining why you need the time (the alternative would be old bugs, support complaints, new bugs, etc.).
The percentage should not be negotiable except for high-alert issues. If it were negotiable, the time would not actually be reserved. You’d have to defend it every week. Even for high-alert issues, make sure that not everything is high alert!
The maintenance time is not a free slot for HiPPO requests, and you have good arguments for this.
The main value that one of these approaches provides is reduction of the number of surprises. You will be able to maintain control of open bugs, code quality, support issues, and help requests, all while also progressing reasonably well on the product roadmap.
You can safely keep your velocity because all unexpected work already has a timeframe assigned.
What approach works best for you? Let me know your experience!
Thanks for reading Leading in Product! Subscribe for free to receive new posts and support my work.