How can you prioritize technical debt and new feature development in your backlog?

Technical debt is inevitable in software development. A good analogy is to compare it to the interest paid on a mortgage. When interest rates are low it is manageable as long as you keep paying it down. But when interest rates get too high it becomes painful and difficult to repay. Some suggestions: - Categorize debt types: design, usability, code, and infrastructure debt. - Evaluate impact: security, performance, scalability, customer satisfaction. - Allocate time for technical debt identification, prioritization and reduction. - Monitor progress and communicate improvements.

Begin by identifying and documenting all known instances of technical debt within your software. This could include issues like code smells, outdated libraries, architectural shortcomings, and more. For each item in your technical debt inventory, assess the potential consequences it can have on your product. Consider factors such as: 1) Customer Impact: Will it lead to bugs, crashes, that affect user experience? 2) Development Speed: Is it slowing down feature development or making it riskier? 3) Scalability: Can it hinder your product's ability to scale as your user base grows? 4) Security: Does it pose security risks or vulnerabilities? Assign numerical values or qualitative measures to the impact of each technical debt item.

Technical debt if not attended to can cripple your product. I have had two different approaches to handling technical debt and both depend on what phase/state the product is at. For Digital Transformation projects where the product is at a transformative phase from a legacy phase, I have applied the 'pit stops' approach in which we schedule technical debt-only sprints after every couple of new feature sprints to focus on tech debt. The second approach has been to allocate 70% of sprint resources to new features and the remaining 30% to technical debt tasks. This creates a balance where you can satisfy users and stakeholders with new features while simultaneously chipping away at potential product-breaking tech debt.

What I have observed is there is always RoI associated with tech debt cleanup, be it in terms of saving in resources, or reducing downtime, or giving an ability to build something which would help you scale product/revenue. Don’t take up a tech debt project just because code is old and you feel a need for it. Always assign a value/RoI. Try to bundle it with product enhancements, it will help to justify RoI.

Tech debt is inevitable. It is a lot as well about estimating the future Achilles heel in your tech setup and chipping away step by step. I always say prioritisation is a wrong word, because it means one is more important that the other. It is more about managing trade offs and keeping space for both product features and a scalable and functional tech stack

Map Technical Debt to Product Goals: Examine your technical debt items and assess how each one aligns with or contradicts your product vision and strategy. Consider the following questions: 1) Does addressing a particular technical debt item directly contribute to achieving a strategic goal (e.g., improving user experience or scalability)? 2) Does ignoring a technical debt item put your product at risk of not meeting a strategic goal (e.g., security or compliance requirements)? 3) Are there technical debt items that are inhibiting your ability to innovate and introduce new features in line with your product strategy? Give higher priority to addressing technical debt that aligns with your product vision and strategic goals.

I always think of Tech debts as the oil that helps the machine i.e., your product to run smoothly. Mapping tech debts to your product goals is a great way to ensure that the machine is mostly well maintained, but I have seen in the past that some tech debts might not give you any product goals to satisfy. This is where probably the technical prowess of a Product Manager kicks in. Understand what powers your product and what is the need to run that smoothly. The system has its needs and one needs to accept and be ready to satisfy those needs, such that the product can in turn satisfy the needs of the business.

Technical debt isn't just a concern for developers; it has a direct impact on your product's overall success. To effectively manage it, align your technical debt reduction efforts with your broader product strategy. Incorporate technical debt reduction into your product roadmap, making it clear how addressing this debt contributes to your product's reliability, user experience, security, and capacity for innovation. By doing so, you'll not only justify the investment in reducing technical debt but also ensure that your team and stakeholders are working in harmony toward a shared vision.

Think of your car. Suppose it's getting old and sometimes doesn't work well (technical debt). But you also want to add new stickers to make it look cool (new features). You have to decide what's more important - fixing the old parts so it runs smoothly or adding new stickers to make it look better. That's similar to aligning technical debt with your car's vision and strategy.

It is important to connect the lines between technical debt and product vision. Many times I see engineering leaders focus purely on technical reasons for solving technical debt vs. connecting it with opportunities or even threats to the business. Typically, everyone outside of engineering needs to understand how technical debt effects the ability for the product(s) to be success or how it could negatively impact the business (aka churn). If you focus too much on the what and not on the why, its hard to get buy in.

To me, the 80-20 rule each month doesn't seem reasonable. Why? Because each sprint is different, and projects can vary significantly. In one sprint, it could be 95-5 (new features vs. technical debt), while another might be almost 50-50 on technical debt. What I believe should remain consistent is communication and visibility. Utilizing issue trackers and dashboards to visualize technical debt items alongside new feature requests helps everyone understand the current state and the progress being made. From there, maintaining a clear picture allows the team to balance technical debt items more flexibly, aligning with the ever-changing needs and capabilities.

I disagree a bit with others on this one. I personally like the idea of dedicating a percentage of each sprint towards tech debt (example of 80/20 rule) - but the key thing is that is doesn't need to be exactly 80/20 every sprint. IMO you are going for an average over time. Some sprints will have more and others will have less. But it makes addressing debt an ongoing commitment, not a one-time event.

again, it depends on the scale of benefits tech debt reduction is going to bring to you. One could weigh lowering OpEx over adding new features if cost reduction is the metric you want to go after. Tech debt can be highly valuable in reducing opex costs of IT services, especially for data intensive processes.

