Product owner demands new features while sprint has started

Question

I'm currently working on project X and my product owner keeps pushing new features to the sprint backlog which has to be completed in that sprint.

Pushing new features to the backlog is not the issue, the problem lies within the fact that he wishes me and the other developers to complete them immediately.

The way our PO handles it isn't professional at all, since we discuss the importance of the current user stories in the sprint-meeting for the upcoming sprint.

How can I address this to my PO in a professional way?

Answer 1

The Agile Manifesto does indeed welcome late changes, see point 4:

Responding to change over following a plan

And the scrum guide has this:

During the Sprint:

No changes are made that would endanger the Sprint Goal;

Quality goals do not decrease; and,

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

The thing for you is that your team has a velocity and you have accepted stories into the sprint based on that.

What you now need to do is get the PO to set the priority within the backlog of this story. If it is above a current story (or stories), you estimate it, and move the lowest stories back out until you balance your velocity back. If the story is below anything in the current sprint, then by definition it is less important so it'll have to wait. If the story is at the end of the sprint and there isn't enough time to do it, start it and flow over into the next sprint.

It's (intentionally) that simple, either it's more important and you prioritise it over the existing work, or it isn't. If the PO wants it as well, remind them that velocity is a metric of what you can do, not a goal, if they want to load it up they can, but you won't get to it.

Another thing is to agree a Sprint Goal with the PO/business as per the guide. If something comes in, you also compare it with that (Does this story help us meet the goal?), if not then it needs a priority call over the work you are doing. So an urgent bug may be priority, but something else is demoted as it's not part of meeting the goal, or maybe you abandon the Sprint for the higher priority work).

Answer 2

I agree with all the above statements about Agile allowing flexibility and change.

But (very big but!) I have worked with POs that are often fire-fighting throughout the Scrum sprint. If that happens, it can be very distracting and/or demoralising for the team to have to constantly adapt to these changes. This continual change of priorities can also seriously affect releases, and as a result it will have a negative effect on ROI!

In these cases, I have been part of teams where the decision was taken to ditch Scrum and experiment with Kanban. The latter offers flexibility in defining requirements much more than Scrum. Kanban is also more suited to continuous delivery vs regular releases.

For further reading, from two perspectives, have a look at these links:

https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban

http://kanbantool.com/kanban-library/scrum-and-kanban/kanban-vs-scrum-how-to-make-the-most-of-both

Finally, taking a quote from the last reference

...never stop retrospection, in order to learn from your experience and to keep experimenting, as you never know what possible solution may turn out to be the best for you.

Answer 3

Speaking as someone who has been both CTO and Head of Product at different organizations, I largely agree with @The Wandering Dev Manager but wanted to add more than a comment would allow.

This shouldn't be happening as described. I see a lot of red-flags in both the frequency and immediacy of requests. I suggest having an honest talk with the Product Owner about their current process and how it affects your work. I would also start to look for another job, as this situation might not get better.

If the Product Owner is simply bad at their job, that's actually good - they can get better or can be replaced. Unfortunately, many times situations like this exist because the Product Owner is actually quite good at what they do, but has been forced into certain patterns due to pressure from above. Not everyone can invite their CEO to fire them on every battle. When this is the case, the situation will not improve.

Overall, changes during a sprint are fine -- but you should be prepared for them. I always make sure my product and tech teams pad sprints with enough points to handle "hot fixes" and bugs. When I ran product at a Media company, my teams knew to reserve a set-number of points each sprint -- something always popped up, as that was the nature of our business. Our system worked, because we could always plan for some sort of event to happen. If a forecasted event somehow didn't happen, then leftover time could be used for personal projects, housekeeping, or [gasp!] getting ahead. Handling the last minute features/changes was always at the discretion of the Product Manager, and in consultation with the Project-Manager and Tech-Manager for that team. We always made sure that the Team's morale was a factor as well. Nothing was ever promised to the business units other than a "best attempt to deliver" .

Sometimes, an exceedingly bad business decision is made – and no one realizes this until the sprint has started. This has happened a lot with startups I advise. Handling this type of situation is pretty simple – you have an an all-hands meeting to re-point, re-prioritize, and re-schedule. The sprint is aborted; you start from scratch.

Your business stakeholders may not understand that proper planning is needed for a lot of reasons. It minimizes administrative overhead, it allows interconnected systems to be built in more efficient manners, it allows for foresight and planning in how a solution is designed... There are a long list of reasons, but there are only 2 main take-aways that the stakeholders and Product Owners need to understand:

