Certification Needs Its Own Lane on Your Roadmap

Certification lead time breaks roadmaps when it's treated as a task instead of a lane: a fixed external lab queue and a resubmission trigger that fires on every material change to a live game don't bend to your sprint cadence. The fix is structural, not a better estimate. Run certification as its own parallel lane on the roadmap, starting the day the math model is frozen, and treat lab turnaround as a dependency you schedule around rather than a task you nest inside the launch sprint. At Luminbrane we've watched teams do everything else right on a launch and still miss the date because certification was planned as a checklist item rather than a workstream with its own calendar.

• Short answer: certification has to be modelled as its own parallel roadmap lane, not a step nested inside the launch sprint.
• First step: book the lab slot the day the math model and RNG are frozen, before internal QA even starts.
• The goal: a certification lane that runs continuously in the background, so lab turnaround never becomes the launch's critical-path surprise.

Tips: Book the lab slot before the feature is code-complete; a held slot you later cancel costs far less than a slot you can't get for six weeks.

Key takeaways

Certification has to run as its own parallel lane on the roadmap, starting the day the math model is frozen, because the test lab's fixed queue and the resubmission triggers on every material change don't bend to your sprint cadence.

Point	Detail
Lane, not task	Certification should run as a parallel roadmap lane starting at math model freeze, not a task nested inside the launch sprint.
The queue is fixed	The test lab's queue does not flex to match your sprint cadence, so the lab slot has to be booked before the feature is finished internally.
The operator owns it	Under UK Gambling Commission rules the operator, not the studio, is contractually responsible for scoping testing and cannot release a game until the report is submitted.
Resubmission is routine	Under the MGA, changing a live game's RNG or math model, not just launching a new title, triggers a fresh prior-approval submission with its own fee.
RNG testing needs time	RNG testing checks uniform distribution, unpredictability, non-cycling and fair seeding against RTS 7, so it cannot be shortened by rushing internal QA.

Contents

• Why doesn't game certification fit inside a two-week sprint?
• Who is actually on the hook for certification, the studio or the operator?
• What happens when you change an already-certified game?
• Why can't RNG testing be rushed to hit a launch date?
• How do you build a certification lane into the roadmap?
• How should certification timing differ across a multi-jurisdiction launch?
• What should product managers track once the lane is running?
• Frequently asked questions
• Sources

Why doesn't game certification fit inside a two-week sprint?

Because the lab doesn't run on your calendar. A two-week sprint assumes every dependency can flex enough to land inside the sprint or slide cleanly to the next one. Independent test labs, the third parties who verify RNG behaviour and RTP against a jurisdiction's technical standards, don't work that way. They run one queue across every operator and studio submitting that month, and a slot booked today might not open for several weeks.

That mismatch is where most roadmap slippage on this topic actually comes from, not from the testing itself taking longer than expected.

• The queue predates your sprint plan. The lab was already booked solid before your feature entered the backlog. Asking "can you fit us in next week" gets the same answer regardless of how urgent your launch is.
• A missed slot is a lost slot, not a delayed one. If the game isn't ready when the booked window opens, you don't get bumped to the front of the next opening. You go back into the general queue.
• A single sprint task hides the real dependency. Writing "certification" as one card in the launch sprint implies it's something your team controls the pace of. It isn't. The lab's throughput is fixed regardless of how well your team executes.
• Estimates without lab context are guesses. The generic "four to twelve weeks" figure that shows up on most certification explainers isn't wrong, it's just useless for sequencing, because it says nothing about when in your build process that clock should start ticking.
• Parallel running is the only lever you have. You can't make the lab faster. You can make sure the lab isn't waiting on you, which means starting the lane before the feature is finished, not after.

The practical consequence is that "certification" should never appear as a single task on a launch sprint board. It should appear as a lane that starts weeks, sometimes over a month, before the sprint that ships the feature to players. Everything else in this article is really an argument for that one structural change: stop estimating certification and start scheduling it as an independent, parallel track with its own start date, its own owner and its own visibility separate from the launch sprint.

Who is actually on the hook for certification, the studio or the operator?

