As I understand, the idea with Agile methodologies is that you deliver something functional and you deliver it often. The application gets into its final shape increment after increment.

But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users.

What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?

  • 2
    Building an entire framework or foundation should be a decision made as late in the project as possible.
    – JeffO
    Jan 7, 2014 at 18:05
  • @JeffO: what do you mean as late as possible? Can you expand that into an answer?
    – JohnDoDo
    Jan 7, 2014 at 19:17
  • 5
    Ideally, it shouldn't be a decision at all. A framework shouldn't be created, it should emerge organically as a result of refactoring. No "good" (for my own subjective definition of "good") framework was ever designed from scratch, they were either extracted after the fact from existing applications or based on other frameworks that were. Jan 8, 2014 at 2:38
  • 7
    @JohnDoDo building a foundation upfront assumes you know what the requirements of your application will be before it even exists. Every time I've seen people do this, they wound up with something that was rigid and very difficult to work with. More often than not, the users of that "framework" wind up fighting it more than embracing it. Jan 8, 2014 at 11:59

7 Answers 7


It is typical to have 2 week sprints.

For me, the first sprint or 2 will likely have less "visible" features than later sprints for this exact reason (for some tenuous description of "less").

That being said, it certainly should not take you 2 weeks to build your entire scaffold and have nothing in the UI visible to show for it.

Maybe you do not flesh out every scaffold item in the first sprint or 2. Maybe parts can wait and be added later.

Maybe your first sprint has "Create webpage X with dummy data" so that you can get something shiny to show your customer. And then the next sprint has "Change webpage X to use data from the database".

  • 6
    +1 for the last paragraph - it is a good idea to start development with a prototype intended for user validation.
    – Konamiman
    Jan 7, 2014 at 15:55
  • 4
    "Maybe your first sprint has "Create webpage X with dummy data" so that you can get something shiny to show your customer.": IMO it depends on the customer and on the project's time scale: For a 2 month project, a customer may want to see something in 1 week or 2. For an 18 month project, one may find it OK to get a first demo in 1 or 2 months. In any case, while some customers may like to see a dummy page, others may want to see something more meaningful and get the feeling you are wasting their time. I think you cannot generalize.
    – Giorgio
    Jan 7, 2014 at 16:33
  • 4
    +1, but always, always keep the iceberg secret in mind when showing UI parts to your customer joelonsoftware.com/articles/fog0000000356.html
    – Doc Brown
    Jan 7, 2014 at 17:42
  • 1
    @MatthewFlynn - Scrum may not have a true "requirements" phase, but that doesn't mean there are ZERO requirements or documentation available. I've never been involved with a project where a customer said "just go ahead and start building and we'll figure it out along the way". I think there's a term for that. Usually there should be some kind of elicitation phase of a project which includes some discussion and agreement as to what is going to be delivered. I've presented prototypes during the sales pitch
    – hanzolo
    Jan 8, 2014 at 0:12
  • 1
    @hanzolo - A very successful project I worked on recently involved implementing a solution to deal with a new legal requirement that was part of the Affordable Care Act. The basic requirements were known, yes, but there was nothing in the way of a prototype or design in place as to what the solution might be. The project team (which included business analysts) figured it out within the context of the sprints. At best, the BAs would be talking to business folks about stories a sprint or two ahead of the rest of the team, but that was all we had to work with. It worked well. Jan 8, 2014 at 5:52

The Agile Manifesto suggests that Working Software is more valuable than comprehensive documentation, and the Scrum framework takes this notion to suggest that delivering tested, working software with business value to be a requirement every sprint.

