Ideally, a Sprint should provide a coherent increment of functionality. In practice, teams may pull in stories that aren't aligned with the singular Sprint Goal, but this requires advanced Scrum-fu. Even when pulling in additional stories, some strategies are more successful than others, and great care must be taken not to violate core Scrum principles while doing so.
One Sprint Goal per Sprint
One of the most overlooked requirements of the Scrum framework is the need for a Sprint Goal to guide each iteration. The canonical definition of the Sprint Goal is described here:
The Sprint Goal is an objective set for the Sprint that can be met
through the implementation of Product Backlog. It provides guidance to
the Development Team on why it is building the Increment. It is created
during the Sprint Planning meeting. The Sprint Goal gives the Development
Team some flexibility regarding the functionality implemented within
the Sprint. The selected Product Backlog items deliver one coherent
function, which can be the Sprint Goal. The Sprint Goal can be any other
coherence that causes the Development Team to work together rather than
on separate initiatives.
— The Scrum Guide, Schwaber and Sutherland, p.10
The text takes a bit of parsing, but the core concept is that a Sprint Goal is the foundation of the iteration. A Sprint doesn't fail or succeed based on how many stories are done or not-done at the end of the Sprint; success only comes from meeting the objective defined by the Sprint Goal.
If your Sprint Goal is "do a bunch of stories," or "complete this, that, and some other thing" then you lose the very essence of agility. The team isn't able to work with the Product Owner and the stakeholders to find an optimal way to reach the stated goal; instead, the team is forced to find success only through 100% completion of prescriptive work breakdown packages.
Exceptions, Always Exceptions
Each Sprint should have a singular Sprint Goal, and the success of the Sprint is based on whether the Sprint Goal has been met by the end of the iteration. However, because a Sprint is a fixed-length time-box, sometimes the team will have extra capacity available after meeting the Sprint Goal. This leads to several options.
Option 1: Early Termination Strategy
The first option is for the Product Owner to call for an early termination to the Sprint. If you have a month-long Sprint, but you meet your Sprint Goal in a week, this is certainly a sensible thing to do. However, early terminations carry process overhead, so if you run into this situation often you should reduce your Sprint lengths and save early terminations for truly abnormal circumstances.
Option 2: Fill Excess Capacity Strategy
The second option is to ensure that the team only commits to stories related to the current Sprint Goal, but uses any extra capacity remaining after the Sprint Goal is met to peel additional stories off the Product Backlog. This is obviously done in cooperation with the Product Owner, who works with the team to identify user stories that:
- can fit within the remaining Sprint capacity, and
- can add value to project if bumped to the top of the Product Backlog.
The Fill Excess Capacity strategy is the one that experienced teams generally find most effective. It preserves the integrity of the Sprint Goal and keeps the iterative cadence stable, but also provides much-needed flexibility to the process. Remember, Sprints are all about maintaining a sustainable pace of development over time, and the primacy of the Sprint Goal is one of the most effective ways to set that pace properly.
The 100% Utilization Fallacy
Of course, some teams fall prey to the 100% utilization fallacy and assume that the goal is to keep the team working at full capacity every iteration, regardless of the need for process slack or flexible business objectives. Such teams will typically fill their Sprint to the brim based on historical velocity patterns or arbitrary management targets.
There are lots of problems with this approach, including a reduced focus on the product increment and a reduced ability to adapt to changing business objectives. It also makes it very hard for a team to determine whether or not a given Sprint was a success. At the end of a Sprint, even if you completed 100% of the stories and kept everyone busy 100% of the time, without a cohesive goal how do you know that you built the right thing?
In some domains, this framework rule can be broken successfully, but it certainly complicates the process tremendously. If your Scrum-fu is sufficiently advanced that you can break this rule by leveraging your inspect-and-adapt cycles, measuring success properly, and keeping a sustainable pace—well, go right ahead.
There are certainly cases where multiple goals or cross-goal Sprint Planning can work, but it's like juggling chainsaws. I don't recommend it—unless you're planning to use your death-defying juggling act to join the circus, of course.