The operator is. That's the detail most certification guides skip, because they're written for the studio handing off a finished game, not for the product team receiving it. Under the UK Gambling Commission's testing strategy, the licensee, meaning the operator, is contractually responsible for scoping what gets tested and cannot release a game to players until the resulting test report has been submitted to the Commission (Gambling Commission). The studio building the game doesn't carry that obligation. You do.

That single fact should change how a product manager thinks about certification entirely. It stops being a vendor deliverable you're waiting on and becomes a workstream your own team scopes, books and tracks, the same way you'd own any other release gate. If your roadmap treats certification as "something the studio handles before handoff", you've misassigned the risk. The studio can certify the RNG and math model in isolation, but the operator still has to scope the full submission, including how the game integrates with your platform, your bonus engine and your responsible gambling controls, and that scoping work doesn't start until your product team initiates it.

This has a direct roadmap implication: the certification lane can't be delegated entirely to a compliance function that only gets looped in near launch. Compliance owns the regulatory relationship and the submission mechanics, but product owns the timeline, because product is the only function with visibility into when the math model will actually be frozen, when the game will be feature-complete, and which sprint the launch is meant to land in. That's the same sequencing discipline that shows up in how we think about product strategy for complete products, components and features: a workstream with an external dependency needs an internal owner who tracks it end to end, not a handoff that gets rediscovered every time someone asks "is this launching on time".

Reframe it plainly: certification is not a box the studio ticks before the game reaches you. It's a submission you scope, a queue you book into, and a report you're legally accountable for having in hand before you can release. Own it as early as you'd own any other release-blocking dependency.

What happens when you change an already-certified game?

This is the part almost every certification guide misses entirely, because they're all written about launching new titles. The re-submission trigger doesn't care whether the game is new. Under the Malta Gaming Authority's prior approval requirements, adding a new game or changing an RNG requires a separate prior-approval submission, with its own fee, even under an existing licence (Malta Gaming Authority). A live, already-certified, already-earning game that gets a math model tweak isn't grandfathered in. It goes back through the same gate a brand-new title would.

Most roadmaps treat certification as a one-time cost paid at launch. It isn't. Every material change to a certified game's RNG or math model resets the clock, which means your live-ops calendar needs the same certification lane your launch calendar does.

What counts as "material" is worth being precise about, because this is where teams get caught out:

• RTP or paytable adjustments. Rebalancing a slot's volatility or payout table after live data comes in is exactly the kind of change that triggers prior approval, not a quiet hotfix.
• RNG or math engine changes. Swapping the underlying random number generation or the math model that drives outcomes is treated the same as certifying it for the first time.
• New game variants sharing an existing engine. A "deluxe" or regional variant of an already-certified title is still a new submission if the math model differs, even slightly.
• Feature additions that touch outcome generation. Adding a bonus round, a jackpot mechanic, or anything that changes how or when the RNG is invoked is in scope, even if the core game feels unchanged to players.

The roadmap consequence is that certification can't be a lane you open once per game and close at launch. It has to stay open, or be reopenable, for the entire live-ops life of every certified title. A product manager planning a Q3 rebalance of a top-performing slot needs to budget lab lead time into that plan exactly as if it were a new launch, because from the regulator's perspective, in the jurisdictions that require prior approval, it effectively is one.

Why can't RNG testing be rushed to hit a launch date?

Because RNG testing is a statistical process with a minimum sample size, not a checklist a tester can speed through under pressure. The UK Gambling Commission's RTS 7 standard sets out the specific bar a random number generator has to clear: uniform distribution across outcomes, unpredictability of the next result, non-cycling behaviour over the long run, and fair seeding of the generator itself (Gambling Commission, RTS 7). Each of those properties needs enough generated outcomes to be statistically demonstrated, not just observed a few hundred times and judged "probably fine."

Compressing the schedule doesn't just risk a failed test. It risks an invalid one, because a test run stopped early to hit a deadline may not have generated enough samples to say anything statistically meaningful either way. That's a materially worse outcome than a delay: a report the regulator or your own compliance team can't actually rely on.

