Adopting a Prioritization Framework for Technical Work

Part of The PIRATE Way — Stories about scaling up engineering teams.

Photo by airfocus on Unsplash

Introduction

Prioritizing technical work is a critical but challenging task. Technical teams often face several challenges, including:

• Many competing tasks: Technical teams often have many jobs competing for their attention, from bug fixes to feature development to infrastructure upgrades. Determining which tasks are the most important and which can be deferred can be challenging.
• Complex and time-consuming work: Technical work can be complicated and time-consuming, especially when it involves new technologies or complex systems. This can make it difficult to estimate the effort required for each task and to prioritize tasks effectively.
• Conflicting priorities: Technical teams often have to balance the needs of different stakeholders, such as product managers, sales engineers, and customers. This can lead to conflicting priorities, making deciding which tasks to focus on first take time.

Despite these challenges, technical teams must prioritize their work effectively to use their resources best and achieve their goals.

Strategies for Balancing Technical and Product Work

Managing the technical workload in software development is a nuanced endeavor, requiring strategies that align with the product’s immediate needs and the codebase’s long-term health. Below are some established methodologies, each with its benefits and challenges:

Specialized Enablement Teams

Creating dedicated teams — often referred to as enablement or platform teams — can provide a focused effort. This specialized attention ensures that the pressure of feature development does not overshadow engineering sustainability. You will not always be able to allocate full-time resources to that mission.

Integrated Engineering Time

Incorporating a set percentage of sprint time for technical work allows teams to chip away at technical debt and make incremental improvements. This integrated approach keeps sustainability in the regular workflow, ensuring it’s a consistent part of the development cycle. Yet, it can be challenging to tackle large-scale technical projects that require sustained effort over time, as the fragmented allocation of time may lead to longer project durations and potential disruptions in workflow.

Dedicated Sprints

Some organizations opt for periodic “engineering sprints,” where the team steps back from feature work to focus on technical tasks. This can be a powerful way to address significant technical challenges sidelined due to product priorities. The downside is the interruption it can cause to the feature development pipeline, potentially delaying product releases and affecting stakeholder expectations. Coordination for these sprints can also become increasingly complex in larger organizations, requiring careful planning to ensure all teams are aligned and productive.

Hybrid

There is no silver bullet solution for enablement, and your particular context is vital in choosing the right approach. At some scale, having dedicated enablement teams focus on anticipating the technology and architectural needs, ensuring discipline alignment, and optimizing the delivery flow is the way to go. These teams should be combined with enablement capacity at the team level so that teams can satisfy their technical work needs around their particular ownership.

Hybrid enablement presents challenges, such as coordinating between a centralized enablement team and distributed delivery teams, and ensuring that enablement resources are evenly distributed across the organization. However, with careful planning and execution, hybrid enablement can be a very effective way to support teams of all sizes.

Engineering Sustainability Backlogs: Orchestrating Technical Health at Every Level

Managing technical health is as crucial as pushing new features in the intricate dance of software development. A multi-tiered backlog approach ensures that engineering sustainability is not an afterthought but an integral part of the development lifecycle across all levels of the organization.

Organizational-Level Backlogs

At the apex, the organizational backlog encapsulates the overarching technical strategy, aligning with the broader business objectives. It’s the strategic compass that guides the collective efforts of all teams, ensuring that engineering sustainability initiatives contribute to the company’s success narrative. This top-tier backlog ensures that teams may operate independently and move together toward a unified technical horizon, including organizational and process debts.

Discipline-Level Backlogs

At the discipline level, “platform” teams or guilds curate backlogs that transcend individual projects. These roadmaps chart the technical direction for every particular discipline. They encapsulate shared challenges and improvements that, when addressed, elevate the capabilities and efficiencies of all teams within the discipline. By centralizing technical initiatives, these roadmaps promote standardization and foster synergies across various functions.

Team/Squad/Pod-Level Backlogs

