Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at jrothman.com Johanna is a DZone MVB and is not an employee of DZone and has posted 127 posts at DZone. You can read more from them at their website. View Full User Profile

Changing Iteration Contents Mid-Sprint

04.07.2013
| 480 views |
  • submit to reddit

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.

Published at DZone with permission of Johanna Rothman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: