What exactly is sprint goal while working on Maintenance/Support defects

Question

For a support project the sprints contains defects and hardly any enhancements, does sprint goal or increment still be applicable?

For e.g. my upcoming sprint has 3 defects:

 Defect 1 : Screen flickers on mouseover. 
 Defect 2 : Save button click not working. 
 Defect 3 : Report generation takes more than 30 minute for large set of records.

In this case what is my increment? What is my sprint goal?

The reason for the ask is, (as per guide) if the Development Team realizes that selected work will exceed the timebox of Sprint they have to collaborate with Product Owner to remove some work but they need to fulfill the below rules which for me doesn't makes sense:

• No changes are made that would endanger the Sprint Goal;

• Quality goals do not decrease;

• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Not sure but I hope my question makes sense.

Answer 1

My suggestion would be to pick a 'theme' for the fixes that is important.

For example:

This sprint our goal is to improve the user experience with search

The focus for this sprint would be the defects relating to search. There may be other types of defects being worked on, but the team knows that it is the defects relating to search that are key to the success of the sprint.

If there are no obvious themes then I would simply pick out the most important defect that needs to be fixed and make that the sprint goal.

Answer 2

If you are using Scrum, then you must have a Sprint Goal and produce a potentially releasable Increment by the end of the Sprint timebox. These are things that are core to the Scrum framework.

But you don't need to use Scrum. Perhaps Scrum, as it's defined in the Scrum Guide, doesn't make sense for your team as you are focused on support and maintenance. There are other ways to investigate, fix, verify, and deploy defects and even minor enhancements outside the Scrum framework and doing Scrum for the sake of doing Scrum is not agile.

If you want to continue using Scrum, though, my recommendations would be:

• Your Sprint Goal needs to be something that can help the team focus. The purpose is to help the team drive toward achieving some goal through the realization of Product Backlog Items. If the known bugs are your Product Backlog Items, what concise statement can summarize what the stakeholders are expecting from the potentially releasable Increment at the end of the timebox?
• Use Product Backlog Refinement to investigate and reproduce reported issues. If you can investigate and reproduce them before the Sprint where they are fixed, you can probably get a good idea of what it will take to fix them and this will help you choose Product Backlog Items for a Sprint and ensure that your Sprint Goal and Sprint Backlog are reasonable after Sprint Planning.