We do 2-week iterations, generally with a demo at the end of the sprint, and we're fairly strict about only allowing potentially shippable code into the demo. This can mean that stories often carry over into the next sprint because they haven't completely met their DONE criteria, even though the bulk of the development work has been completed.
We don't count points for stories until they have been completed, and yet we limit our points commitment during sprint planning -- which can sometimes mean that the carry-over stories take up the bulk of our points commitment. When this happens, we are left in a situation mid-sprint, where most of the cards have traveled across the wall into the DONE column, and we still have capacity left in the sprint.
When this happens, in theory, the team is meant to pick stories from the top of the backlog (which is, in theory, meant to be in priority order and with story points already estimated). The reality is that we try our best to keep that top of the backlog in order, and often it's just not ready to go. This can mean that the developers start to 'cherry-pick' stories that they feel like working on, rather than adhering to the priorities of the product owner.
We've just experience this situation in our last sprint, but we did something a little differently, which seems to have made a big difference: we held a mid-sprint demo, which we used as a checkpoint with our product owner, to make sure we were on the right track, do some user acceptance testing, and set the course for the remainder of the sprint.
In this case, we were building an admin tool, for use by the product owner. What we discovered during our mid-sprint checkpoint, is that the tool as it was currently built, was only usable on a developer's sandbox machine, required a whole lot of configuration and setup, and was generally fairly clunky. It was a (dare I say) painful session for all involved, which lasted nearly half a day, but at the end of it, we came away with valuable feedback and a stack of new cards to add to the top of the backlog.
Now, I'm not necessarily advocating adding tickets into a sprint midway through. Instead, what we had created was a clean, prioritised and estimated backlog which the team could go to once they had burned through what they had already committed to.
And it this case, it worked very well. In the end, we completed all of the carry-over work from the previous sprint (about halfway through the sprint), had our mid-sprint checkpoint, then completed an additional approx. 25 points over our usual velocity. By the end of the sprint, we had an admin tool which was very close to the finished product, certainly usable in a pinch, and can be polished in the next iteration.
