Over a million developers have joined DZone.

Changing Iteration Contents Mid-Sprint

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}