Every business analyst eventually faces more work than the team can deliver in the time available. Prioritization is how you decide what gets built first, and it is one of the core skills the IIBA’s BABOK Guide expects a BA to use throughout a project. Some approaches rely on judgement, such as sorting items into must-haves and nice-to-haves using MoSCoW (Must have, Should have, Could have, and Won’t have). Others put numbers behind the decision by scoring each item against a set of factors and ranking the results. This article looks at that scoring approach and at a simple check most teams skip.
A weighted scoring model rates each requirement against several criteria and then combines those ratings into a single number. Typical criteria include business value, implementation cost, risk, regulatory pressure, and strategic alignment. Each criterion carries a weight that reflects its relative importance, and the composite score is the weighted mean of the individual ratings. The arithmetic follows the standard formula x̄ = Σ(wᵢxᵢ) / Σwᵢ, where xᵢ is the rating on criterion i and wᵢ is its weight.
A quick example makes the idea concrete. Suppose value, cost, and risk carry weights of 0.5, 0.3, and 0.2, and a requirement is rated 8, 4, and 6 on a ten-point scale. Its composite score is (0.5 × 8) + (0.3 × 4) + (0.2 × 6) = 6.4, and every item on the backlog is scored the same way, then ranked.
The mechanics are simple enough, so the real judgement sits in the weights and in the choice of criteria, and this is where a common design flaw tends to appear. Analysts often pick criteria that overlap: terms like “business value,” “revenue impact,” and “strategic alignment” sound distinct in a workshop, but on a real backlog, they frequently move together, and when two criteria carry nearly the same information, a scoring model ends up counting that information twice. The result is that requirements scoring well on the shared dimension get pushed up the list for reasons the stakeholders never actually agreed to.
The fix borrows a basic statistical concept: once you have scored a reasonable number of items, you can measure how strongly any two criteria track each other with the correlation coefficient. Pearson’s r correlation, for instance, runs from −1 to +1, where a value near +1 means the two criteria rise and fall together, a value near −1 means they move in opposite directions, and a value near 0 means they carry independent information.
Which coefficient to use depends on your scale. Scoring models often rate criteria on an ordinal scale such as 1 to 5, and for ranked data of that kind, Spearman’s rank correlation is usually a better fit than Pearson’s, because it looks at the order of the values rather than assuming equal spacing between them. The same tool computes it.
As you may suspect, the interpretation matters more than the raw number. The standard Evans scale (1996) treats an |r| of 0.8 or above as very strong, between 0.6 and 0.8 as strong, and below 0.4 as weak. If two of your criteria return r = 0.85 across the backlog, they are close to measuring the same thing, and keeping both effectively doubles that criterion’s weight. The practical response is to drop one, merge the pair into a single criterion, or lower their weights to compensate. This is the same reasoning statisticians apply to multicollinearity in regression, where correlated inputs make a model’s coefficients unstable.
First, Pearson’s r only detects linear association. Two criteria can be related in a curved pattern and still return a low r, so a scatter plot is worth a glance before concluding the criteria are independent. Second, correlation is not causation. A high r between “cost” and “risk” tells you the scores move together on this backlog. It does not tell you that one drives the other, and it is not a reason to redesign the underlying business logic. The check is a housekeeping step for the scoring model, not a finding about the domain.
One more practical point: a coefficient computed on a handful of items is unstable, so a few scored requirements will not tell you much. Aim for a couple of dozen before reading anything into the number.
Putting it together gives a short routine you can repeat on any backlog. Start by agreeing on the criteria and their weights with stakeholders, then score the items against them. Before publishing the ranking, run a correlation check for each pair of criteria and treat anything above roughly 0.8 as a candidate for consolidation. Then recalculate the weighted scores on the trimmed set and confirm that the top of the list still reflects what stakeholders actually wanted.
None of this turns prioritization into a purely numerical exercise. Weighted scoring is a way to organize judgement rather than a substitute for it, and the correlation check simply keeps the model from quietly overweighting a single dimension. For a business analyst, that is the difference between a ranking that holds up under scrutiny and one that falls apart the moment a stakeholder asks why their feature landed where it did.