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 tend to disagree with the basic assumption that technical initiatives are not business initiatives. They may be different from rolling out a new product or an advertising campaign, but:

* They have a business benefits... be it regulatory compliance, improving efficiencies, making the customer experience better, etc
* They have business costs... training, systems development, etc
* They have business risks... what if stakeholders don't like the changes, what if their costs are more than expected, what if their benefits are less, etc

Where technical initiatives tend to have problems is that they aren't easily understood by decision makers who tend to come from the marketing/sales/"business" side of the house. Basically they aren't as "sexy" as a new marketing campaign or partnership. 

The best approach to getting a better focus on "technical debt" is to do a thorough business case for addressing it. How much will addressing the debt cost in time, money and effort? What is the payback period given the expected labor savings, increased sales, increased customer retention, increased market share, etc once the initiative is implemented? How does this compare to the costs and benefits of maintaining the status quo? Getting this information together will take some time and effort, but if it is done well it should be obvious to you whether or not the technical debt needs to be paid *now* or if payment can be deferred.
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**.