Scrum doesn’t really care about the type. A Feature, story, bug, thing, item, use-case… Anything can live on the product backlog. So it doesn’t really matter what you call them.

The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be comfortable that they’ll be able to finish by the end of the sprint (which doesn’t necessarily mean that it’s fully defined, as long as the team knows they’ll be able to refine the final things during the sprint). That’s the idea behind just-in-time planning and refinement. Items lower on the list may have a lot less detail as you still have time to refine them over time.

If you’ve chosen to use User Stories as your format, then there is generally a certain level of detail that still makes sense, then the next level is generally specified in useful test cases or acceptance criteria.

You should look at writing your acceptance criteria for your stories, the latter ones really feel more like the more detailed steps you described. Specification by Example and the “Given…When…Then…” notation would fit really well.

Only break down to a level that’s needed to provide your level of forecasting and estimation. If a specific acceptance criterium would cost a lot of extra time, you may break it down into it’s own story. You can always break it down at any later point in time, so only do it if you need it broken down now to set the order of implementation.

Remember that as you’re refining your backlog over time, you may indeed get to a detail level that’s closer to you BUFD level, but if you do, make sure that it’s in some form of executable specification or in the form of test cases that you want executed, that way you don’t create a lot of duplicate work.

Tools like Specflow and Cucumber can really help in doing this. Your specification is automatically mapped to Unit tests and integration tests so that you will automatically see when the work is finished by looking at your passing tests. That takes away a lot of the waste that’s associated with the traditional use-case definitions. It also allows your stories to be written at a high level, then as you go into details, it’s specific and easy to validate.

My experience; Although there is a ‘bug/defect’ object in RTC (the collaboration tool used to capture user-stories in my workplace) for the most part my associates tag everything as a general ‘task’, regardless of whether it can be considered a bug (or group of bugs) or a non-bug task.

We do have a Trac-style tool to keep track of the discovery and resolution of bugs as well, but when we take on those bugs, we replicate the description in RTC, and usually just list it as a ‘task’, for purposes of uniformity. It may seem counter-intuitive to describe bugs in two places, but this is useful for hour tracking if nothing else. And listing everything as a ‘task’ helps the higher-ups with their queries… At least, that’s what they tell us.

So an example SuperEpic might be Open Source Proof of Concept, Epic could be Email app on Android, the story would be Composing and Sending, and a task would be Compose screen should show recipient instead of sender.

With regards to your use case… Is it a bug? Sure. Is it a user story? It looks like one. Why not both?

That’s my opinion, anyway. But you asked for it!

First, I think that the use of the term “bug” is a bit off. There are some questions here on Programmers about this (1, 2, 3). Generally, the word “bug” refers to a defect in code. The software does not do what we expect – it crashes, it produces incorrect results, or something along those lines. I prefer to use the word “defect”, and this other answer suggests “error” as the correct term, when it comes to discussing a broad categories of issues that arise in the development process.

Rather than trying to classify your change as a unique user story or a bug, I’d classify it as a defect in your original user story. Your original user story or some aspect of it, such as the acceptance criteria, the task breakdown, or perhaps just a breakdown in communication that lead to a misunderstanding – regardless, it seems like the activity of gathering and decomposing the requirement was the issue.