Ways to find the right balance of feature vs maintenance in a sprint

Release a product half baked 2 months ago. So not all features are there. Leadership is very focused on the live product features like text change, color change. The product is live and viewed by customers so they are very keen on making sure that these are addressed and every little detail is P1.

As this is a half baked product there are a ton of features still left out. Essential features. Like failure paths of payment. currently only tech support can solve, customer reaches out to customer support. On the planning we discuss and schedule these features but there are just too many interruptions from live site.

There are lot of features changes to current site which are being iterated, so team is confused on what is to be worked on as the original features have also being changed without assessing impact on next set of features.

If this continues, we would never be able to take any newer features and another team would get hired to develop this and our team would be tagged as incompetent.

What are some good practices for

  1. managing maintenance work along with feature development?
  2. what is the balance or percentage of maintenance you take with features?
  3. is there a separate team for maintenance and development?
  4. what kind of line do you draw on what are maintenance and what should be pushed for future?
  5. maintenance is not in sprints but development is. how to manage technical debt.

greatly appreciate your help on this.


“Changing colour” isn’t maintenance, it’s enhancement.

As the PM you need to protect your team from stuff like this dropping in mid-sprint. Unless it’s genuinely a critical issue, it goes in the backlog for you to refine & prioritise with everything else.

The other thing you should do is work with your product leaders to set some clear priorities for the product’s objectives/metrics. E.g. if the priority objective at the moment to increase customer retention, then you would focus on developing things that help towards that objective.

This all sounds simple but you’ll need the backing of your manager & product leadership to work in this way


Just wanted to add that this is why it can be extremely helpful to know the strategic priorities of leaders before feature launches (how if fits into the current strategy) and getting everyone on the same page beforehand. Setting explicit “requirements” about what this feature should look, feel, behave or even be used like will help immensely in identifying when something is in a successful state.

Identify the goals early, set simple goals and even feelings that define what success look like, and you won’t be confused about what achieving it looks like. You may have to adjust as you go, but it helps when you’ve agreed with stakeholders prior to building about what state you want to get something to before moving on and why.

It’s always good practice to define what you’re building and why, but getting the stakeholders buy-in on this is the key step that gets easily forgotten. Make sure they know you’re aiming for “earliest testable product” “earliest usable product” or “earliest loveable product” (feel free to throw in any terms to help you define).


leadership is very focused on the live product features like text change, color change. the product is live and viewed by customers so they are very keen on making sure that these are addressed.

This should not be for leadership to decide. If they want to decide what gets done and when, then you can leave and let them be the PM.

There’s give and take of course, but it’s a hot job market and you don’t need to be in a place where upper management takes away your agency


Loads to unpack here; akin to a fire fight: a) “…Not all features are there” b) “…lot of features changes to current site” c) “… features have also being changed without assessing impact on next set of features”

Some predictability/control on the PM process is getting lost (assuming it was there from get go); need to reign that back in or firm it up.

You realeased a product that matched (a); nothing new there - what items were deferred and what were their priorities on your team’s roadmap post release… On (b) who is managing these changes…you… the team… How come impact (c) isn’t being done…

Get some predictability, contol back: Start from the foundation - technical debt needs to be scheduled in with your engineers cognisant on impact to current or near term work… What features/items were prioritised & deferred on roadmap for post release related to the half baked release… Are those features/items still valid and/or need pruning, reprioritising based on product now being in the wild (or metrics…) …

With the above context - responses to your questions:

  1. Both are in the sprint. Lol including tech debt if applicable based on tech debt impact to current or near term…even future work.
  2. Make a small % of your capacity dedicated to maintenance. Fine tune as you go e.g. 1st pass of an 80% capacity for development will cut that down to 60% Dev : 20% maintenance…fine tune…
  3. Not always. “You break it, you fix it” mantra. Ownership & responsibility better aligned there than having a separate maintenance team where items are thrown over to.
  4. Access impact of candidate maintenance item: is it some deficiency to what’s already been implemented based on spec that was deferred intentionally for post release or a new uncovered unthought of scenario not covered by the spec or a break to existing implemented functionality - Prioritise accordingly.
  5. See (1)

Prioritize tech debt right alongside new features in the dev team’s backlog, allocating 20% to tech debt, to start for each sprint. Adjust this allocation as needed but don’t shoot yourself in the foot. Better to have the same dev team working on those as opposed to a different team. If you use a prioritization mechanism you can weigh features and tech debt evenly against each other.

  • For most sprints, I try to follow 70-30 rule. 70% is for new feature requests (coming from business users and customers) while 30% is dedicated to reducing technical debt, code cleanup, fire fighting, etc.

  • My philosophy so far has been everyone on the team should work on new features and everyone should work on maintenance. Ofcourse, there are specialists like Backend devs, database devs, etc., but no one is working specifically on new requests

  • Maintenance, according to me, should be part of your sprints. As a PM, you have to build new products and ship new features but it’s equally important to build a solid foundation and keep your code base tight.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.