Use-case: a Jenkins deployment on internal LAN, corporate IT won't allow incoming connections - so no webhooks. Polling must be used to find and build new code from public or corporate SCM systems.

• Prerequisite: have a Github (or Stash) organization with some component repositories, each has Jenkinsfile pipelines in master and other branches - and those pipeline scripts define a speedy polling frequency (H/2 .. H/5)
• On Jenkins: create a New Item / Github Organization (AFAIK backed by Branch source nowadays - at least I have no Github Organization plugin installed anymore)
• point the setup at desired organization
• have it scan the org, find repos, set up MultiBranch pipelines for the repos, scan repos, find branches, find Jenkinsfiles, set up jobs for each matching branch.
• Review that the final jobs have the frequent polling in their read-only configuration, and that it is indeed honored (add a commit, see it built in a couple of minutes)
• Add a branch or PR against the monitored repo... and wait a day for it to be found!
• When it is finally found, see the subsequent additions to the branch (or origin of the PR) get discovered and built as frequently as set up via Jenkinsfile.

The problem highlighted here is the implicit 1-day polling rate of the generated Multibranch pipeline jobs, which is not editable (it works well as expected in manually created MBP jobs).

Our current workaround is to either wait the day for non-urgent PRs, or to manually trigger a "build" of the generated MBP job so it rescans the repo and finds new PRs/branches to build. Probably a regularly running Jenkins job with a bit of groovy could be made to that effect as well, by capable devs  But the preferable solution would be to have that default (1-day) frequency actually just configurable from the organization-level job.