RTS 7 requirement	What it checks	Why it needs time, not effort
Uniform distribution	Every possible outcome occurs at the statistically expected frequency over many trials	Requires a large enough sample to detect deviation with confidence; a small sample can look uniform by chance
Unpredictability	The next outcome cannot be inferred from prior outcomes	Needs sustained sequence analysis, not a spot check on a handful of spins
Non-cycling	The generator doesn't repeat a detectable pattern over its period	Only detectable by running well beyond any suspected cycle length
Fair seeding	The generator's starting state isn't itself predictable or manipulable	Requires testing the seeding mechanism independently of the output stream, adding a distinct test phase

The practical takeaway is that RNG testing has a floor on wall-clock time that no amount of internal urgency changes. Your team can compress the sprint that builds the feature. You cannot compress the sample size a valid RTS 7 test requires. That's the clearest argument for starting the certification lane at math model freeze rather than when the feature is otherwise done: the lab's clock and your sprint clock are unrelated, and pretending otherwise is how launch dates get missed by exactly the length of a rushed, then re-run, test.

Tips: If your RNG changes even slightly between the version sent to the lab and the version you ship, tell the lab before they finish testing. Retesting a swapped build from scratch costs more time than a short delay to align versions.

How do you build a certification lane into the roadmap?

Building the lane is mechanical once you accept it has to run in parallel rather than sequentially. Here's the sequence that actually works:

1. Freeze the math model and RNG first. Nothing else in the lane can start until this is locked, because it's the artefact the lab actually tests. Treat this freeze as a milestone on the roadmap in its own right, not an implicit side effect of "feature complete."
2. Book the lab slot the same week you freeze it. Don't wait for internal QA to sign off first. The slot booking and internal QA should start on the same day, because the lab's queue is the longer of the two clocks in almost every case.
3. Run internal QA and the lab's process in parallel, not in sequence. Your team continues testing the wider game, integration, UI, RG controls, while the lab independently tests the math model and RNG. These don't need to wait on each other.
4. Track the lab's turnaround as a fixed external dependency on the roadmap, visible next to the launch sprint. Give it its own swimlane in whatever tool you use, distinct from feature work, so a delay in the lab reads as exactly what it is: an external dependency slipping, not a team missing a sprint commitment.
5. Treat the submission of the report to the regulator as the actual release gate, not the completion of lab testing. The Gambling Commission's rule that the operator can't release until the report is submitted means the gate is the paperwork landing, not the test finishing.
6. Hold a buffer between expected lab completion and your intended launch date. The lab's stated turnaround is an estimate for a queue you don't control. A buffer absorbs the difference between the estimate and reality without pushing your announced launch date.

This sequencing is the same discipline that underpins good prioritisation generally: you sequence around the dependency you can't compress, and you let the things you can control flex around it. Our piece on RICE, ICE and OKR frameworks for prioritisation covers the same principle applied to feature scoring: the fixed constraint should shape the plan, not get squeezed to fit a plan made without it.

How should certification timing differ across a multi-jurisdiction launch?

A single-market mental model breaks the moment a launch needs to clear more than one regulator, because each jurisdiction runs its own prior-approval regime, its own lab relationships and, in some cases, its own technical standard for what counts as compliant. Assuming they all move in lockstep is how a multi-market launch quietly becomes a single-market launch with delayed markets nobody planned for.

The sequencing question isn't "which market do we launch in first" so much as "whose lab queue is longest, and which approval blocks the others." Book that one first.

Jurisdiction factor	Planning implication
Regulator with the longest typical lab queue	Book this slot first; it sets the floor for your earliest possible multi-market launch date
Regulator requiring prior approval before any release	Treat its sign-off as a hard gate, not a parallel track, for that specific market
Markets sharing a common math model and RNG	One certification result may be reusable across them if the labs and standards accept cross-recognition; confirm this before assuming it
Markets with distinct technical standards	Plan for a separate, non-overlapping test cycle rather than assuming one report clears every market

The roadmap version of this is a dependency map, not a single timeline: which jurisdiction's approval gates which markets going live, and which markets can launch independently of the others once their own approval lands. Treating a multi-jurisdiction rollout as one certification event with one date is the same planning error as treating a multi-team initiative as one deliverable with one owner. Our writeup on how we ran Q3 planning for Keep.Social covers the same underlying discipline: sequencing dependencies explicitly, market by market or team by team, rather than assuming everything converges on the same date by default.

