Something our team has wrestled with over the course of our agile adoption is how architecture and framework development fit into our Scrum process.  We strive to deliver an increment of functionality to our client at the conclusion of each sprint.  However, in many of our early sprints, we have to do architecture and framework development.  The things we develop on these types of architecture/functionality tasks are not really useable by our clients and we really can't demo them either.  Brian Noyle recently wrote a post on his blog asking a similar question.

So, we've decided that the best of course of action is to strike a good balance between architecture/framework and functionality development.  In earlier sprints, we've accepted that architecture/framework will be a big part of what we're working on.  But we've also become cognizant of the fact that we need to show something to the client in terms of functionality.  So, we usually comb through the backlog and pick the highest prioritized backlog item that we can complete early in the first sprints, while still doing the architecture/framework tasks we need to get done.  In this way, we ensure that the client sees forward progress that they can touch and understand right out of the gate, and we build the architecture and framework to support future development efforts on the project.  As we progress through our development, architecture/framework tasks become fewer and our delivery of functionality increases steadily.  In graphic form, it looks something like this: