"Let the user import legacy data", though, is not a one-sentence description of a feature demo. "Import a transaction list file in version 1.0 of the format and show that it loads all entries," would be more like it.

It is also going to lead to wildly different implementations developer to developer unless they have a really solid understanding of the project. And given how frequently we turn over, that rarely exists.

I usually don't really know anything about how the code I write will be used in practice.

You can't stop at the user story. Actually that sentence is not a user story at all.

It just says 'user' which is way too generic.

It's missing the "why" which can inform the developer a lot about the actual AC for this story both when discussing the story prior to starting estimation and later when it turns out that some AC is unclear or missing.

The 'standard' format of 'As a <type of user> I want <do X> so that <I can do/get/see etc Y>'

Of course it's very possible to write utterly bad user stories in this format too and to write good ones that do not follow it slavishly.

So why do these users want to import legacy data and who is this user?

Let's say this is an import that only ab admin can do.

As an Admin I can import legacy data.

Better. Let's say our system only has one level of admin so that this is actually completely clear and not ambiguous.

So why does he want to do this? Since we don't know the context you had in mind I will invent one. Let's say that this is an on premise (not cloud/SaaS) issue tracking system that and it has an export feature and we want to be able to import from the old legacy format that has since changed. People routinely use this export/import to create a data dump for backuo purposes and the problem is that only the same version of our software can read them.

As an Admin I want to import legacy data so that I can use old data dumps from previous versions in a newer version instance.

Much better. Let's add some imaginary AC:

* should be able to read version 0.8 to 1.3 data formats (no need for <= 0.7 as those were EOL'd 2 years ago)

* add to both current master as well as the release branches for 1.4 through 1.7

* user should be able to import any size file (we've routinely seen customers with dumps in the 2gb+ range)

* show a progress indicator on screen while the import is running

These could be some initial AC that can now be discussed with the team. The team might tell you that 0.8 had a real dumb quirk and if we could skip implementing that it would save us weeks of implementation and testing time. Also support it on 1.4 would suck because of that big refactoring that happened in 1.5 and it would basically mean writing the legacy import twice instead of cherry picking it with minimal conflicts.

And so on and so forth. Depending on how you work and what roles your org has there might be a design attached for the progress indicator and such or you're expected to whip something up. Or you tell the PO that he should check the current feature set because we already have a progress indicator there and this is just about adding new (old) file format support! And then he tells you that the indicator was only added in 1.6 which suddenly makes this a hidden backport of other features and you might split the story into more than one or say 'screw it' and remove that AC (you get the indicator in versions where it exists but no backporting).