Why need a "push" sprint for that, a "pull" priority queue like XP is just fine. Then demo every few weeks plus or minus, when there is something tangible to show.
I prefer pull systems and most teams I've seen that are more concerned about following Agile than following Scrum eventually evolve from Scrum to something that looks more like Kanban. If you regularly talk about how to make things better, pull systems tend to emerge.
But sprints are often a reasonable step especially for teams that are part of a large organization. It is often easier (and faster) to move a team from waterfall to sprints to a pull system than it is to go from waterfall to a pull system directly.
IMO Kanban (i.e. "pull") is better suited for reactive work (bug fixing, QA, support, ops, etc.).
There is a third approach: to give autonomy to the team so that it can distribute and perform tasks as it sees fit. There may be hints about priorities, such as a must-to-have or nice-to-have. See: Shape Up Method or Informal Mini Waterfall SDLC (design->plan->build(iteration)->ship) used by FAANG.
Once you have a written design document (especially if you wrote it yourself), you don't need a ticketing system like Jira. In many places we have only used tickets for bug reports and not for tasks.
Can you please show me a single example of a real company working under classical waterfall in the last decade?
NOTE: informal SDLCs, mini-waterfall, and RUP are not classical waterfall.
Agile™/Scrum® consultants implanted false memories to so many people. My colleagues who worked with me under lightweight flavor of RUP using an incremental approach, after getting Scrum Master certification now referring to it as "waterfall" ;)
