In my case, I have always found that the level of details needed for full use cases come about by thinking through my user stories first. The first question I ask is "what do people need to be able to do?". Once I have the scenarios, then it's easier to start going through all the use cases and variants of flow for the system.
That being said, for a single developer who works alone, you don't really need to care about whether it's a use case or a user story or a sticky on the wall that says "don't forget about 'x'". What you need is any process that makes you think about what your users are trying to achieve and helps you track the different things they need to be able to do. Everything else is up to you as to the level of detail you need to write down in order to plan out your development.
For example, when I work on a solo side-project, my work tasks look something like this:
- View list of 'foo'
- Save selections from list
Honestly, each one of those would not have anything more on it than an estimate. Why? Because I'm just using them as a reminder of what I need to be able to have the user do and I'll figure out the details when I get around to that part. With a team of a single person, everything can be in your head and that is okay, because you don't have to communicate it to anybody else.
Now, there are caveats...
Single developer working with other specialists
Do you need to report on progress to another team? Do you have testers that need to validate your work? Do you have management that wants to know what you've done? Do you have a project manager that needs to predict a timeline? Do you have a product owner who is determining the features that are required?
If these people are part of your project then you need to make sure your work tasks have enough pieces of information on them to allow them to do their work. The PM probably needs a way of seeing relative sizes of things and progress through that work. Your testers will need details as to how things are expected to flow (use cases) and you may even ask them to help you write them. Management might want to know what it is you are working on, so you'll need enough of a business description so they can understand the features you are going to be delivering.
If you answered 'yes' to all those questions, you probably need to have a more rigidly documented backlog as you will be using it to communicate with the other members of your team.
- You will likely need to have the concept of 'Epics' or 'Features' that will be the high level functionality that you can use to report to management or your product owners.
- You will have nested User Stories inside those Epics/Features that
will define the smaller blocks of functionality that will be used to
communicate progress with your project manager, define your work
tasks within a sprint, and will be used to communicate the business
objective to the test team.
- You will have use cases or test cases defined for the stories to capture the various low-level flow decisions that are required to make sure that you, the business, and the test team are aligned and know what will be accepted as 'correct'.
All of the above can just be ignored if you are the one defining the work, managing the progress, testing the software, and deciding if something is 'correct'. Cut out the extra effort and make sure you are doing what is important: building working software!