Making short iterations work is hard. First the team has to find the right amount of work and commit, only to be confronted with reality and find out that the estimates are not what they meant them to be.
In the first days of the iteration (T-8) the top priority stories get tackled, and somewhere in the middle of the iteration (T-5) the team has a pretty good feel, of which stories have a good chance to get accepted, and which may fall off the iteration or get split.
This last part of the iteration is what our team calls the End Game. The End Game starts 3-4 days (T-3) before the end of the (2 weeks) iteration. This is when we start deciding, which stories can be accepted, which may be split, and which may be moved to the next iteration. The rule of thumb we adopted is that once we enter the End Game, we do not take new stories if there are other stories in the works that have higher chances of acceptance.
This simple rule helps the team concentrate on completing top priority stories and the associated bugs first and then move onto new work. We found that this leads to a much better outcome rather than have many stories open at once and than struggle to split them or move them to the next iteration.
Another effect of adopting the End Game rule is that it raises the team awareness of what it takes to complete the stories with highest chance for acceptance. This is when team members that have completed and accepted their assigned stories, start asking the question: “How can I help other stories so they get accepted?”.
Tasks get reshuffled, pairs form to tackle difficult tasks, conversations with the product owner take place to set priorities. Work gets done-done.