Share via

What to do when one user story is complete and all other user stories are on track

  • Article

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:

  • By  bringing in a 5th user story you may end up with a situation where not all 4 planned user stories are completed but instead one or two bonus stories are implemented by the end of the sprint. This can be both good and bad:
    • If you're actually releasing things after each sprint and/or you have communicated that certain things are going to be completed the customer may be unhappy if they get only 3 of 4 planned user stories even if 2 bonus stories are completed.
    • If you do not release after each sprint and/or the customer cares more about total amount of work completed rather than exactly when different things are delivered it may be good to deliver 3 planned and 2 unplanned things over 4 planned since 5 is better than 4.
  • Having the team focus on the planned things first gives them an opportunity to learn more areas. A common objection to having more people on one thing is that it is inefficient. It is important to remember that you should not throw more people at a problem if it does not a good investment. You don't want to slow the original developers down but IMO people are way to fast in saying "I can't split this work up more". Just sitting next to somebody working may be a goodlong term investment for the team. And if the team is forced to work on fewer user stories they will come up with ways to split the work and work efficiently. That is a good investment for the future when you do want a lot of people working on the same thing sine it is a very important user story.
  • When people say they're on track they either mean they don't know if they're late or not or they're lying. You cannot know that you're on track until you're done. That's the nature of being agile I think. But agile is also about managing risk. i think it is too early to even consider more user stories when only 25% of the planned user stories are completed but when 75% of the user stories are completed and 75% of the team is free for new work you may want to add a few to the remaining 25% planed and then use part of the team to look at bonus user stories.

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.