In a perfect world, all tasks are broken down into small enough pieces such that they can be completed within one iteration, but this can't always be the case for large stories.
For example, consider a back-end web service where the user story is:
“As a web service client I can search for payments in the back-end mainframe using a web service call, with a customer ID and a date range as search keys”
The web service developers might know they need to spend two iterations worth of actual effort to complete the task, but because the mainframe developers are not permitted to work in an agile manner, the elapsed time will be more like seven iterations worth. In fact they will start all these long tasks on the first day of the project by scheduling some meetings with the mainframe team.
So do they estimate seven iterations worth of story points for the story? No, only two, so that the burn up chart is still valid. For the purposes of roughly ordering the development pipeline, the story should be scheduled in the iteration it will be completed in, not when it is started.
