Johanna Rothman writes on how she facilitated a project management clinic in which she overheard this statement: "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." To Johanna, this is a huge pain and it is similar to multitasking.
One of the quesions in a project management clinic i facilitated was:
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 ten 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.
