How granular a BDD feature should be?

Let's talk about something simple. We have a TODO list, we want to add tasks to the list. What is the feature and what is the scenario here?

a.) we are probably talking about a class or a set of services feature: todo list scenario1: adding a new task to the todo list scenario2: trying to add a new task, but fail due missing task description

b.) we are probably talking about a method or a single service feature: adding tasks to the todo list scenario1: adding a new task scenario2: fail due missing description

Solution

I think that the whole concept of BDD is not related to the number of classes, methods or variables whatsoever. It's all about the conversations with the stakeholders.

What you're calling a feature, is probably the thing that triggers that conversation in the first place. For instance, we have a TODO list, but it's no use to anyone if it's empty. So a feature would be to have the ability to add tasks into the TODO list.

From here, the conversation begins, and most likely you'll come up with the "happy path" for your scenario:

Given that the TODO list is empty
When I add a new task "Buy Milk" to the list
Then the TODO list should have 1 task
And its description should be "Buy Milk"

Then you might start asking more questions to your stakeholder:

Do I need to be logged in to add tasks to the TODO list?
Do I need any permission to add tasks to the TODO list?
Is there a maximum tasks that a TODO list can hold?
Can I add a task with the same description as an already existing task in the TODO list?

All these questions are going to create your scenarios, which you'll need to describe in Gherkin with your stakeholder's help and then code it up to get them to pass.