Each squad or pod maintains its backlog tailored to the unique technical landscape of its problem domain. These backlogs are living documents prioritizing technical tasks that directly impact the team’s agility and the robustness of their corner of the codebase. Teams must negotiate bandwidth with other counterparts, such as design and product, as a normal part of the required cross-discipline partnership. Team-level backlogs should also be aligned with the overall company strategy to ensure that teams are working on the most critical tasks and that their work contributes to the company's overall success.

By embracing a multi-tiered backlog strategy, an organization ensures a coherent and collaborative approach to engineering sustainability. Each level of backlog acts as a cog in the larger machinery of software development, ensuring that every layer of the codebase is nurtured, from the granular lines of code to the grand architectural blueprints. This systematic approach aligns technical improvements with business goals and imbues the entire software lifecycle with resilience, efficiency, and adaptability for the future.

Prioritization Frameworks: Mastering the Art of Strategic Focus in Engineering

In the intricate web of engineering sustainability, where the backlog of technical tasks is as diverse as the technologies themselves, prioritization frameworks are not just tools but strategic allies. They guide teams in discerning the most valuable tasks, ensuring that every effort aligns with overarching business goals and delivers tangible value.

MoSCoW Method: A Hierarchical Approach

Developed by Dai Clegg, the MoSCoW method offers a hierarchy of task categories, each delineating the level of necessity and potential impact on project outcomes:

• Must-Have: These tasks are the non-negotiables, the essentials that form the backbone of project success.
• Should-Have: Important yet not vital, these tasks enhance the project significantly and are targeted for inclusion.
• Could-Have: Valuable but not vital, these tasks are considered beneficial and are included as resources permit.
• Won’t-Have: Deferred for the future. These tasks are acknowledged but need to be prioritized in the current scope.

This categorical clarity positions the MoSCoW method as a beacon in the fog of competing priorities, offering a compass to navigate the seas of engineering sustainability.

RICE Scoring: Quantitative Evaluation

The RICE scoring system, crafted by the team at Intercom, quantifies the value of tasks through a calculated lens:

• Reach: How many users are impacted or will benefit from the task?
• Impact: What magnitude of improvement or advancement will the task bring about?
• Confidence: How certain is the team of the task’s successful outcome and impact realization?
• Effort: What quantity of resources — time, talent, and technology — will the task consume?

RICE transforms the abstract into the tangible, assigning numerical values that crystallize into a clear priority score. It’s a framework that marries the analytical with the strategic, ensuring that decisions are data-driven and aligned with objectives.

For those seeking a contemporary twist on prioritization, Lenny’s Newsletter sheds light on DRICE — a nuanced adaptation of RICE that merits exploration.

Weighted RICE: A Customized Approach

Building on the RICE framework, the concept of Weighted RICE introduces an additional layer of customization. It allows teams to adjust the weighting of each RICE component to reflect current project needs and strategic goals. For example, if immediate performance improvements are critical, Impact might carry extra weight, ensuring that tasks promising significant performance enhancements are prioritized. Conversely, as deadlines approach, Confidence may become paramount, favoring tasks with a higher certainty of timely completion.

Weighted RICE allows teams to dynamically shift their focus as project demands evolve, ensuring that prioritization remains relevant and aligned with the changing landscape of engineering challenges.

Expanding the Toolbox

Beyond MoSCoW and RICE, an array of other frameworks await adoption, each with its unique perspective on prioritization:

• Weighted Shortest Job First (WSJF): This framework juxtaposes the relative value of tasks against the time required for completion, fostering a focus on quick wins with substantial impact.
• Cost-Benefit Analysis (CBA): A classic economic model that weighs the financial implications of tasks against their projected benefits, guiding financially prudent decision-making.
• Eisenhower Matrix: A time-management cornerstone that categorizes tasks by urgency and significance, it’s a tool for immediate action planning and strategic delegation.

My preferred option is RICE, with some customizations I will elaborate in the following sections.

