After working Scrum(ish) in a previous workplace, I am trying to implement it in my new place of work for a brand new project (I am no scrum expert). We have some pre-requisites to code before we can begin working on the stories (which are being groomed in the mean time). Things like database design, api design, etc. We plan to use two week iterations and it's just not clear to me how the first one (or two) can provide something useful to the customer and "potentially shippable" if we first have to "lay down some groundwork" ? Any ideas on how to treat this?

-----edit / rephrase-----

How do we incorporate initial non client-visible preliminary work (e.g., database design, api, etc) into the Scrum process?

  • Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking.
    – gnat
    Jul 21, 2013 at 12:54
  • 1
    What is your role in this new project? Are you part of the team?
    – malte
    Jul 21, 2013 at 19:23

4 Answers 4


Of course you need to have some technical prerequisites in place before you can start a project. For example, you need a solid working environment, a decision which technology to use (programming language, frameworks etc). Wrong decisions at the beginning of the project could slow down or even cause the project to fail, so one should be very smart about them. It is the responsibility of the team to make the best decision there.

Do not spend too much time on it though. The real job is to finish things for the customer. And this is only accomplished by creating customer-facing features, not by designing some detail of the application or creating the infrastructure the project needs to run at all.

You will always find something to tweak in the DB schema that just is not perfect, yet. Or there simply is not enough testing infrastructure, yet. This is not a particular "beginning of the project problem". The same goes for the architecture. Target on scaling the architecture rather than designing a lot up front. There is a great talk by Mich Lacey on exactly this topic which I would recommend to watch. It illustrates how you could approach this.

Create a mindset where you concentrate on finishing not on polishing things and think of every technical detail as exactly that what it is - a technical detail. It does not interest the customer (and should not interest the customer) a single bit.


Treat it like any other story. Having stable design benefits the customer. Having schema design benefits the customer. Describe what you need to have done, and what the deliverables are. Prioritize them between technical staff and the product owners, then pull them off and complete them.

Another thing to consider is that these technical stories are similar to technical debt issues that likely have more commentary/research about them.


I'm worried that you have separated the design / API from user stories - it is a good idea to consider how things are going to evolve, but I feel this work should be incorporated into the stories, not segragated from it.

It sounds to me like you are scared of the words 'potentially shippable'. This does NOT mean that what you build can be shipped to the customer to use, merely that the result of the sprint is actually 'Done' - that is tested and production quality.

It can be the case in larger projects that the first sprint/s the result has absolutely no meaning to the customer, but if you can at least say 'This database has been built so that we can do X' or something similar, or even run unit tests that show 100 little green lights, they should understand the usefulness will follow soon enough.


If you're working on something like choosing and setting up source code control, I would say that you are not open for business yet. An analogy would be that a restaurant has to set up its kitchen before it serves customers. You could still use the scrum process, but the focus would be getting ready to start instead of meeting customer needs.

"We have some pre-requisites to code before we can begin working on the stories." The previous sentence cuts to the heart of the problem. You are planning to work on something for the customer, but what you are working on is not a story.

It is important to work on what the customer needs.

I suggest that you validate with the product owner that you are correct in thinking that they do not expect something in two weeks. Whether they say yes or not, what is important is that you are aligned with the customer.

Based on what the product owner says, I suggest one of two options

  1. If the project needs something done quickly or is likely to change requirements in the future, I would suggest only doing enough design to meet the current iteration's story.

  2. If the project has fairly high (3 months of work or more) amount of stories to be useful, or is not likely to change requirements in the future, treat the database design as a spike. The risk to the customer is that you might design something that the customer decides not to implement.

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.