Minimum length of a sprint and sprint goal

Officially there is no clearly defined minimum, but you have to consider the time it takes to hold retrospectives, planning, and backlog grooming as well as the (presumably largest) phase of actually doing the work.  Also, since new sprints start at the end of the previous sprint, having sprint durations that aren't a multiple of 5 days means having them start and end on different days.  Inconsistent timeboxes are not ideal.

In my opinion, I'd draw the line at 1 week (5 days) as a practical minimum.  Yes, you can technically manage shorter sprints, but I think Scrum loses a lot of its effectiveness when you attempt to do this.

As for the second question, regarding what happens if sprint backlog items don't seem to match a sprint goal, my understanding is that you could potentially approach it in three different ways:

• The Sprint Goal doesn't accurately reflect the goal for the sprint, and should be revised.
• The original Sprint Goal is no longer relevant, and the sprint should be canceled.
• The Sprint Backlog items don't match the Sprint Goal, and should be left in the Product Backlog for a future sprint.

The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

My question was based more on the assumption that there are no other PBIs that can relate to the sprint goal in such a way that multiple PBIs can be picked up from the product backlog to successfully run a 1 week sprint. What if we have multiple items that are not related to a single goal and are estimated to be a few hours worth of work. Would we not waste an entire sprint for such small tasks? Then, in such a case would we have to make an exception like a Scrumbut?

In the situation you describe, is there sufficient complexity left to deal with which would make Scrum useful?

@Ian Mitchell, Good point! I would say there isn't much complexity, therefore would such items have to be dealt by another framework like Kanban?

That leads me to ask, what if there are no more items left in the product backlog (assuming that the product still exists)? Is such a scenario possible?

Conceptually, the Product Backlog will exist for as long as the product exists, although at times it may be empty.

Based on that there would be no sprints until the product backlog has items again, is that right?

I wouldn't think so, Steve.  What would your potentially releasable increment look like if you had no backlog items?

If you're wondering about the technical "scrum way" to handle this, the Scrum Guide would prefer that you cancel the sprint for having an obsolete (nonexistent) sprint goal, over and over.  Or, it would tell you to close out the project and open a new project for the same product once have enough backlog items to perform a couple of sprints.  If you think those options sound inefficient and messy, you're right.  Scrum doesn't play nicely with "downtime."

In reality, where time and money aren't infinite, this wouldn't work very well.

The Development Team may continue Sprinting but for a different product. There's nothing to stop teams from alternating between products in different Sprints according to demand. The Sprint Goal in such cases may be to service enhancements for a particular product being worked on. The complex environment may thus lie not in the specific product but rather in the range of products to be supported.

"The complex environment may thus lie not in the specific product but rather in the range of products to be supported"

That's a good way of putting it, and in that case, I agree with you, Ian.  Thank you for the clarification.  In a complex environment (and not a complex single product), moving the team over to another product would meet the definitions of Scrum a lot more cleanly, and probably be the preferable way to handle it over the much messier product-based methods I had suggested.

I also see the primary cause for my confusion, which I'll share for anyone who falls into the same thought process.  Scrum guide states both:

"Scrum is a framework for developing and sustaining complex products."

and

"Scrum (n): A framework within which people can address complex adaptive problems"