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.

Setting up the database has no customer value by itself, so preferably it is not a story of its own. The database implementation should be part of the first story that needs it. Or ideally, the database is implemented in phases: with Every story you implement the part that is needed to make that story work.

(That doesn’t mean you can’t do the design in advance. You probably should)

In general: Dependencies between user stories are very common. The team will estimate a certain story in the assumption that some other story is already done. (Best to take note of these kind of prerequisites). This happens all the time. If the planning changes, and the prerequisites of a story no longer apply, then the team should get the opportunity to re-estimate.

I’ve run into this problem a number of times and never found a perfect solution.

But I have found that the least imperfect solution is to have a separate story. The difficulty is in how to word it. You need to do this in conjunction with the user, so that they know this story doesn’t produce anything visible, but it does allow you, the programmer, to provide other useful stories for them.

“As a shop owner I want to store information about products I sell” doesn’t really convey that point very well. It implies that the end user will be able to store those details.

If your stakeholders are good at understanding that developers are also stakeholders in the product, you can put it to them that a story such as “As a programmer, I want to store and retrieve information about products that my customer sells, so that I can complete tasks #132, #133, #134.”

When a user sees this in the current iteration but not tasks 132, 133 or 134, they’re going to know that this isn’t something you can demonstrate to them at the end of the iteration, but they will be satisfied that, next iteration, they’ll be able to get those tasks done, cheaply. This is usually enough.

You should, as a matter of course, demonstrate such tasks to each other, at the end of an iteration, as you are the primary stakeholders for the task.

As a bonus, this mentality leads nicely onto conversations about technical debt stories like “As a programmer, I need an improved API for the XYZ services, so that I can develop against them more rapidly.”

Note that I’ve added a “so that” clause to each of my story examples. This is a good practice for stories, even when they’re more clear-cut than the example we’re discussing. The business value of a task is at least as important as what the user needs to be able to do to gain that value. This becomes exponentially true as the number of stakeholders grows.

I would avoid using story dependencies, it leads to a slippery slope. As has been said before, how do you know you need a database. Perhaps flat file or something similar could work for your situation.

Creating the database upfront/early is not really a good option as that will severely limit your options for the code.

I would move forward by using Mocks, XML or some other light weight data input mechanism for the development. Then as the overall design for the code begins to evolve, you can use the Mocks/XML as the basis for your database design. The mocks are not throw away, as they can be used later for automated validation of code changes. Does the creation of the database even need to be work done in an iteration? Is it possible to review the Mock structure with someone who could create the database based on the mocks and provide it at an agreed upon point in the future?

Story-wise, you may want to think about breaking down “As a customer I can search product catalog” even further? How do they search the product catalog, by Product ID, Description, Color, Size, Price? As written, I would say the story has a high probability of taking more than a single iteration to complete.

Finally I would suggest reading some of Scott Ambler’s material at [http://www.ambysoft.com/scottAmbler.html][1]

[1]: http://www.ambysoft.com/scottAmbler.html Scott has done a lot of work regarding databases and how they relate to agile.

Cheers!