Expected points explained: inside the FPLRogue model

The short answer

Expected points, or xPts, is an estimate of the average FPL return across possible outcomes. A forecast of 7.91 is not a promise of seven or eight points: a player can blank, miss the match or produce a large haul. Use the estimate to compare decisions under the same assumptions.

This guide explains how to read FPLRogue projections. The worked chart below is deliberately frozen at 6 August 2026. Current recommendations need the latest projection release and team news, not the old player values in that example.

How it works

Playing time determines how much opportunity a player has to earn points. Expected minutes and start probability describe different things: a likely starter can still be substituted early, while a substitute may collect a short appearance. Injury, rotation and workload evidence can change both.

The points estimate combines playing time with position-specific routes to goals, assists, clean sheets, saves, defensive contributions, appearance points and bonus, alongside potential deductions. Team strength, opponent and home or away context affect those opportunities. An attractive team fixture does not guarantee a useful individual role.

At the 21 September check, the production status endpoint identified xPts v1 and Dixon-Coles 3.1 as the live engines. It also reported that v2 distribution bands were disabled. A candidate model or published backtest is therefore not proof that the live tools use that candidate.

The current v1 floor and ceiling are indicative display ranges, not calibrated probability intervals or guaranteed minimum and maximum scores. Do not read them as a statement that a particular percentage of outcomes falls between the endpoints. The August chart preserves the labels and values displayed at that time; it does not establish their statistical coverage.

A practical example

In the original August example, Haaland had 7.91 GW1 xPts, with displayed floor and ceiling values of 6.02 and 9.80. His three-match estimate was 24.63, compared with Bruno at 22.31. The difference over that horizon was 2.32 projected points before captaincy.

Bruno cost £3.5m less in that comparison. Choosing him could be sensible if the saving improved the rest of the squad by more than the projected gap, but the chart does not contain every alternative squad needed to prove that claim. Captaincy also changes the comparison: doubling one player in a specific week is different from comparing uncaptained three-week totals.

Common mistakes

Keep the horizon consistent. A next-Gameweek estimate cannot be ranked directly against a three-Gameweek total, and a single-fixture forecast is different from a Double Gameweek total. Check the fixture list and the units before comparing values.

A fresh injury update does not automatically make an old forecast injury-aware. Check when the projection was captured and whether the affected role was included. The same applies to transfers, changing club assignments and postponed fixtures.

One correct captain or one failed pick cannot establish model accuracy. Compare frozen forecasts with outcomes across a stated cohort and period, including misses. The model-accuracy pages separate research evaluations from release decisions and describe the limits of each test.

Decision checklist

For a current decision, check the Gameweek horizon, capture time, model release, player price, expected minutes and availability. Compare affordable alternatives within the same squad constraints, then account for captaincy, transfer costs and bench cover.

Prefer a decision that remains reasonable when a doubtful starter loses minutes over a tiny numerical edge that depends on every uncertain assumption going right. Keep the forecast used for the decision so the eventual result can be reviewed without rewriting the original prediction.

See current projections and capture times

Read model evaluation results and release decisions