Variable sprint length VS multiple goals ?

Hi, I see a few red lights in your description:

• Overfocus on maintaining people busy - "(...) so that the team has enough work to work on (...)  if I have one single goal the team might not have enough work (...)"
• Referring to rules that do not exist in Scrum - "(...) according to the scrum framework the sprint length shouldn't vary."
• Focusing on efficiency, not effectiveness - "(...) I know we should have one single goal to improve efficiency"

When you for example take care for a soccer team, would you focus on handing over every member a ball during the match so that they can do something productive? I bet you won't. So why are you worried that someone would not have "enough work"? There are plenty of things to do to help the team as a team member, other than focusing on the next task - for example, refinement of the Product Backlog. If I as one of the Developers "have nothing to do", maybe if I focus on refinement, I will find a way to split bigger items in a way that enables us to actually have a more consistent Sprint duration. However, I also can simply pair with other developers and help them with the work.

In the Scrum Guide, you will not find any rule that prohibits using different Sprint lengths for respective sprints. The Sprint duration is fixed for the running sprint, not indefinitely. You can easily decide together whether the upcoming Sprint will be shorter or longer. However, the Sprint can not be longer than one month - that is the rule written/implied in the Scrum Guide.

One single goal improves effectiveness, not efficiency. If you can focus on one thing only, even if that means that sometimes you "have nothing to do", improves overall team effectiveness in achieving a selected goal.

There is no paradox here, as in Scrum we are not focused on ensuring that everyone has enough work to do. We rather are focused on ensuring that as a team we are able to create useful Increment by the end of the Sprint - or to be more precise, to create something of value together, to turn ideas from the Product Backlog into a value within the product.

IMHO The sooner you will stop bothering yourself with finding work for people, the quicker you will truly become a team that can actually get and create value from using Scrum 😉

We currently have to develop small features and fix bugs

I'd suggest otherwise: what Developers have to do is to ensure bugs don't arise in the first place. That's a commitment to the Definition of Done, and it's a commitnent which you haven't mentioned.

You don't "have to" develop small features either, or big ones for that matter. Scrum is about learning to build the right thing at the right time. Work is pulled, not pushed, and a good Sprint Goal will mitigate a significant risk or uncertainty in this complex challenge.

There's no evidence to suggest the Sprint length is currently wrong. Scrum isn't a reductionist process where work is broken up and chunked down into Sprints for delivery. It's more experiential than that. We face complexity and empiricism is needed. Every time we deliver something we must know the quality is there, and has not become another variable. That's the missing piece and the key to the supposed paradox you describe.

Something to consider about variable length Sprints is how it can erode the benefits of consistency for the Scrum Team and Stakeholders.

Scrum Guide on Sprints…

“They are fixed length events of one month or less to create consistency.”

Consistency and structure in our events reduces the cognitive and administrative load, allowing us to focus on the work. Our problems to solve are complex. Why add complexity to our processes by worrying about scheduling and re-scheduling events?