The RICE Framework for Technical Work: Customization and Application

The RICE framework, initially designed for product management, has proven to be a valuable tool for prioritizing tasks and allocating resources. However, when applied to technical work, specific adaptations are necessary to reflect the unique characteristics of software development. By tailoring the RICE criteria to the technological context, teams can ensure that their prioritization decisions align with business objectives and technical considerations.

RICE for Technical Work: Adapting to the Nuances

The RICE framework, a staple in product management, can be a powerhouse for technical prioritization when adapted to the nuances of software development. This customization ensures that engineering teams make informed decisions that uphold both business objectives and the intricate demands of technical work.

• Reach: In technical projects, Reach should account for the immediate effect on the codebase and the ripple effect across teams and end-users. For example, upgrading a database might improve performance and reduce the operational load, benefitting cross-functional teams and enhancing user experience.
• Impact: For technical tasks, Impact should be measured against key performance indicators like system uptime, error rates, and incident response times. A task that reduces downtime from hours to minutes has a high Impact, directly influencing customer satisfaction and operational efficiency.
• Confidence: With technical tasks, Confidence is about certainty in outcomes and timelines. It’s prudent to evaluate historical data, team expertise, and testing robustness to gauge the probability of successful implementation within projected timelines.
• Effort: Effort in technical terms often goes beyond time to include complexity, technical debt, and the skill level required. An effort estimate should encapsulate all the resources necessary to complete the task, including potential disruptions or dependencies.

Prioritizing Technical Tasks: A RICE Framework Example

To bring the RICE prioritization framework to life, let’s walk through a hypothetical scenario where a Frontend engineering team needs to prioritize a backlog of technical tasks. This exercise is particularly relevant for StaffPlus Engineers, who often struggle to balance technical debt reduction with ongoing product development.

Imagine our Frontend team has identified five critical tasks that need prioritization:

1. Completing migration to TypeScript
2. Adopting a Design System
3. Migrating to Vite
4. Migrating from Cypress to PlayWright
5. Adopting Redux Toolkit for State Management

Task Evaluation Using RICE

Here’s how the RICE framework could be applied to each task:

Completing Migration to TypeScript

• Reach: High — The entire codebase will benefit from type safety and improved developer experience.
• Impact: High — Reduced bugs and cleaner code can accelerate development and ease maintenance.
• Confidence: Medium — Some uncertainty due to the complexity of the codebase.
• Effort: Medium — Significant development resources are required, but they are manageable due to existing JavaScript expertise.

Adopting a Design System

• Reach: High — Standardized UI components will affect all user-facing features.
• Impact: High — Enhanced user experience and consistency across the application.
• Confidence: High — Availability of experienced designers and well-documented systems.
• Effort: Medium — Setup is resource-intensive, but long-term benefits outweigh initial costs.

Migrating to Vite

• Reach: Medium — Affects the build process and could improve developer productivity.
• Impact: Medium — Potential for faster build times and improved hot module replacement.
• Confidence: High — Vite’s growing popularity and community support boost confidence in its adoption.
• Effort: Low — Integration is straightforward with existing modern JavaScript setup.

Migrating from Cypress to PlayWright

• Reach: Low — Affects testing infrastructure with no direct user impact.
• Impact: Medium — Improved testing capabilities and browser support.
• Confidence: Medium — The adoption of a new tool carries inherent risks and learning curves.
• Effort: Low — Migration effort is offset by PlayWright’s ease of use and feature set.

Adopting Redux Toolkit for State Management

• Reach: Medium — Will impact state management across the application.
• Impact: High — Streamlines state management and reduces boilerplate code.
• Confidence: High — Redux Toolkit’s best practices and utilities increase confidence.
• Effort: Medium — Requires refactoring and potential rearchitecture of state management.

Preliminary Assessment

A couple of examples are enough to see this dynamic. The final summary might look like this:

Disclaimer: These scores are examples for illustrative purposes and should be calibrated with real project data to reflect actual task priorities.

