In story 1, I would just state what operations the user can/wants to do on data already present on the device, and add an explicit note that the origin of the data is out of scope for the story (possibly with a reference to the story that handles retrieving/updating the data)
Your own suggestion for story 2 looks reasonable, and story 3 could be something like ", but I don't want Joe Random User to be able to access those [entities]". That should give you the incentive to add the authentication feature, so the real user can prove he/she is not Joe Random User.
@thecapsaicinkid wrote in a comment:
If I'm splitting my stories in a way which requires me to fake data, is this an indication I'm not splitting in a helpful way?
Not necessarily. If the story that needs the fake data and the story that replaces the fake data with the real data are in the same sprint, it is not a problem at all. At the demo it should not even be noticeable that half-way down the sprint fake data was used.
If the two stories get scheduled for adjacent sprints, it would at most be a minor annoyance that the result of the first sprint can't be meaningfully deployed to the end-users. It might become a problem if the story to provide the real data gets pushed further down backlog, but that is not very likely.
A 'thin slice' which relies on fake data has value to the business;
they can see the application working. But it has practically no
benefit to the end-user. Should I try and simplify my slice even
further (maybe a simpler UI) so I can find the time to get some real
data into the system and have an app which does at least something
useful to the end user?
It depends and should really be discussed with the customer representative.
Sometimes it would be better to slice an epic in vertical slices (several stories, where each story contains both data retrieval, manipulation and UI). And sometimes you just have to accept that it is impossible to split an epic in multiple stories that are all on their own relevant to the end-user.
If that is the case, don't worry too much. The customer representative will most likely understand the situation and try to prioritize the stories such that the entire epic gets completed in as few sprints as possible (it is in their interest as well).
