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:

  1. another story: As a shop owner I want to store information about products I sell
  2. 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?

4 Answers 4


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.

  • Points measure the complexity of a story - not the amount of work, or even less the time it takes - I'm not sure I understand what you're trying to explain. There is additional work, which will take additional time. Points are used with velocity to estimate how much can be done in a sprint. If you're not taking into account the extra work, won't you be underestimating cost and not having enough time in the sprint?
    – Izkata
    Commented Jun 3, 2013 at 2:55
  • In scrum, we don't estimate work, time or costs. We try to predict if a concrete and specific set of stories will fit in a sprint or not. Points are an aid to that, nothing more. We don't expect all stories with the same point score to take equal time at all, since the scope of each is renegotiated during the sprint to fit the time. It's a time-boxed methodology, thus we always keep time and quality fixed and scope negotiable.
    – Sklivvz
    Commented Jun 3, 2013 at 6:43

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.

  • However, equally ideally, you should be able to switch and change story priorities at-will. If you have three 2-point stories and a DB change adds 3 points to any of those stories, but they are not dependant on each other, the business might prioritise Story A at 5 points and then think that getting the other two stories done would be more valuable; they look and see 4 points and move Story A out of the way, not noticing the dependencies. What do you do?
    – pdr
    Commented Jun 2, 2013 at 22:21
  • This is pretty much what we've been doing - we give the additional points to whichever of the dependent cases is highest in the product backlog. @pdr - we make it clear to the product owner (who sits in on sprint planning) that this case has a higher estimate than the others because there's extra backend work, that can also be applied to the others.
    – Izkata
    Commented Jun 3, 2013 at 2:47
  • The cases then have comments on them so that if it and other dependent ones are pulled into the same sprint, the developer(s) who take them know why that one is so much higher (and can just do the work with whichever is done first). If two different developers try to start these cases at the same time, they pair program for the common part.
    – Izkata
    Commented Jun 3, 2013 at 2:49
  • Nothing wrong with estimating both scenarios (A after B and B after A). As long as you don't name db as a separate story. Because then the team will expect points after completing just that, which smells waterfall. Commented Jun 3, 2013 at 5:52

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.

  • You are rewarding the team points for a task that achieves nothing for the user. It will likely take the team two sprints instead of one to get to something useful. And the preparation story might get overfeatured to anticipate other future stories. Commented Jun 3, 2013 at 6:01
  • @KrisVanBael: I don't see points as a reward, I see them as a way of explaining to the business how much work they can expect done in an iteration. Thus I'm not "rewarding" anyone, I'm taking a pragmatic standpoint to facilitate the main goal of estimation.
    – pdr
    Commented Jun 3, 2013 at 8:38

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.