I’m a big fan of value weighted ranking systems. That means attempting to quantify the difficult, impact, opportunity cost, and risk for all ideas and activities. Under this prioritization framework, you could (and should) add missed upgrades and technical debt, as well as emergent technologies and mainstreaming technology. This will allow you to be more adaptive about time allocation and prioritization of new features as well as technical debt management. Some technical debt may not matter as much as others, or some, in this framework, will take absolute priority flipping it to a 20-80 model until the debt is resolved.

Embedding technical debt resolution within the sprint’s cadence is an acknowledgment of its ongoing nature. It’s a proactive stance that ensures the product's health isn't compromised amidst the quest for new features. The 'Boy Scout Rule' isn’t just a coding ethos but a cultural shift towards continuous improvement, ensuring each sprint leaves the codebase in a healthier state.

In the realm of software development, the adage "what gets measured gets managed" holds true for technical debt. By employing metrics and indicators that quantify technical debt's size, complexity, and impact, you can make more informed prioritization decisions. Utilizing code metrics like lines of code and product metrics such as error rates allows you to monitor progress and validate your assumptions, ensuring that your efforts to address technical debt are data-driven and effective in enhancing your product's performance and quality.

To measure and monitor technical debt, begin by defining key metrics aligned with product goals. These include the technical debt ratio, code quality metrics, bug tracking, performance measures, and security scans. Maintain a backlog of debt items and regularly update it. Gather feedback from developers and users, analyze costs, and report key findings to stakeholders. Continuously improve by setting goals and adapting strategies based on the collected data.

Quantifying technical debt and its ripple effects on the product's performance is the compass that guides prioritization. Metrics act as a mirror, reflecting the state of the codebase, and providing a data-driven narrative that fuels informed decisions.

NPS and Customer satisfaction score will be a great measurement also app reviews on Playstore or app store in addition to Product analytics for every related technical debt feature whether number are sounding Google or getting worse

I first like to isolate the possible sources of technical debt: - bugs - poor technical documentation / centralization of IP - code review - automated test coverage - QA procedures Backing out the source and defining the succession of improvements helps me close the gaps and manage debt. Pattern recognition is key to identifying those measurable KPIs to track the current state of technical debt as well as bench marking future state. There is an art to reading in between the lines of data points and finding the source of truth in the data. Creating swot analyses, interviewing my developers, listening to their concerns during stand up and focusing on the patterns allows for SMART goals that are actionable and task oriented.

In the world of product development, the value and cost of addressing technical debt items are as dynamic as the changing tides. Treating technical debt prioritization as an evolving process acknowledges that what might have been a high-impact issue last quarter could shift in significance. By embracing regular reviews, your team remains agile, ready to adapt to these fluctuations and make decisions that optimize both the product's performance and your development resources. This dynamic approach ensures that your efforts are always aligned with the evolving needs and opportunities in the ever-changing landscape of technology.

Regularly reviewing your product backlog with key stakeholders ensures that technical debt is not dismissed or pushed aside for later releases or to a "someday" pile. At each sprint planning, work with stakeholders to refine and include about 10-20% of the overall planned work to include technical debt. Prioritizing technical debt upfront saves a lot of rework or refactoring in the long run.

The dynamism of the tech landscape necessitates a periodic revisiting of technical debt priorities. It's an iterative dialogue between the evolving market demands, the product vision, and the state of the codebase. A quarterly or release-based review is like a pulse-check ensuring the technical debt strategy remains aligned with the product’s overarching goals.

Refinement must be data driven you have to check regularly product analytics in addition to data related to business as churn, revenue and NPS. Efforts needed to work on Technical debt will be an imoartant factor in prioritization

a) Involve the entire team in technical debt discussions to encourage collective ownership. b) Collaborate closely with your development team, aligning their insights with your product vision. c) Strike a balance - not all technical debt needs immediate attention; prioritize judiciously. d) Educate stakeholders on the value of addressing technical debt to secure their cooperation and resources.

Reframe technical debt as something that is directly connected to the business. When a team or engineer wants to tackle technical debt help them draw the lines in how it impacts the business. When technical debt is solved or dramatically improved celebrate it broadly like if it was a new feature or product launch. It may have just as an impact if not more depending on the situation. This will help your engineering organization to focus on the the most important technical debt, while the rest of the organization is aligned on the importance of solving it for the business.

Tech Debts is an interesting book of work for the solution PMs. In my experience, I often faced the challenge of convincing app/solution stakeholders to squeeze tech debt over the product features that sell and create a competitive advantage. Sales and management want shiny things that sell and bring additional revenue. I approached this challenge by articulating the value to the customer, competitive advantage, and cost savings. By demonstrating value, it was relatively easy to get buy-in from the stakeholders.

Navigating the delicate balance between technical debt and feature development is also a lesson in communication. It’s about fostering a transparent culture where the rationale behind prioritization is shared and understood across the board. Moreover, celebrating the wins, however small, in managing technical debt can foster a collective ownership and drive towards maintaining a healthy codebase, which in turn serves as a robust foundation for innovative features.

There are 6 ways in which you can manage technical debt - - Make how to manage technical debt part of every conversation with your developers. - Be an organizational advocate for maintenance. - Develop a KPI tied to basic product expectations. - Encourage your development team to track technical debt in the same place they track other development items. - Empower developers to do some situation planning around technical debt. - Plan reasonable workloads for sprints.