A Sprint is a planning cycle. It’s a short-term plan (and, although the Scrum Guide no longer uses this word, I prefer it: commitment) to achieve a goal that adds value for stakeholders. Epics and Stories represent changes to the system’s features/functionality and quality attributes.

I’d start to use the idea of Spikes to handle investigation tasks where the objective is to make a decision or learn some information before delivering a value-added capability. Spikes are time-boxed in hours or days. Some teams attempt to fit them into Sprints while others have them live outside of the Sprint, not aligned with Sprint start and end dates. No matter what you do, realize that your team’s capacity to deliver functionality will be reduced if a Spike is ongoing. You may opt to put the Spikes into the Product Backlog and/or Sprint Backlog, as well, and prioritize them and have Epics and Stories dependent on their completion.

As far as your Sprint Goal goes, I’m not entirely convinced of its usefulness. As you are seeing, your Sprint could be some combination of delivering functionality (creating software, standing up hardware, etc.) in the form of completing Epics and Stories and learning something new (architectural trade-offs, regulations, languages or frameworks, etc.) in the form of completing Spikes. Based on priorities, your Sprint Backlog could cross-cut many aspects of a software system, making it difficult to write a concise goal. In my view, all Sprints have a goal: to deliver value to the customer and users by meeting your Definition of Done for each completed Story. That value may be in functionality or in an increase in knowledge of the team to make better decisions going forward.

Based on what you’ve said I simply think Scrum is not suitable for you. You’re trying to massage sprints as tasks and they’re not designed for that – they’re timeboxes to ensure people demonstrate progress regularly. Unfortunately, they’re particularly bad when progress cannot be measured in time periods longer than the scrum, or when a task takes longer to complete than the sprint (which will happen with external consultants).

A better approach for you would be a modified Kanban – where tasks are run in parallel anyway. If you assume a task can be ‘parked’ when sent off to a consultant to allowing more than the prescribed number of in-progress tasks 9ie a parked task doesn’t count as in-progress) then I think you’ll have a much more manageable (and obviously understandable) process.

There are plenty of other Agile processes out there, I would seriously consider any one of them over Scrum. I would recommend you at least investigate the alternatives.

Thanks for good thoughts, I have been taking them into consideration.
What I see is the best option is to stick with SCRUM even if it is not optimal when working with consultants.

@Thomas Owens My experience as scrum master has shown me that when a sprint contains various features that are not really related to each other, it is hard to have good retrospective meetings afterwards. They tend to be vague is my experience.