Techniques for Splitting User stories .

How about just letting the Development Team discuss the larger story and determine what they feel is the best way to accomplish the story while delivering incremental value?  Sometimes the best "technique" is just plain old communication.  I have found that to be much more effective than trying to follow a process.  Your development team are professionals, let them decide how to do their work and respect their decisions.

Find out what the Product Owner needs to learn about the item, as quickly as possible, in order to validate that continued development is on the right track. What are the smallest things that can be delivered which would provide those lessons?

Thank you for your comments, Daniel Wilhite and Ian Mitchell. But my question is not yet resolved because say the team is brand new and very much unaware of splitting user stories in Agile Scrum framework. They need some ladder or technique to get through and acquainted.

As Daniel said if I leave to the Development team then with traditional project model mindset they broke user stories in horizontal layer format. Which is not what Scrum guide advocates. Even though there is no such format in Scrum guide but user stories should give Value and user acceptance. So, now as a Scrum Master, it's my part to guide them on splitting the user stories. ..... Please suggest.

It could be helpful to look at the acceptance criteria, and to think of the major use cases that are to be tested.

If each of these use cases represents an opportunity for feedback, or some kind of delivery of value (no matter how small), perhaps it makes sense to split these down into a separate story.

Imagine the initial story is to allow us to write with coloured text on this forum. This could require various changes in the code. The editor I am using would need to support it, the page would need to display it, and there's perhaps some kind of separate tool used by Scrum.org staff to be able to edit replies. Depending how the tool works, maybe they even have separate functionality in their tool for editing the opening posts, and the replies in a thread. It might be that within this tool. Maybe Scrum.org also want to prevent certain colours being used (e.g. no white text because of the white background). Perhaps there need to be changes in an RSS feed or the search results to support it.

There could easily be more "requirements" in such a story, and each would need to be coded and tested.

One way to build something that can get feedback from some users, would be to implement a feature that only allows Scrum.org's staff to edit the colour of text within an opening post of a thread. The test cases can be simpler, because the feature would only exist on opening posts, and the impact of the feature can be controlled by collaborating closely with whoever edits posts at Scrum.org. It might not be necessary to restrict colours for this staff member, who can be trusted to use the tool in an appropriate way.

Feedback may be obtained from actual customers by using colours on the opening post of a thread on this forum, and either asking for feedback, waiting for it to come organically, or measuring user data.

Perhaps more importantly, having someone use the colour editing feature early, they might be able to tell the team where there are problems with the user experience, so that the team can develop something better, before too much time has been wasted.

Perhaps it turns out, after building the other features, that there's no need to prevent users placing white text on a white background (maybe real users are just not likely to do it). Perhaps that difficult piece of functionality, with limited value, doesn't even need to be done, because it's been sensibly split out.

Maybe the feedback from users is that colour editing isn't important for them at all, and it could lead to a quick decision to stop wasting time on this feature.

Do you mean, something like http://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flowchart.pdf ?

Mike Cohn offered  couple of free videos from his Better User Stories course:

https://www.betteruserstories.com/courses/better-user-stories/videos

You have to register with an eMail address, but I think they're still offered free of charge. The second video is on splitting with SPIDR. But lesson 1 on User Story mapping also helped me out a bit on identifying splits. After minute 13 it gets interesting.

Mike also recently posted a blog about complex User Stories that cannot be split:

https://www.mountaingoatsoftware.com/blog/how-to-work-with-complex-user-stories-that-cannot-be-split

The comments weren't very positive, but Mike commented back that the Progress Points could in some cases be seen as split criteria.

Hope this helps.

Thank you all for your comments. All are valuable. 

The crux of all the messages together I got is we can use these ways to split user stories:

a. SPIDR,

b. Back to front pattern i.e. splitting user stories based on acceptance criteria &Use cases, 

c. Based on an algorithm (pdf link shared by Olivier Ledru).

Great! But I was just thinking if it can have some pattern to make a more feasible way of splitting user stories and *Discover/Invent a new pattern or some kind of flow (apart from existing a, b, c points) within this great Scrum.org community, the way Scrum came to light for Project models.

Thank you all!