13 pointer story

When we ask them to break it further, they say, they can break it but the QA won't be able to test them individually

...

P.s - Yes, we have a separate QA. and that's how it is. 

Then let's leave the "separate QA" out of the picture for the moment. If the team can break the item down, how would they test it themselves during development, so they are satisfied that it works correctly?

What is stopping the organization to have at least 1 person with QA skills in the Scrum Team?

What is the role of the separate QA in this environment? If the role is to ensure that the system is stable and reliable from an end-user perspective, then I would argue that they don't need to necessarily test every single change. Some changes may not be visible to an end-user. In cases like this, the regression testing of functionality and performance is sufficient to accomplish the purpose of QA to ensure that stability and reliability won't be compromised.

It's not uncommon that a particular feature, to be useful, is very large and can't be completed it one Sprint. In cases like this, you can use techniques like feature flags (feature toggles) and keystone interfaces to hide the implementation of the feature in production, yet be able to review thin slices at a Sprint Review, outside of the production environment. After the feature is finished to a point of adding value, the feature flag can be toggled or removed, exposing the functionality to all users in the appropriate (or all) environments. This also lets the QA team develop their test cases earlier so they are ready to execute with a higher confidence of passing when the feature flags are toggled and the keystone interface is in place.

For an approach like this to be successful, there needs to be an emphasis on quality from the whole team. The Development Team needs to appropriately test the slices of functionality within the Sprint Timebox and the separate QA team can focus on ensuring that the configuration intended for production will not have any issues as the team iterates behind a feature flag.

My advice is to go ahead and break down the work into things that can be designed, developed, and tested in the Sprint by the Development Team, working with the QA team to obtain feedback on the changes behind the feature flag or keystone interface so it can quickly be rolled out after the last pieces of valuable work are done.

P.s - Yes, we have a separate QA. and that's how it is. 

Since QA is separate that indicates to me that their activities is not part of the Sprint and that your Definition of Done does not include it either.  So how the Development Team deals with the stories to create a potentially releasable increment of value is up to them.  In your case the "release" decision seems to be release to QA.  I would expect that the Development Team would only release something that they feel is of high enough quality to give to end users. But taking into acccount whether QA can test everything doesn't seem like a necessary criteria. 

The Definition of Done needs to be clear about what the Development Team means when they say they are done.  

When we ask them to break it further, they say, they can break it but the QA won't be able to test them individually hence no point as it will then defeat the DOD. 

Are these broken pieces of a functionality individually releasable ? If not , then how DOD is defeated taking into account DOD applies to an increment as a whole ?

Also, if they happen to break it, they raise a PR so that the team can review the code written, then as well they cant move the tasks since a PR can be raised when the entire 13 pointer work is completed.

How about slicing the work in a way that each slices can be delivered separately with compliance to your DOD? 

Check this out  - https://www.thoughtworks.com/insights/blog/slicing-your-development-work-multi-layer-cake