There are often debates between Scrum practitioners about whether to have a Sprint Zero or not. You can side-step the various arguments by redefining what the Sprint Goal will be for the first sprint, and by adjusting expectations of what will be demonstrated in the Sprint Review.
Sometimes, the drive to have a "Sprint Zero" seems like a need to have a tool-chain or architectural sprint without a concrete deliverable. If you dig deeper, though, the real goal is often to avoid counting the first sprint into your team's velocity. However, all project-related work should be carried on the Product Backlog as a visible cost to the project, so please don't fill your first sprint with invisible work.
The technically-correct answer within the framework is to ensure that the necessary architectural, tool-chain, and other infrastructure stories are included on the Product Backlog. For example, the Sprint Goal of the first sprint could be something like:
Install the development infrastructure needed to kick-start the project.
You might even need several such sprints at the start of a project; that's okay, too. The user stories accepted into those initial sprints would be selected to meet the defined Sprint Goals.
User Stories and Sprint Review
A literal interpretation of the Sprint Review process seems to make non-feature stories a no-no. However, this isn't really so. The process goal is to make progress (or the lack of it) visible to stakeholders, and to provide an inflection point within the project to gather stakeholder feedback. This generally works best with tangible or user-accessible features, but anything that you can demonstrate in a visual or engaging way will suffice.
For example, your team's first Sprint Review could certainly demonstrate developer-facing deliverables such as:
- The status screen of the project's continuous integration server.
- The web interface for the new source control system.
- A live demo of "Hello, World!" compiling with the team's tool-chain.
It is up to the team, including the Product Owner and the Scrum Master, to educate the stakeholders about the need for these project prerequisites. Sweeping these deliverables under the rug through the "Sprint Zero" mechanism is a way to side-step the need to educate the organization, but it ultimately cheats stakeholders and the team out of the full benefits of a transparent process.