Agile – How should I break this user story into tasks

The correct solution is number 2.

Agile estimation is by design much less precise than waterfall:

• stories are "reminders to have a conversation" and they are incomplete and negotiable by definition
• the only purpose of estimating stories is to determine, more or less, what can be accomplished in an iteration, if you are using iterations
• estimates are basically useless in agile methodologies like Kanban, as long as the stories are small enough.
• there is no point estimating when a set of stories is precisely going to be done: stories will change, so detailed estimates must be avoided for long term goals.

In particular, creating the database is a task, an implementation detail, in the first story you are going to play. Tasks will be estimated (if you so choose) in hours, not in points, and they are estimated during the sprint and not during sprint planning.

Points measure the complexity of a story - not the amount of work, or even less the time it takes - and in my experience they are best seen as a "prize" that the team wins when they complete the story. Adding a database table does not really increase the overall complexity. Adding a database table is a detail which appears because of the specific point in time the story is played.

Asking "where do the 2 points go?" is meaningless. There are no "2 points" to go anywhere. The story is still the same whether you need to create the table or not, and it's perfectly normal and unavoidable not to know which all the tasks that need to be executed in order to complete the story are.

When I estimate, I don't know when a story will be played and what bit of the database will be in place when I play it, so there's no way out of this lack of precision. Again, let me stress that this is normal and unavoidable.

To be more specific, you say:

• As an administrator I can add/modify/delete catalog items (one or more user story, doesn't matter here)
• As a customer I can search product catalog
• As a customer I can view product details

Each of this stories rely on predecessor: design and create database to store product information.

But this is not true in general. You don't need a database at all. You could use, say, a service. You could install an open source component that takes care of it. You could decide to use a document database which doesn't require table creation. You could use a pre-packaged search service, etc. etc.

What you are doing is conflating the implementation details with the stories. Stories are not requirements. They must be more high-level than that! A customer will benefit from searching the product catalog, and the team should be expected to provide the simplest solution that satisfies the story (and the definition of done that you've set), which may or may not include a product database.

Since this is tagged scrum, you likely want to defer to a more detailed user story. If you were using something like XP or FDD, you can be a bit more agile because the milestone is not time-based.

With Scrum, you really only want to define the user story enough to be able to adequately give an accurate time estimate - however much definition that requires.

It really depends on the whims of the team and the stakeholders, but if you delineate 10 aspects or subfeatures of editing purchase orders, you aren't likely going to be able to add another once the sprint has been planned, and if one of those subfeatures is involved enough (like removing items from an order, possibly), it may need to be turned into a feature with a story of its own.

It's impossible to do Scrum perfectly, however the end goal of Scrum is not to remove all ambiguity, but rather to clearly define basic functionality to remove enough ambiguity to give a mostly accurate time estimate.