How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.
Scrum informs the customer that their ticket will be processed in the next sprint or not. It gives visibility into the future. A Kanban backlog, which is unordered, only tells them if their ticket is being worked on now.
Putting a ticket into a sprint is the same as putting it into a queued stage of kanban for purposes of reporting, although the reported number will differ (“this sprint” vs mean cycle time with percentile bounds.) Both methods can have unordered backlogs where something can sit indefinitely.
(Many orgs are understandably nervous to automatically report a simple number as an estimate; in those cases, you could translate cycle time into a date range estimate so long as you’re not also expected to report “we’ve started” etc. since those won’t necessarily line up.)
It provides less granularity and visibility, but it provides regular, well-defined touch points.
OTOH, nothing stops you from having biweekly reviews with customers in Kanban, or delivery goals on the same cycle that guide decisions of which work items to pull in and whether to allocate more effort or defer ones that run into unexpected complexity. There’s no reason to (and plenty of reason not to) build a work-should-end and then new-work-items-should-start cycle around that; continuous flow makes more sense.
Even in Scrum, a Sprint Goal is not a batch of tickets, and for kanban the period re-evaluation of goals/priorities can be even less like that. And, of course, a review can be whatever there is to review.
What I am saying is that, insofar as cyclical touch points are a valuable customer-interaction feature of Scrum (and even when doing “proper Agile” with daily interaction with the customer as part of development, which is more an exception than the rule in most “Agile” places I’ve seen, the fact that “the customer” is usually an organization and the ideal daily interaction is individuals at the working level, not whole-team-to-whole-team level, those periodic touchpoints are useful) you can have them in Kanban while maintaining continuous flow as opposed to sprint-oriented flow in the development team.
