There was recently a discussion on an internal distribution list that caught my eye. The initial question was; when should you add more to a sprint instead of ending early? At first glance I think it is safe to assume that while the person asking the question claimed to be doing scrum he had missed a few points. One being; you keep the sprint length for a very long time. IMHO there is no ending sprint earlyin scrum. You keep your sprint length fixed since you want to measure the number of user stories (or story points) the team can complete in one sprint to make a release plan and estimate what will get into a certain release. So far I don't think there was a lot of discussion to happen but the question had some more information that made the question more interesting. Turned out that the team consisted of 8 people and they planned 4 user stories in the sprint. This meant two people was working on each user story for the duration of the sprint. And the question was more about what to do when one user story was completed. Do you bring in a 5th user story or do something else?
Basically there are two options; Either you bring in a 5th user story or you have the "free pair" helping the rest completing the planned user stories. This is when it gets really interesting since I don't think there is a simple answer. Or actually there are two simple answers; It depends and you decide. The important thing is that the teammakes the decision and that they make an informed decision. There are also a few traps an inexperienced team (i.e. a team learning Scrum) can walk into so the Scrum Master may want to prevent the team from making some decisions in some situations. These are a few things the team and Scrum master should consider:
In my opinion the situation described in the question is wrong from the start. Starting all 4 user stories at once and having pairs more or less working in silos on "their" user story for the duration of the sprint does not sound agile to me. It sounds like old fashioned silo/code ownership practice that is a bad investment for the future of the team. I think the majority of the team should swarm on the most important user story and then a few can start on the second most important one. By working on all 4 at once the team is risking to complete none. Top priority is to complete at least one user story, then two and so on.