• You waste more time and money with immediate changes and requests. This method is always the least efficient.
• You hurt team morale and employee job-satisfaction with this workflow. Your developers will become stressed, angered, and ultimately leave.

When the customer is an internal organization, this means the department heads need to discuss. If the customer is an external client, then the company needs to decide if the business relationship is fixable or even justified.

Answer 4

In Theory I agree with @The Wandering Dev Manager but I think he/she is making it potentially to easy for the PO to change the sprint.

It is the job of the PO to resist change to the sprint (not prevent it) from external entities (customers). Unless there is some critical situation then the sprint should be thought of as immutable.

Also the sprint cycle is supposed to be short so that anything new that comes up can be prioritized into the next sprint without affecting the customer. If you are having several month sprints then you are not really doing agile. The goal is quick turnaround with some visible change (2-4 weeks).

But a sprint can change. If it does the cost of the new items Must be calculated and an equivalent amount of work dropped from the sprint to compensate.

So what should you do about it? Well that depends. It is the Job of PO to maintain the sprint is he doing it? Is he dropping appropriate work to compensate? If not then "The Scrum Master" should have a word with the PO.

Answer 5

Here's what your PO causes:

I've been doing one of the tasks in the sprint. I have made changes to my local code base. I'm not quite finished. After I'm finished, and satisified that everything is up to scratch, it goes to a code review, it goes through QA, then it's integrated into the shared development code. If it takes a long time between me starting the task and being ready, there will be changes in the shared development code that conflict with my work, creating extra work and risk.

Your PO, if he gets what he wants, would cause me to interrupt my work and continue on something else. Some time later, I go back to the first task. By that time, I've forgotten half of it, so it takes me time to start again. Things that were in my mind that needed doing are dropped. Quality drops. By the time I'm finished, there are many more changes to the shared code, many more conflicts, more wasted time.

At the same time, it totally destroys any motivation. Starting a task, and being told halfway through that it isn't wanted, is totally demotivating. And being demotivated doesn't exactly increase productivity. Why should you put effort into the next task when you expect it to be pulled as well?

I wouldn't be surprised if this kind of thing, happening regularly, would cut the productivity of a team in half. In other words, the new stuff that was inserted into the sprint won't get finished any quicker than if the PO had been patient, while the original stuff is massively delayed. Instead of two weeks for the original items and two weeks for the new items, it takes one week to start the original items, three weeks for the new items, two weeks to finish the original items. Instead of four weeks + a happy team, it takes six weeks + produces an unhappy, demotivated team.

Answer 6

What your PO does may be entirely legitimate. I presume you are in a commercial business, and the money from your customers is going to pay your salary. There are times when your business people say "OK, total change of plan" and when you should accept that.

On the other hand, it is your responsibility towards the owners of the company to deliver a quality product at a sustainable rate, not wreck your architecture because somebody has a new idea each week.

• If the high-priority stories are small and fit into the product, consider to use your bug process for them even if they are new stories. (I guess you have a defined process for getting hot-fixes into the current sprint.)
• If there are major changes in priority, suggest to the PO to abort the current sprint. Return all unfinished stories to the backlog. Remind the PO that any work you have already done on unfinished stories may be wasted if you can't restart work and merge soon.

Answer 7

In situations like this, having a process for expecting the unexpected is key. For example, a policy in which one story is traded for another story of the same size is a good way to maintain balance:

In the Scrum process, scope creep occurs when the Product Owner, or any other Scrum Team member, brings additional work (e.g. “gold-plating” or sneaking in Technical Debt) into the sprint without discussing it with the Team. The entire Team should always negotiate taking a user story out of the Product Backlog and bringing it into the current Sprint Backlog. However, if the Team has finished all of the work they committed to in the current sprint, and there is no way a developer can assist another or tester, they can raise the issue at the next daily stand-up and request to bring in new work.

In addition, sharing customer feedback and metrics within the team helps to clarify whether or not a change is necessary in the product itself, the messaging around it, or the analysis of the data. Having a road map and adhering to it is key, but this only works if everyone knows the plan and changes to it are bi-directional:

We can add or change tasks in quarterly plan, but this is reflected as a scope creep and an explicit change in plan.

References

• GSA Tech Guides: Conducting a Sprint Planning

• From Road-mapping to Planning to JIRA and Sprints