Switching stories mid sprint

Introduction

I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.

Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it’s worth blogging about this particular situation once more.

The response I received was “You’re not serious you’re going to ignore the PO” and “You can’t be a slave to the process”

In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:

How long are the sprints?
How far into the current sprint are you?
Are there stories that have yet to start that is of similar size that you can switch it out with?
Is this a critical issue that needs to be fixed ASAP as customers are complaining and may negatively impact revenues?

Those are some of the questions that need to be asked when making that decision.

In response to being a slave to the process…

Well you’re either a slave to the process or the team is a slave to any chicken in the company who shouts the loudest. Lets go back to basics and why the Sprint is there in the first place. It’s designed to provide stability for the team to get stuff done. Hopefully you’re doing short sprints so it’s not a lot of time before the team pops it’s head up again and asks for more direction.

If the team listens to whatever the next flavor of the month is, then we’re back to square one where there’s just chaos and nothing gets done. Seriously, smart people figured out why we need to do it this way. There is strong evidence to support that this makes a difference, a really positive difference. So lets not willy nilly and go changing plans whenever someone in the organization feels like there’s something more important to do.

Moreover, in this situation, I think it’s important the team asks some serious questions as to why suddenly there’s a story that’s so super urgent that it calls for a change in plan. Lets say you’re doing 2 weeks sprints and lets say you’re midway. This means in reality that 5 days ago, nothing was more important (top priority items get selected to go into the sprint). Why all of sudden is their a need to change direction so soon after. Additionally can’t it wait another 5 days?

Now I am sure there are times where such a situation arises and that’s fine. I would never be so hard-line to suggest that the team doesn’t collaborate over this and decide what are the best options. And in such a case, it’s important that the team does this.

But lets be very careful how we deal with this. Because once you do this once, it’s a slippery slope after that.

So what would I do. As already mentioned above, I would sit down with the team. Have the PO explain the dilemma. Thereafter, it’s up to the team to decide if there is an easy swap out that doesn’t impact the Sprint goals and productivity. Ultimately if it is possible, I am sure most teams would do it any ways. Level heads should prevail.

5 thoughts on “Switching stories mid sprint”

  1. It’s never easy dealing with POs who sidle up to your desk and start a conversation with the words “I just wondered if you could do a little job for me…”

    The truth of the matter is this: Business priorities will change mid-iteration.

    There are costs to making shorter iterations, so iteration length will always be a balance.
    The PO should be told the true cost of the change request, whatever you do:

    1. Adding the feature right now will cost more than it will if added in the next iteration
    2. Will the new feature generate more revenue in the space of 1 iteration than the extra cost of developing it now?

    Without knowing the amount of extra time the new feature will take to develop right now (rather than waiting until the next iteration), the PO cannot make an informed decision as to whether that extra cost is worth it.

    So, give 2 estimates: do it now for 5 days, or next iteration for 3 days.

  2. I have an interesting situation where the name of a sprint goal (story) was changed by the team mid sprint. This is because the name of the sprint goal didn’t accurately describe the work that was being done. The name of the sprint goal was changed to more accurately reflect the content … actual work was not changed at all. The Product Owner has indicated that when this is done the appropriate practice is to stop the sprint. Is this a supported practice by Agile/Scrum?

  3. Interesting post Jack. I worked with a client that, before I arrived on the scene, would frequently swap same size stories in and out of a sprint. I put a stop to this right away for a number of reasons: the motivation of the team was shot to hell as they never knew what was going to happen and so they felt that they were never accomplishing anything, business knew that they could do this and would live by the whims of the customer rather than incorporating feedback on a timely basis, and measuring the output of the team was near impossible. Bad factors compounded on other bad factors resulting in not as much being done as could have been.

    What we did to remedy this situation is to shorten the length of a sprint. We then ensured that all account managers had the training and understanding to convey expectations to their clients. This worked out great. The team has measurable and predicable output, and they feel that they are truly accomplishing work.

Leave a Reply

Your email address will not be published. Required fields are marked *