Key Takeaways
- Gut-feel prioritization does not scale. A consistent scoring framework helps teams make backlog decisions based on business value, effort, urgency, and risk instead of whoever asks the loudest.
- Foxly brings prioritization directly into Jira. Teams can score, compare, and rank work without relying on disconnected spreadsheets or separate planning tools.
- Different frameworks fit different teams. RICE, WSJF, and Value vs. Effort each provide a structured way to evaluate competing priorities based on the organization’s goals.
- Structured prioritization creates a defensible decision trail. This is especially valuable in regulated industries where teams may need to explain why certain work, risks, or compliance activities were prioritized over others.
Every product manager knows the feeling: a backlog that keeps growing no matter how fast the team ships. Requests come in from customers, sales associates, and the engineering lead who just found a bug in production. Without a consistent way to weigh those requests against each other, teams end up prioritizing whoever complained most recently. I’ve helped companies build products for over 20 years, and I can attest to this. That’s not a strategy. It’s triage, and triage doesn’t scale.
When I first joined SPK, we were developing SPK vCAD, our cloud-hosted CAD product. We had plenty of feature requests, infrastructure work, and customer asks that were all competing for the same sprint capacity. “Gut feel” wasn’t cutting it anymore. Our team asked for recommendations for prioritizing the backlog, and we brought in Foxly for Jira to put some actual data behind those calls. It changed how we run the backlog, and I wanted to share what this could do for your team. Let’s dive in.
Why Gut-Feel Prioritization Gets Expensive
In regulated engineering environments like medical devices and automotive (anywhere traceability matters), subjective prioritization isn’t just inefficient. It’s a liability. If an auditor asks why a compliance-related task got pushed back two sprints in favor of a new feature, “it felt more urgent” is not an answer that holds up. Decisions need a paper trail.
The usual failure mode is spreadsheets living outside the tool where the actual work happens. Someone updates a priority ranking in a shared sheet, three people are working off a stale copy, and by the time anyone notices, the backlog has drifted from whatever plan it was supposed to reflect. Foxly avoids that by keeping scoring inside Jira itself, next to the issues it’s evaluating.
Two Frameworks Worth Knowing
Foxly ships with several standard prioritization models built in. The value isn’t the framework itself so much as the fact that every backlog item gets scored against the same criteria, instead of whatever logic happened to feel right that week.
Prioritization Method 1: RICE
RICE is the most common starting point. It scores a feature on Reach (how many users it touches), Impact (how much it moves the needle on a goal), Confidence (how solid the underlying data is), and Effort (the time cost to build it). The formula is (Reach × Impact × Confidence) / Effort — divide the upside by the cost, and rank accordingly. Personally, this is not my favorite approach because sometimes stakeholders can argue about Reach, which makes it a theoretical discussion.
Prioritization Method 2: WSJF
WSJF, or Weighted Shortest Job First, comes out of the Scaled Agile Framework and answers a slightly different question: what’s the cost of not doing this yet? It combines User-Business Value, Time Criticality, and Risk Reduction / Opportunity Enablement, then divides by Estimated Size. A task that’s cheap to build and expensive to delay rises to the top fast, even if its total value is modest.
Prioritization Method 3: Value vs. Effort
For our own roadmap for SPK vCAD, we use a modified Value vs. Effort model rather than RICE or WSJF outright. It fits the mix of customer-facing features and backend infrastructure work better than a formula built for one or the other. Each new request gets a business-impact score weighed against an effort estimate, and Foxly turns that into a Priority Score stored as a custom field on the Jira issue. From there, sorting the backlog by that field is a one-click operation instead of a meeting.
Business Value
How much would this item benefit the product/customer/company and help us achieve customer strategic goals?
: Low(COULD HAVE)
Minimal impact on the business and/or customer. Implementation may minimally enhance product or customer experience.
: Below Average(COULD HAVE)
Limited impact on the business and/or customer. Lower priority compared to other items. Implementation could provide incremental value.
: Average(SHOULD HAVE)
Moderate impact on business and/or customer. Considered important but not critical for immediate implementation. Can enhance the product or customer experience to a reasonable extent.
: Average(SHOULD HAVE)
Moderate impact on business and/or customer. Considered important but not critical for immediate implementation. Can enhance the product or customer experience to a reasonable extent.
: High (MUST HAVE)
Significant impact on the business and/or customer. Substantial gain in business value. Considered top priority and essential to achieve business objectives.
Estimated Size
What factors contribute to the estimated size of this task, and how do they affect our project timeline?
For this measurement, we use t-shirt sizes.
- XS – Extremely straightforward and require minimal effort
- S – Slightly larger than XS but still manageable within a short time frame
- M – Require more effort and time to complete, typically ranging from a few days to a week. They may involve some degree of complexity or require input from multiple team members.
- L – Significant pieces of work that require substantial effort and time to complete, usually more than a week.
- XL – Largest and most complex tasks, requiring a significant amount of time and effort to complete, typically spanning multiple weeks or even months. They often involve extensive planning, coordination, and may require input from multiple teams or stakeholders. At this point, this ticket should not be a story but an Epic to be broken down into pieces.
Time Criticality/Urgency
What are the consequences of not addressing this task within the specified time frame, and how does it impact our project timeline?
- Lowest – Not time-sensitive and can be completed at the team’s convenience without impacting the product.
- Low – Have some degree of time sensitivity but is not considered urgent.
- Medium – Have a moderate level of time sensitivity and should be completed in a timely manner to avoid the product losing value or avoid missing an opportunity to build product value.
- High – Time-sensitive and should be prioritized to avoid consequences and product losing value (or impact the customer negatively).
- Highest – Extremely time-sensitive and require immediate attention and prioritization. Failure to complete these tasks on time could have severe consequences for the product and users.
Risk Reduction
How does addressing this task reduce potential risks or uncertainties, and what are the implications if these risks are not mitigated?
This should be answered as the risk to the company and customer. This could include business risk, compliance risk, market share risk, etc.
- Lowest – Little to no negative impact on users or product. Likelihood of risk occurring is extremely low.
- Low – Some degree of negative impact on users or product if not addressed but not prioritized. Likelihood of risk occurring is low.
- Medium – Moderate degree of negative impact on users or product if not addressed. This has some prioritization. Likelihood of risk occurring is medium.
- High – High degree of negative impact and will impact users or product if not addressed and prioritized. Likelihood of risk occurring is high.
- Highest – Will disrupt users and/or product if not addressed. This is highly prioritized to avoid severe consequences. Likelihood of risk occurring is extremely likely.
Stakeholder Prioritization – A Team Effort
A recurring problem in prioritization is that no single person has the full picture. A product manager might call a feature low-effort because the UI change looks small; the engineer who has to touch the deployment pipeline knows better. Foxly’s Priority Planning Poker feature gets around this by having the team vote on scores together, the same way planning poker works for sprint estimates.
Two things come out of that. The scores end up more accurate, because they reflect what the DevOps engineer and the backend developer actually know, not just what looks true from the product side. And the team buys in more, because they were part of setting the priority instead of being handed one.
Better Outcomes from a Prioritized Backlog
None of this is really about the tool. It’s about being able to explain, in plain terms, why the team is working on what it’s working on. Additionally, it’s about having that explanation hold up when someone in a regulated environment asks for it. Foxly keeps that reasoning inside Jira instead of scattered across sheets and Slack threads, which matters whether you’re running a PLM-heavy hardware program or a pure software product.
If your backlog is starting to look more like a list of fires than a roadmap, SPK and Associates can help. As an Atlassian Gold Solution Partner, we work with engineering organizations to modernize their Atlassian toolchains and bring data-driven prioritization into the day-to-day workflow. Contact us to talk through what that would look like for your team.
