I'm not throwing shade on sprints altogether. They can be effective, but, like The Bachelor, you need to be sure you're using it for the right reasons.
This poorly named tool is really misunderstood. If weilded poorly it can do real damage to team health and sustainability. If used properly, the team gains momentum, protection, and metrics to help tune their workflow.
A sprint is not a deadline. Not completing all work in a sprint is an opportunity to learn and improve, not an opportunity to begin the blame game.
Velocity is not a tool you can use to measure the performance of a team. It shouldn't be used to push a team beyond what they are able to accomplish. If velocity is used as a whip to drive the team forward, people will not do their best work, burn out, and leave.
A sprint isn't a race. You're not running full tilt the entire time. In fact, it is more valuable to leave some space in a sprint than everyone fill themselves to bursting. Extra room is more time to help each other, write tests, code review, and most importantly to think.
Sprints can't have dictators. I've never met an engineer that was happy to pick up step-by-step instructions on what to build and how to build it. I've met many engineers pissed off by dictatorial sprint planning where they have no voice. Sprints aren't a free-for-all; if done well, everyone's needs are fulfilled by sprint end.
The main benefit from sprints is the sprint backlog is locked during the interval. If the sprint backlog isn't really locked, and folks can slip work in, you've lost the biggest bonus working in sprints gives you. Change is that damn constant every project has. The more complex a project is and the more tolerant to change it needs to be. Sprints, and the locked sprint backlog, is one way to manage change.
Sprints rally everyone around a goal. After sprint planning the team should be aligned to their goal and have a good understanding of the work ahead. They can focus in on the sprint backlog and ignore everything outside of the sprint. I don't like assigning work during planning. Letting work items float lets people focus on where they're needed most, or what interests them. The whole team can reflect at the end of a sprint, and use what happened to improve the next sprint. All of this means good team health and collective ownership over the work. That translates into value through increased momentum, more innovation, and room for great work to happen.
The sprint structure can be used to improve continuous delivery on a team. To do this, aim for a consistent throughput sprint over sprint and continuous deployments within a sprint. This assumes the team has found a stable velocity and you have the proper tooling to deploy at any time. By using Story Points and Velocity metrics you can tune the cadence of work on a team. Velocity can't predit when things will be done in the future, but it does help tune the system for a more predictable cadence.
First, ask the team. A lot of engineers, designers, and product folk are used to and most comfortable in a sprint structure. Beware of any baggage people bring from previous gigs. A lot of bad managers have used sprints for evil.
Sprints are structure. Sometimes adding more structure to a team helps them do better work.
A team should be iterating constantly. After a few sprints a team has learned things about how they work together. The team will use these learning to adjust the sprint structure to meet their needs. This could mean iterating away from sprints.
If I were to start a new project today I would first figure out what the team was familiar, comfortable, and wanting to use. I'd look at the history of the team, and histories of individual members. From there I would look at the type of work we'd be doing; how complex and unknown it is.
Team wants to use sprint + Team worked together before + Work is high complexity/unknowns = Sprints
Team doesn't want to use sprint + Team worked together before + high complexity/unknowns = No sprints
Team doesn't really care + Team worked together before + High complexity/unknowns = Kanban all the way!
Doesn't care + New team + High complexity = Sprints to start, quickly iterate to what works
Any low complexity project = Choose the best project management lifecycle. Often you'll be best with up front planning and staged delivery on a low complexity project.