We have several user stories that have spilled over into multiple sprints. Some of them are fairly large and complex, requiring very high level of understanding of a) what we want, and b) the granular steps on how to arrive there.
The team has given them higher point levels, but haven't been able to really allot any hours, given the unknowns.
I've reviewed the user stories and could possibly slice them somewhat, but some of them really are just huge black holes.
What strategies as the Scrum Master can I implement to assist the team with being able to dissect these stories to reveal its done-able parts?
As an example, I have a user story that reads mostly as follows:
"As a user, I would like to upgrade to the latest CentOS7 version of Linux, so that I can ensure the security of my IT infrastructure by only running supported versions."
We have fairly complex home-grown software running on the current OS. The upgrade of the OS is multifaceted in that it needs to meet specific security standards, apply patch updates, regression tests to ensure that the software works as intended on a completely new operating system. Each of those, and there are likely many more high-level tasks, are going to require quite a few additional sub-tasks.
Another one (definitely breaks some basic Scrum rules):
As a Software Developer (I know...), I want to implement the rules engine logic discussed in user story 123456
The rule engine has approximately 15 bullet points as high level logic requirements, each with its own inherent requirements in order to make them work.
My initial thought would be, since the requirements are somewhat defined, to separate the units of work that are independent, small enough to easily fit into a sprint, and estimable.