The value of a sprint is to help keep everyone focused on how to deliver something of value and usually this means working with the customer to figure out how to make sure you deliver the valuable pieces while deferring the pieces that can wait until later. So basically making sure everyone is able to work efficiently. If they are being used to try to make people work more hours every week, then they are missing the point.
Ah yes, the mythical customer that can tell you exactly what they need, and even prioritize it. This customer probably also can be bothered to give usable feedback on what you have built in a timely manner. But I've yet to see such a customer...
If there is no customer for the software that is being built, then there is no one who would be disappointed if it was not built. :). So the most efficient thing to do is to do nothing.
There usually is a customer. It may not be the person who is called the customer, but somewhere there is someone who is spending money on development and is wanting to be able to us or benefit from whatever is being produced.
If the customer doesn't have time to collaborate with the devs to provide feedback, it might be a sign that what is being built isn't valuable to them. This could be either because it doesn't address a real need or because the cycle time is so slow it isn't going to help them any time soon. When a dev team is working on the customer's biggest pain point and has a track record of delivering a solution in a few days, customers will magically have time to talk about it.
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" ;)
