I always understood that in agile, each sprint is about adding a new functionality to existing application, so that the application can be build incrementally.

On the other hand, when you define data model, you need to think of many possible use cases and functionalities upfront, so that data model satisfies wide range of them and performance of CRUD operations is satisfying. This is usually a case when starting a new project. It might be hard to modify data model later, incrementally, because far too many existing functionalities might be bound to it. I'm used to waterfall methodology in this case.

So how those two conflicts methodologies can be combined together when defining an initial data model? Or there is some third way?

  • 1
    If your domain / data model is relatively simple you can develop it incrementally from sprint to sprint. Otherwise you either need some upfront design before the development sprints start, or you dedicate one sprint or two to redesign / refactor your model later into the project.
    – Giorgio
    Nov 19, 2014 at 20:11
  • I'm liking the answers here. Also check out the classic Eric Evans book on domain driven design that focuses quite a bit on modeling.
    – Kyle
    Nov 20, 2014 at 12:31

2 Answers 2


You do just enough modeling up-front to feel comfortable moving forward responsibly. Defer as much modeling as you can until you don't feel comfortable deferring it any more.

How do you know how much can be responsibly deferred? Experience.

A basic premise behind Agile development is that you don't waste effort doing things that don't provide value. Obviously, proper data modeling provides value, and needs to be done.

But, history has proven that trying to plan/model everything up-front commonly leads to designs that, if strictly adhered to, don't end up providing the value that was expected.

Alternatively, if the plans have to change, then the effort spent on the initial design may have been essentially wasted, and could have been spent on something else.

Agile development is an art that leverages experience to minimize the wasted effort by responsibly deferring certain design decisions until those decisions need to be made, and we have the best information with which to make our decisions. That is seldom at the very beginning of a project.

If, in your case, you feel that it is irresponsible to move forward with any part of your application until your entire data model is done, then there's nothing in Agile that would keep you from doing that. But, most Agile practitioners would say that such a situation is rarely occurs.


This is similar to the architecture of the application itself. Instead of doing all the architecture before starting the project, you do only what you need, and then you change it, incrementally.

The same applies to data model. If you're developing an e-commerce website and start by the functionality of displaying products, you will need the corresponding data model which describes how products are stored, but you don't need the data model of users, or shipment, or newsletters yet.

This let you focus on the actual problem you have right now (displaying the products), while keeping away of things which are not defined well yet and may change over time.

For example, your customer may decide a few weeks later that he don't need you to implement any newsletter any longer. If you've spent three hours designing the data model of newsletters before starting the project, you have wasted three hours of your time (plus the time required now to get rid of this part of the model).

Note that changing the existent schema based on the small changes in the data model can be very painful (imagine if you have to switch the IDs of products from GUIDs to bigint while your e-commerce website is already used in production). Moving from databases with strict schemas, such as Microsoft SQL, to databases which are less strict, such as MongoDB, can be a solution.

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.