Here’s an all-too-common scenario in agile software development projects. You’ve defined fixed-length sprints. They are 4, 6 or 8 weeks long. The team is well into a sprint when the product owner shows up and says something like “We have to add another story to this sprint. The business will reject the software unless we add this story.” What do you do?
Some will argue that stories cannot be added or swapped during a sprint. The business will have to wait. Others will argue that the sprint should be scrubbed and a new one defined. Again, the business will have to wait. Are either of these positions reasonable?
As is often the case, the answer is, “It depends.” If the sprint end date is not mission-critical, it may be reasonable to argue for adding the new story to the next sprint or scrubbing the current sprint and starting anew. In either case, it will be several additional weeks before the business sees the software they want.
However, if the sprint end date is mission-critical, the team has a problem — potentially a big problem. Delivering software that the business doesn’t want is foolish. It will be rejected and the team will look bad. Yes, even if the business folks and the product owner made a mistake in selecting or defining stories, the development team will still end up looking bad. Why? Because they were given notice of the error and they failed to take corrective action. That’s not agile.
In this context, the team has 5 options. None of them are great choices. Some of them may not be viable in particular situations.
1. Add the new story to the sprint backlog and extend the sprint by a few days to accommodate it.
Assuming the business is willing to tolerate a delay of a few days, this is the simplest option. It will disrupt the team’s rhythm but that’s manageable. There may be a desire to extend the sprint by exactly one week rather than a partial week. Don’t do that! Adding more stories to the sprint to fill out the week will only make matters more complex.
2. Swap an existing story in the sprint backlog for the new one and keep the sprint timeline intact.
This may not be feasible. There are inter-dependencies among stories that complicate this option. It may also be difficult to find another story that can be readily swapped with the new one. That said, it’s worth taking a look at this. Consider swapping more than one existing story for the new one. Also consider splitting one or more larger stories to free up story points for the new story. You may be able to shorten the sprint using these techniques. Be creative.
3. Add a team member to work on the new story.
If someone is available and has worked with the team before, this is a viable option. However, bringing in a total stranger will be more hassle than it’s worth. Too much time will be lost getting the newbie up to speed.
4. Take on some technical debt.
Admittedly, this is a poor choice but in the interest of getting all the options out in the open, it’s a possibility. The team may be able to cut a few corners without impacting the usefulness or stability of the software and still deliver on time. Let everyone know what you’re doing and also let them know that the debt will be paid off during the next sprint. Just remember that business people don’t understand technical debt and don’t want to pay it off.
5. Have the team work some extra hours.
I don’t like this option. It’s the least desirable of the five to me. Once you demonstrate a willingness to work longer days or extra days, the precedent is established and you’ll have a tough time going back to a ‘normal’ schedule. Don’t offer this option unless the business situation is dire and be clear that it’s a one-time offer meant to address a crisis situation.
Can you think of any other options? Let me know.
First of all, I think you shouldn’t have sprints as long as 4, 6 or 8 weeks. 1 or 2 weeks should work better.
I agree. I like 1-2 week sprints too.