Skip to content

Switching stories mid sprint

October 24, 2009 by Jack Milunsky

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.

About the Author: As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at http://twitter.com/agilebuddy

Comments

Interesting post Jack. I

October 26, 2009 by Robert Dempsey (not verified), 15 weeks 1 day ago
Comment id: 3976

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.

It's never easy dealing with

October 29, 2009 by David Vivash (not verified), 14 weeks 5 days ago
Comment id: 4023

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.

Changing name of story - work stays the same

October 29, 2009 by Anonymous (not verified), 14 weeks 4 days ago
Comment id: 4025

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?

Story name change

October 30, 2009 by Jack Milunsky (not verified), 14 weeks 4 days ago
Comment id: 4026

if the essence of the story is in tact, then it wouldn't matter. I would have no problem with this.

Jack

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com