Why I want to differentiate between "iteration" and "sprint"?

Project sponsors want to control the development process. Why? Because they care about the investment and want to ultimately ensure it works toward the goal. For that matter, the only thing they can do is overseeing the development process and adjust whenever it is off the direction to the goal.

The traditional process model, typically the "waterfall" method, doesn’t provide enough check points, and the sponsors has little control over development process. But things changed when iterative methods get popular. Iteration methods essentially break down a big project into smaller, controllable pieces, and the sponsors have many check points to look at and adjustment points to take action.

“Divide and conquer” again is the silver bullet here even though it doesn’t come easily to decompose a project since no matter how you break it down you always get the pieces with complex relationship among them, and such relationships will result in recursive of works and cascading of problems.

“Iteration” comes into play here as a common strategy to decompose a project. First off you don't know all requirements upfront but you do know certain things to kick start a project, and assume along the development you'll know more and deeper. An iteration is defined and planned based on a set of confirmed requirements. A whole project, which is set to fulfill a business needs, is divided into multiple, progressive iterations. And the result of an iteration could be adjusted by following iterations (the spiral metaphor). The point is iterations are defined through requirements efforts. In an extreme case that you know all requirements upfront, the project is broken down into a single iteration.

In Agile practice, “sprints” are often considered equally as iterations. But they are substantially different. A sprint is special terminology in Scrum referring to the development efforts related to user stories that are selected for the sprint backlog. A sprint commonly engages around a 2-week time-box with certain resources, and should not be interrupted from outside until it is done. In other words, a sprint is a “working unit”.

The question is how requirements (mainly user stories but may have other forms) are translated into working items? Per user story is not a workable item but rather a functional requirement, which needs to be translated into work items. This transformation has to come from integrated design efforts. And the design efforts come just-in-time as soon as requirements are confirmed, i.e. design goes with iterations, rather than sprints or stories.

By breaking down a project into iterations, every iteration is a mini-waterfall with business sense and value. Designs, UATs, and releases are planned in this layer, while sprints are scheduled under iterations for productivity and velocity management.

In summary, I want to differentiate iteration and sprint because I desire to convince to incorporate design and other higher level of planning (such as testing and releasing) into Agile development process.