Prioritization Outcome

With the RICE scores calculated, the Frontend team can now prioritize their technical tasks as follows:

1. Adopting a Design System — Highest RICE score due to its high reach, impact, and confidence levels.
2. Completing Migration to TypeScript — Also scores high, but the slightly lower confidence level places it just behind the Design System adoption.
3. Adopting Redux Toolkit for State Management — Medium reach, but high impact and confidence make it a strong candidate for prioritization.
4. Migrating to Vite — Despite its low effort, the medium reach and impact place it lower on the priority list.
5. Migrating from Cypress to PlayWright — The lowest priority given its low reach and medium impact, despite the low effort required.

Refining RICE: A Scale-Based Prioritization Framework for Technical Tasks

Photo by Brett Jordan on Unsplash

While the RICE framework offers a systematic approach to prioritization, adopting a scale-based scoring system can enhance its granularity and adaptability. This refined method allows for more nuanced evaluations, providing a spectrum of values rather than the binary high, medium, and low assessments.

Reach

To accurately assess the reach of a task, we can assign a numerical value that quantifies the extent of the impact. This scale ranges from affecting a single team member to impacting the entire customer base or engineering department.

Reach Scale: 1 (single member) to 100 (all customers/engineers)

For example, if a task impacts all of the team's engineers, the reach score would be 100. If a task only impacts a single team, the reach score would be 50.

Impact

The impact metric should be aligned with the team's specific technical and business goals, which can vary depending on the organizational context and strategic direction. For instance, during periods of rapid growth, the focus might be on scalability, while in times of consolidation, improving efficiency might be paramount.

Impact Scale: 1 (no impact) to 100 (crucial to business/technical goals)

For example, if you assign a weight of 30% to the alignment of the task with the quarterly technical goals, a weight of 50% to the potential impact of the task on the quarterly business goals, and a final weight of 20% to the impact on the team of reducing technical debt and improving developer productivity, you can have a very grounded impact.

Confidence

Confidence levels should reflect the team’s certainty in their impact and effort estimates. A lower score would indicate a higher degree of uncertainty, encouraging a conservative approach to prioritization.

Confidence Scale: 25% (low confidence) to 100% (high confidence)

Effort

Effort scoring should account for the complexity and resource demands of a task. This scale helps differentiate between minor fixes requiring a few hours and major overhauls spanning several months.

Effort Scale: 4 (a few hours) to 480 (several months)

Example Application of Scale-Based RICE

Applying this scale-based RICE approach to the same set of Frontend engineering tasks, we might arrive at the following prioritization:

Disclaimer: These scores are examples for illustrative purposes and should be calibrated with real project data to reflect actual task priorities.

Prioritization Outcome

With this new approach, we have a more nuanced way to decide between the TypeScript migration and the Design System, which scored the same with the first approach.

The resulting RICE scores provide a numerical value that can guide the prioritization process. Tasks with higher RICE scores are generally considered a higher priority because they have a greater reach, impact, and confidence relative to their effort.

This calculated approach offers a consistent and transparent method to navigate the complexities of technical work, ensuring that resources are allocated to the tasks that promise the most significant benefits to the engineering team and the broader organization.

Conclusion: The Importance of Prioritization in Technical Work and the Value of RICE Scoring

Technical teams play a vital role in the success of any organization. However, with so many tasks competing for attention, it can be difficult to prioritize effectively. RICE scoring is a simple but effective framework that can help teams make better prioritization decisions.

RICE scoring allows teams to assess each task's reach, impact, confidence, and effort. Teams can then use these scores to rank tasks in order of importance, ensuring they are working on the most critical tasks first.

While RICE scoring is a valuable tool, it is vital to customize the framework to fit the specific needs of your team and organization. For example, teams may want to weigh certain factors more heavily than others, depending on their specific priorities.

Remember: This is a blog post from “The PIRATE Way” series.