Lest's say I have user stories about using product catalog in shop:
- 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.
I can express db creation as:
- another story: As a shop owner I want to store information about products I sell
- Task to be done in story which will be firstly chosen to do
In first case I create story dependency, in second I wondering where estimate this additional task. Let's say it adds additional two story points. To which story should add this points? All (and re-estimate remaining stories in the future), none? I think that second option also can hinder estimation – I have to remember to add this story points to dependent stories and then possibly remove it.
How to deal with such situations?
Best Answer
The correct solution is number 2.
Agile estimation is by design much less precise than waterfall:
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:
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.