I am working on a team that is exploring the possibility of adopting agile development practices.
One question that we are running up against is deciding when an iteration (sprint) should complete.
Let's say we've defined our feature backlog, and produced story-point estimates for them, and we have decided that the first 30-day sprint will include features A, B, D, and F. What should you do if at you're reaching the end of the sprint and you've completed A, D, and F - but B is only 80% complete. Should you:
Complete the sprint on time but exclude feature B (deferring the remaining work to a future sprint)
Extend the sprint by the time necessary to complete feature B but not start the next sprint.
Extend the sprint by the time necessary to complete feature B and begin working on the next sprint.
Fail the entire sprint, and bundle all work to be part of a future release.
The problem I see with option 1 is that the team isn't delivering what it committed to. In some cases, you may not be able to exclude feature B without making the entire release useless (or at least substantially less valuable). It may make it difficult to guide the direction of the next sprint without feature B.
The problem with option 2 is that some members of the team may be idle for a significant period of time - which eats into overall productivity. You may be able to add more unit tests, or polish features, but it doesn't add proportional value. It's also politically hard to explain to management why most of your team is idle.
Option 3 seems to be against the spirit of agile - you are putting the next sprint at risk by not allowing the results of the prior one to guide the next iteration of development.
Option 4 seems to severe and has most of the same problems of Option 1 and 3. First off, you're completely missing a commitment. Second, bundling more features into a subsequent release makes it harder to test and verify with customers - and it again precludes the ability to guide the future iteration based on feedback from prior ones.
Option 1 of course. Your velocity for the next iteration is going to be less, as it is based on yesterdays weather, so the next iteration you have a better chance of being complete.
In scrum you are time-boxing. And you only deliver features that work.
In the sprint planning you have made an estimate of what you could deliver. The customer has to accept a certain level of uncertainty in the estimate, or be prepared to have too many resources on the team.
If you miss the next iteration again, switch to a shorter iteration length, and make sure the size of individual features is smaller.