Changing Iteration Contents Mid-Sprint

I facilitated a project management clinic last week at PSL. One of the questions was this:

We have a product owner who persists in changing the contents of the sprint during the sprint. This is difficult for us. It costs us to change the content.

Okay, this is a huge pain in the tush. It's just like multitasking, and you know how much I like that. (Not at all!)

I suggested my colleague ask the product owner what business pressures the product owner is facing that he/she is feeling that is forcing the changes more often than two weeks. Yes, they have two-week iterations. So, what is going on that they have to change direction more often than 10 business days? Those are some fearsome business forces. Or, the Product Owner or the business have no idea what they are doing. Or something else. This is a great time to empathize with the product owner and understand more about what is going on with the business. Do they have a roadmap for the product? It's worth knowing what's going on.

Then, I asked if they could go to one-week iterations. That might alleviate the issue of changing requirements mid-sprint. I heard this:

No, the overhead of moving to releasing for one-week iterations is too high.

Danger, Will Robinson, Danger! You heard the “overhead” word. What does that mean? That's code for hidden impediments.

That means it's useful to move to one-week iterations to know what the impediments are and clear them, so that if they wanted to release at any time, they could. That would allow the Product Owner to see the value earlier, and while not change the contents mid-sprint, at least, see the value of the requests sooner.

When Product Owners want something that appears crazy, it's useful to see if our team behaviors are pushing them into this “crazy” behavior. In this case, it's a combination of not-so-sane behaviors. If the technical team could match the release frequency to the Product Owner mind-changing, I bet the frequency of mind-changing would decrease. Or, maybe the mind-changing would change to “Let's do A/B experiments.” Because that might be what it is.

But, when the technical team has impediments that prevents easy releasing, everything is too hard. You have to ask yourself, “How short can the iteration be?” There is no easy answer.

When a Product Owner wants to change the iteration contents mid-sprint, and the Product Owner realizes this is a no-no, look deeper for systemic forces at work. It won't be an easy answer, and will likely be a combination of answers. If you are lucky, it will be a relatively easy-to-diagnose problem, as this one was.

17 thoughts on “Changing Iteration Contents Mid-Sprint”

  1. Hi Johanna,

    yes go to shorter iterations, lower the water and see the problems.
    Last week at ALE2012 (while you had PSL) we had an Open Space development going on.
    One of the goals of this development, was to deliver once every hour.

    During 3 days, they have delivered new versions 23 times. And that for a non-team, (people walked in and out) , a nice example that smallers iterations are possible. EVERYwhere.


    1. Yves, every time I work with a team and say, “let’s experiment and see how short the iteration can be” they always surprise themselves (assuming they don’t have hardware to turn). Even the hardware guys can iterate! It’s all a matter of mindset. I love your once every hour. — Johanna

  2. I have seen that sometimes Iteration is confused with Release, so people think that an iteration must be “feature complete”, and thus cannot be shorter than whatever time is needed to achieve that. Once they understand that an iteration must be “Fully Functional” instead of “Feature Complete”, and that a Release may have several Iterations, some of the pressures to over-commit and to change midways is gone.

    Sometime our Product Owner decides that there is a feature that must be included in an iteration, after the iteration has started. We gave him a mechanism to do that, and to balance cost and benefits: if you add a story to an iteration, another story of the same value must go, PLUS at least 3 points of story to represent the effort the team must do for the story (understand it, estimate it, quick design, context change, etc). If there are no 3 points stories in the iteration, this means that a 6 points story must go too.

    This put some perspective in the cost of changing the scope mid-iteration, and give the PO the power to decide if its worth it or not. For us, the changes mid-iteration are basically gone.

    1. Rafael, I really like the idea that it’s not the same size story but it’s cost-plus. Very nice. I’m stealing that! — Johanna

  3. I thought something different when I read “overhead” — I interpreted it as a sign of a cost-accounting worldview, whereas shorter iterations result in improvement within a throughput-accounting worldview. This, sadly, leads to a complicated discussion that often doesn’t help in the moment, even if it helps over the longer term. 🙂

    Good news for me: it gives me a chance to talk about why fixed costs kill, and how that’s a general business concept, not a software-related one, so pay attention! If I really get on a roll, that leads to “…and that’s why Lean Startup is just XP for business development. We did that stuff last century.”

  4. Pingback: Changing Iteration Contents Mid-Sprint | Development Block

  5. Being able to shift gears easily is indeed a major component of agile. However, it does pose problems if the sprint is already mapped out, the team is already in motion, and the PO changes his/her mind in the middle of it. I wonder if the PO would change again mid-sprint even if the team did move to a one-week iteration – would it really solve the problem? We’ve been interested in knowing how many people are doing shorter/longer sprints than the average 2 weeks – and is there a better day of the week to start the sprint? I added these as new questions to the annual State of Agile Development survey (take it at this year, so hopefully people will provide some good insight to this topic.

  6. Michael Robillard


    I appreciate your perspective on empathy and understanding. Given this is complex knowledge work with a self-organizing team, I always believe the first focus should always be on understanding and learning; in this case, as you assert, what is causing this behavior?

    A pattern I’ve seen with some POs and team members, especially when new to the agile philosophy, is that they seem to fear the accountability and the potential to appear vulnerable – to not actually know EVERYTHING perfectly.

    Another pattern I’ve observed that I try to work people through is the division that sometimes creeps into a team between the PO and the rest of the team. This seems to be very prevalent in organizations that have a history of silos and cross-functional strife. A team is obviously more powerful than any individual member.

    Thanks for the post.


  7. Nice post with lot of insight even in the replies. I was wondering on how do we deal with evolving requirements in multi-vendor scenarios where development is done by Org A and testing by Org B. Understanding the nuances associated with Distributed agile and requirements if they change at sprint level which ideally shouldn’t, how do we deal with it? Any insights?

  8. Rafael, provided a good response, trading one user story for another. But there are other issues to consider:
    – What if there is not enough time left in the sprint to handle the POs request?
    – What do you do with stories that are in progress that need to be traded?
    – What if there are dependencies between user stories?

    If the request is too disruptive for the sprint the other Agile/Scrum approach is terminate the sprint and plan and start a new sprint. I think the biggest issue here is training and coaching the PO to understand that once a sprint is started the development team is locked into that plan until the end of the sprint.

    One way or another there needs to be consequences to the change and the negative aspects be made known to the PO before proceeding with any change.

  9. We have the problem of changing things in mid of the sprint. PO removed the user stories after the sprint was designed and decided. One day in the morning we got surprise that scope of the sprint was changed. Kindly suggest us how to tackle such changes.

    1. HI Jaidev,

      You have several options:

      1. You can take the surprises and go with the flow. (this is not my favorite option.)
      2. You can call a meeting with the PO and ask, “What is going on?” before you do anything at all. This is a very good idea. You want to get the data before you make any rash decisions or blame anyone. You have no idea what pressure the PO is under.
      3. You can stop the sprint.

      You want to understand what is going on. Get the data.

      Did the PO change the stories because the PO is under pressure to deliver different value? Did the PO change the stories because the team has too much work in progress because each of you takes one story and “nothing” appears to get done? Are your iterations four weeks long and going to two week- or one-week iterations help with this?

      Talk to your PO. Understand what is going on for your PO. Then panic 🙂

      It is wrong to change the scope once the sprint is underway. You need to understand why. I assume we are all reasonable people working together. Start there, and see what happens.

      Maybe you can let us know?

      Good luck.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: