Question: In real world, business initiatives always take higher priority as there are associated ROIs and deliver something tangible to the users. But there are technical initiatives and projects that need to be done to keep up with the different versions of software, upgrading to a newer platforms, architecture re-factoring etc., 

1. How can we plan, prioritize and manage such competing initiatives?
2. Is there a model to quantify technical debt and its impact to the business?

Answer: 
I would start by **Identifying the ROI that the technical debt delivers** and discussing this with the business. If you can describe both value work and what John Seddon calls 'Failure Demand' in the same terms and using the same metrics then you can agree how to split your capacity across them.

**Example - Architectural Refactoring**

We have a piece of configuration information which is baked into an app (I know, I know...). This config can go unchanged for weeks and then suddenly need changing. 

If the config doesn't get changed then ads stop appearing in an application and we stop making revenue from it.

The quick and dirty solution is to change the config in the code and redeploy. This is repetitive and error prone and ultimately not sustainable.

The sustainable solution would be to factor our the config from the code and provide a mechanism for changing it independently from the code. This will take longer the first time round but will then make future config changes much quicker and less error prone.

Guess which one we have done twice already? That's right the quick and dirty. This is because the ROI on the feature is immediately visible or rather, the Cost of Delay were the work not to be done is very high.

The sell we have to make to the business is, let us spend time refactoring this to address the technical debt. That way, next time we need to change the config it will be quicker than it currently is, so quicker ROI in the future, but we will need to take some capacity away now to address the technical debt. It is deferred ROI.

**Example - Architectural Refactoring as complexity increases**

Sometimes it is hard to describe the technical debt to the business, to them it is just an implementation detail or something you should not have accrued in the first place. 

For example, as something grows in complexity it requires refactoring. In this case I do one of two things. 

I either cover the cost of the refactoring in the delivery of the feature which has required us to go back and look at the code in question. I always call this out to the business either to tell them that the feature will take longer to deliver than similar features have in the past, because we have reached a point where we need to refactor. 

Again I describe this to them as deferred ROI. There will be a greater upfront cost but by doing the refactoring now, future work in this area will be cheaper.

The other approach I take is to treat the development team as a customer of itself and reserve a percentage of capacity, agreed with the business, in each iteration for reduction of technical debt.

**Example - Platform Upgrade**

For the example you give of upgrading to a newer platform I would again look at how you can describe this in terms of ROI, or impact on ROI. 

If the existing platform is no longer supported by the vendor then the business is exposed to the risk of defects discovered in that version of the platform not getting fixed and so impacting on business functionality which depends on it.

This impact will be an increase in failure demand, that is, customers will be less able to get value out of what you as a business provide as problems with the underlying platform are getting in the way. This can be articulated as lost revenue, or potential lost revenue so the ROI is to upgrade the underlying platform.

Prioritising such an upgrade can again be done by looking at the Cost of Delay. If you were not to upgrade the platform would there be any impact on your existing products and services? Would it prevent you from launching new ones? 

If problems in the existing platform are generating failure demand now then the Cost of Delay is high and you have a compelling ROI based argument for doing the work sooner rather than later. 

If you are currently unaffected by problems in the existing platform but need to upgrade in order to add new functionality then the ROI of the new functionality will determine the ROI of upgrading the platform.
I know there's an answer for this and I mostly agree with @Lunivore and @jmort253 answers but I thought I would chime in on how I have seen and heard technical debt handled?

In our company we recently started trying to allocate dedicated week-long sprints that we focus on technical debt. Unfortunately this hasn't worked super well when there are certain features that go over the course of multiple sprints, in which case it's impossible to prioritize low-priority fixes vs features that need to ship.

Kind of building on above, I believe **it's important to show and communicate communicate how technical debt is affecting the team's velocity**. This naturally starts with being able to know what your team's velocity is, and then showing it is simply a matter of process.

Recently we have started costing out all issues with [story points](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) (whether it be features and the small tasks associated with features, or just nitpicky bug fixes) everything is costed out with a certain value. After a period of time, our manager is now able to give a ballpark range of how much bandwidth each engineer has and how much time they can allocate to fixing certain bugs. When we first started this, it was naturally really bumpy because we would forget that there was more to a task so its generally better to overestimate than underestimate. 

After some time though, we were able to give a good sense of what we can fit into the sprint and what we can't and we have been given dedicated time to fix bugs that makes sense (hey you have this feature but from what was costed out you seem to have time for some small bugs?). I think we are still working on a good rhythm and we have juggled between alternating people to fix bugs or just dedicating time for the entire team (especially useful if you have new devs) -- maybe I'll chime in again when we have narrowed that down but we have definitely seen an improvement in how fast we do things when given the time to fix the things that no one sees and it's nice that everyone can "see" it too now.

In regards to responsibility, I don't necessarily think it's the PM's responsibility? Our **engineering manager and tech lead drives managing technical debt** while our PM drives the projects and timeline of features. That being said, **it's important there is dedicated time for the PM and the manager to coordinate and set expectations**.