Tips: Ask your lab directly whether a test report from one jurisdiction's standard is accepted, in full or in part, by another before you assume you need to run the process twice.

What should product managers track once the lane is running?

Once certification is a standing lane rather than a launch-sprint task, the risk shifts from "we forgot to book the lab" to "the lane is running quietly and nobody's watching it." A lane that's off the launch sprint board is easy to lose visibility on precisely because it's no longer competing for attention in sprint planning.

• Lab slot dates, for every game currently in the pipeline. Not just the next one due, all of them, since a lab delay on one title can cascade into the booked slot for the next.
• Which live, already-certified games have pending changes awaiting prior approval. This is the category most teams don't track at all, because it doesn't feel like a launch and doesn't sit on a launch sprint board.
• Which games are mid-resubmission and in which jurisdictions. A game can be approved in one market and still pending in another after the same change, and shipping the change everywhere at once without checking this is a compliance risk, not just a scheduling one.
• The gap between expected lab completion and the buffer you built into the launch date. If that gap is shrinking, that's the earliest signal a launch date needs to move, well before the lab actually misses its estimate.
• Ownership of the report submission step itself. Since the operator, not the lab or the studio, is on the hook for actually submitting the report to the regulator, someone specific needs to own confirming that step happened, not assume it did.

This is the operational layer that makes the lane durable rather than a one-off fix for a single launch. If your team is building this tracking discipline for the first time, or wants a second pair of eyes on how the lane should sit alongside your existing roadmap process, that's the kind of structural product work we help teams with directly. You can see the range of that work on our services page. Which changes actually count as material is its own question, covered in Feature Flags Don't Make an Update Minor.

Frequently asked questions

How long does game certification actually take? Most public guides cite a range of roughly four to twelve weeks, but that figure describes the lab's own testing window, not the total time your roadmap needs to absorb. The real planning number depends on when you start the clock: booking the lab slot at math model freeze, rather than after the feature is finished, is what actually determines whether that window causes a delay.

Does every game update need re-certification? Not every update, but more than most teams expect. Under the Malta Gaming Authority's rules, changes to a game's RNG or math model trigger a fresh prior-approval submission even for an already-live, already-certified game. Cosmetic or UI changes that don't touch outcome generation typically don't trigger this, but anything affecting RTP, paytables or the RNG itself does.

Can internal QA and lab certification run at the same time? Yes, and they should. Once the math model and RNG are frozen, there's no reason your team's broader QA, integration testing, UI checks, responsible gambling control testing, needs to wait for the lab to finish its independent RNG and RTP testing. Running them in parallel is the core mechanism of treating certification as its own lane.

What's the difference between certification and prior approval? Certification is the lab's technical testing of the game against a jurisdiction's standards (RNG behaviour, RTP, and similar). Prior approval is the separate regulatory step of submitting for permission to release a game, or a change to one, in a specific jurisdiction. You typically need certification to support a prior approval submission, but the submission and the regulator's sign-off are a distinct step with their own timeline.

Should certification live in the same sprint as the game launch? No. That's the core argument of this article. Certification should start as its own parallel lane the day the math model is frozen, running alongside development rather than being nested as a task inside the sprint that ships the game. Treating it as one sprint task guarantees the estimate is wrong, because the lab's queue doesn't move at sprint speed.

Who should own the certification lane, product or compliance? Both, with different responsibilities. Compliance owns the regulatory relationship and the submission mechanics. Product owns the timeline and the sequencing, because product has the visibility into when the math model will actually freeze and which sprint the feature is meant to land in. Leaving the lane entirely with compliance, disconnected from the roadmap, is how it goes quiet until a launch date is at risk.

Sources

• Gambling Commission: Testing strategy for compliance with remote gambling and software technical standards
• Gambling Commission: RTS 7, Generation of random outcomes
• Malta Gaming Authority: Prior Approval Requirements

Recommended

• Product Strategy for Complete Products, Components and Features
• Product Prioritization: RICE, ICE & OKR Framework Guide
• Q3 planning done right for Keep.Social
• Explore our services