Why? Well, among other things, designers and developers often fall victim to spending lots of time on YNNI (you'll never need it) items. Unfortunately, those frameworks you are talking about are often a big liability in this area. The developers start building in all the stuff that the framework MIGHT have to support and suddenly you are 3 months in and don't have anything of business value to show for it. Then it turns out the framework doesn't even really support what they end up needing.

So the suggested approach is to build only what is actually needed now, and deliver it now.

This does NOT mean that you can't build reusable parts and the like, you just always do it in support of building a current need. Moreover, it does not mean you have to completely wear blinders to what's coming down the road--don't build things so that it's impossible to change/enhance them later. But the key is to always be delivering business value.

There often are some key things that absolutely need to be established before anything can be delivered, such as setting up environments and the like. For these things, a lot of teams find it useful to have a "Sprint 0" in which the groundwork is laid. Sprint 0 can be a bit longer than your other sprints, in that it is not applied to your product backlog or burn-down, but it should still be time-boxed to a reasonable duration.


What gets delivered to the client in these first iterations?

What has highest business value for the user. For example, if the applications has complex business rules, the first iteration(s) will only contain those business rules encoded in the form of code. Customer should be satisfied as long as you have code for those business rules. (The problem of actually persuading customer to accept such a thing is completely different matter.) For example, you might show the customer's business experts your unit/acceptance tests that express what the domain should do and that code passes it with green result. Or even better, make the business experts help create those tests.

There is also question of

you might build the framework or foundations

Which I believe is much more important than what is actually delivered. There is big thing for Evolutionary Design, which says, that you should create the architecture over time instead of trying to create it in the beginning. As for foundation, this usually means some kind of database or UI framework. In which case, there is idea of "Good architecture is one which allows you postpone important decisions." And choosing database or UI is an important decision. For example, you might be fine with just in-memory storage for data instead for trying to use DB from the very first iteration.


What we try to do is to deliver in the first iterations the simplest application possible (a hello world version of what we are delivering). We see 3 important benefits in this:

  • Setup the delivery procedure (always one of the most difficult parts imho) (get environments, servers in place, update security for this environment). As we will deliver often, it is important to get this right as soon as possible.
  • Give the users a first glimps of how the application will look like. This helps the users and the developers to understand what they really want and need.
  • Have a basic idea about how the architecture of the application will look like (the application should cover the basic 'layers' or components of the application).
  • "Set up the delivery process" is much harder than people think. Jan 8, 2014 at 9:35
  • Yes it is. That is why you should do this as early as possible.
    – user99561
    Jan 8, 2014 at 13:12

You can deliver pretty much anything you want. The building the infrastructure idea is simply wrong/not agile/unsustainable.

For example: building a fully functional Hello World app can be built in hours. Bringing up a server (even temporarily) in the cloud or as a VM can be done in hours.

These are enough to start developing. Then, if you need CI, you can add a CI story, if you neeed a physical server, sure, add a story for that.

But start delivering on Day 1 and never stop!


But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users.

This is wrong, since you do not need to build a framework you may use in the future. The idea is to build only what is needed (see also YAGNI).

In the sprint zero, you need to prepare for the real work. Lots of people argue what should be done in this sprint, but in my opinion, it is finished when you can start working on the items in the backlog. This step includes setting PCs, setting build process, picking frameworks, etc.

When you are done with sprint zero (or iteration zero), you can start working on your application. Take items from the backlog, and finish them one by one. After you finish iteration one, you are going to have something useful. The first iteration usually includes some of most important features.

What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?

After iteration zero, obviously you do not have anything to deliver. The deliverable comes after iteration one. It contains features that you set for the iteration.

If your question is "how to pick what goes into iteration X?", then take a look into these videocasts (videos for iteration 0 A and part of B).

  • +1 for being the only one to mention iteration zero
    – crad
    Jan 9, 2014 at 23:48
  • I do not consider setting build process and picking frameworks tasks for sprint zero. How can you know which framework you need if you don't know what to build? I always limit sprint 0 to a bare minimum. Get people PCs and find a space where they can sit. Find out who you need to talk to from the business. Setup a first planning meeting. I apply YAGNI to the rest.
    – user99561
    Jan 10, 2014 at 8:51
  • @user99561 Frameworks are big decisions, and usually hard to change. For example, you should know whether you are going to use gtest or cppunit for unit tests before starting to write code. Changing it later is going to be huge pain in the ass and lots of time wasted. Jan 10, 2014 at 9:13
  • @BЈовић : Yes frameworks are big decisions, that is why you should postpone the decision. There is no point deciding on a framework if you don't know what needs to be developed and how the application and architecture will look like. You should decide on what framework to use on the last possible moment. Otherwise you definitely run the risk that you have to change it.
    – user99561
    Jan 10, 2014 at 13:43
  • @user99561 If you do not know what needs to be developed, then you can not even start :) The requirements and user stories have to be written down, otherwise the iteration 1 can not even start. Jan 10, 2014 at 14:35

Early iterations, especially the 1st, will contain or should at least plan for architectural spikes, which include a certain amount of discovery time and maybe some architectural prototyping.

Like you said, generally, there are structural requirements which may not mean much to the stakeholder / customer, but are required to form a strong platform or pattern orientation. You cannot get around this as you can't start building B until A is complete.

Part of the Agile approach is to have the customer close so documentation is not needed because all you need to do is pick up the phone / send email, and it's expected. The customers expectations should be set appropriately and any work completed should be very terse and NEEDED. No gold plating, no "You might need it", etc.. Build what you need in A to move onto B.

Depending on how you're attacking the project, you may only build out the required foundation in order to complete a certain module, so during the sprint planning meeting you would lay out the plans for the current sprint based on the priorities set forth by the customer, depending on what is needed for that sprint, there may be some foundational requirements, so that's what goes into sprint 1. After the 1st sprint is complete and A has been built and then plan to complete B.

If you've agreed on a timeline with the customer, as long as you're going to meet that agreement, the customer probably won't care what you do 1st or 2nd. You could always show them the unit test results, but if you say we'll have something for you to see after sprint 2 (or 3), and you deliver, it will set a strong precedence. Customers are expected to be reasonable as much as developers are and both are working towards the same goal. A completed project which meets the needs of the customer and works as expected. So worrying that there's nothing to see after sprint 1 is a moot point because the customer just wants to make sure that after sprint 20, the project will be done(-ish).

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.