Iyfjky

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?

You know adding features to a currently running sprint is antithethical to the concept of scrum right? — May 13 '16 at 11:23
Any Scrum Master in the place that can explain to him that a sprint is a non-modifiable unit of work once it is started? If the company or the team agreed to do Scrum, then this is not Scrum and you guys need to talk about it, as a team. — May 13 '16 at 11:27
@AlexandreVaillancourt what if you discover a massive security hole in your product on the first day of the sprint? What if you find an open source library that has the functionality you planned to work on? What if the client whose code you were writing goes bankrupt? "The sprint can never be changed" is not a workable idea. It's a matter of whether these requested new features are important enough to change the work plans, and if so, how that is done. — user45590, May 13 '16 at 11:35
@AlexandreVaillancourt - No, see my answer below. The Manifesto WELCOMES changes, anyone who told you otherwise was a snakeoil salesman and did not know Scrum. This is the most common fallacy in SCRUM today. — May 13 '16 at 12:04

score 59 · Accepted Answer · 2018-04-27 23:19:37Z

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).

Agreed. Also, if the product owner is unhelpfully changing priorities frequently, insisting on this process (and a meeting to make the changes) each time helps them to see how the changing priorities disrupt plans. — user45590, May 13 '16 at 11:50
I would say if this is happening all the time, if you normally have 300 people-hours per sprint, maybe only assign 250 people-hours per sprint with the last 50 dedicated to the "rush jobs". Maybe have that last 50 set aside with things that you might want to get done this sprint but you can put off if needed. Then if your CEO comes in with demands, you know ahead of time what you're cutting for it. — May 13 '16 at 20:59
+1 for "something else is demoted as it's not part of meeting the goal". At the risk of repeating what JeffO said. Everything has a price. Any new feature has a price. Don't let your product owner get away with adding things to the pile without rebalancing the spreadsheet of priorities and without cutting things elsewhere. — May 13 '16 at 23:13
@corsiKa: But that's just enabling those who want to work around the system. How long until the 50 hours are not enough for them any more? Within a few months I can almost guarantee you won't be doing scrum any more. — May 14 '16 at 15:35
@Lightness So what? Scrum is not a goal. And it is certainly not a holy grail. If it doesn't work for your work situation, stick to the parts that work and move on. Don't forget that the goal is to deliver a good profuct. — May 15 '16 at 6:16

maurocam 714 · Answer 2 · 2016-05-13 18:27:22Z

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.

I also have been in the situation of switching from a Scrum (where sprints were constantly being fiddled with mid-sprint) to Kanban and it worked much better for that team and company. — May 13 '16 at 22:30

score 5 · Answer 3 · 2016-05-14 23:33:24Z

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.

Martin York 953616 · Answer 4 · 2016-05-13 15:38:03Z

up vote
2
down vote

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.

answered May 13 '16 at 15:38

Martin York

953616

It's He, and I disagree with you. The job of the PO is to maximise the ROI of the product, if that means changing then that means changing, even if the sprint needs to be abandoned. The sprint is never immutable, you may want to discuss it, but not accepting valid change is an Agile antipattern, one trotted out by 'Agile Coaches' the world over.
â€“Â The Wandering Dev Manager
May 13 '16 at 16:29

For that matter, the job of the PO is to maximise the ROI of the product even if that means not using sprints at all, or not doing agile at all. If the process doesn't suit the business, the process loses. A sprint is just a name for a collection of work that you forecast for a particular block of time. If that's not what you're doing, because that doesn't suit the business, just don't call it a sprint.
â€“Â Steve Jessop
May 13 '16 at 17:19

2

Yes and no. Constant change results in loss of productivity. If that happens more than occasionally it bombs velocity. I have seen that at my last large customer where the PO was prioritizing the backlog 3 times a week - the result was NOTHING got ever done. You start on something, then box it over and over.
â€“Â TomTom
May 13 '16 at 17:20

@TheWanderingDevManager: Churn in changing the sprint will reduce ROI in the general case. It is the Job of the PO to discuss with the client and make sure that the change is the best option (not just change because of changes sake). Thus they should resist (in council that is generally bad) but should facilitate if that is the best option. They should also remind the customer that the sprint is short for a reason so that you don't need to change often.
â€“Â Martin York
May 13 '16 at 19:11

@TheWanderingDevManager: I think we actually agree on what should be done. I just want to emphasis that to get the best ROI does not mean agreeing to whatever the customer wants just because they are the customer. There Job is not to act as the yes man for sprint change but to act as the point of reason and make sure the customer is willing to pay the cost for a change in the middle of a sprint and to try and prevent the team being randomized by changes. But if the sprint must change then they are responsible for it and must do the change correctly.
â€“Â Martin York
May 13 '16 at 19:19

Â |Â
show 1 more comment

gnasher729 70.7k31131222 · Answer 5 · 2016-05-13 21:37:19Z

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.

o.m. 992158 · Answer 6 · 2016-05-13 17:14:58Z

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.

I disagree with the first bullet. Wiggling more stuff into a sprint even if small requires wiggle room. Either a) there are unspent sprint points (bad) b) drop some story to fit the new ones (adequate) c) overwork the sprint (bad). d) Set it aside for the new sprint (recommended, but not always possible given the PO agenda)... Never use hot-fix/bug process for new features. — May 13 '16 at 18:29
@Mindwin, we are always reserving some time to look at new bugs, prepare powerpoints to explain things to management, cope with one or two sick days, etc. If the sprint is 100 percent full, you are not making enough allowance for the unexpected. — May 14 '16 at 9:12

Paul Sweatte 20514 · Answer 7 · 2018-03-29 07:51:43Z

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

score 59 · Accepted Answer · 2018-04-27 23:19:37Z

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).

Agreed. Also, if the product owner is unhelpfully changing priorities frequently, insisting on this process (and a meeting to make the changes) each time helps them to see how the changing priorities disrupt plans. — user45590, May 13 '16 at 11:50
I would say if this is happening all the time, if you normally have 300 people-hours per sprint, maybe only assign 250 people-hours per sprint with the last 50 dedicated to the "rush jobs". Maybe have that last 50 set aside with things that you might want to get done this sprint but you can put off if needed. Then if your CEO comes in with demands, you know ahead of time what you're cutting for it. — May 13 '16 at 20:59
+1 for "something else is demoted as it's not part of meeting the goal". At the risk of repeating what JeffO said. Everything has a price. Any new feature has a price. Don't let your product owner get away with adding things to the pile without rebalancing the spreadsheet of priorities and without cutting things elsewhere. — May 13 '16 at 23:13
@corsiKa: But that's just enabling those who want to work around the system. How long until the 50 hours are not enough for them any more? Within a few months I can almost guarantee you won't be doing scrum any more. — May 14 '16 at 15:35
@Lightness So what? Scrum is not a goal. And it is certainly not a holy grail. If it doesn't work for your work situation, stick to the parts that work and move on. Don't forget that the goal is to deliver a good profuct. — May 15 '16 at 6:16

maurocam 714 · Answer 9 · 2016-05-13 18:27:22Z

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.

I also have been in the situation of switching from a Scrum (where sprints were constantly being fiddled with mid-sprint) to Kanban and it worked much better for that team and company. — May 13 '16 at 22:30

score 5 · Answer 10 · 2016-05-14 23:33:24Z

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.

Martin York 953616 · Answer 11 · 2016-05-13 15:38:03Z

up vote
2
down vote

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.

answered May 13 '16 at 15:38

Martin York

953616

It's He, and I disagree with you. The job of the PO is to maximise the ROI of the product, if that means changing then that means changing, even if the sprint needs to be abandoned. The sprint is never immutable, you may want to discuss it, but not accepting valid change is an Agile antipattern, one trotted out by 'Agile Coaches' the world over.
â€“Â The Wandering Dev Manager
May 13 '16 at 16:29

For that matter, the job of the PO is to maximise the ROI of the product even if that means not using sprints at all, or not doing agile at all. If the process doesn't suit the business, the process loses. A sprint is just a name for a collection of work that you forecast for a particular block of time. If that's not what you're doing, because that doesn't suit the business, just don't call it a sprint.
â€“Â Steve Jessop
May 13 '16 at 17:19

2

Yes and no. Constant change results in loss of productivity. If that happens more than occasionally it bombs velocity. I have seen that at my last large customer where the PO was prioritizing the backlog 3 times a week - the result was NOTHING got ever done. You start on something, then box it over and over.
â€“Â TomTom
May 13 '16 at 17:20

@TheWanderingDevManager: Churn in changing the sprint will reduce ROI in the general case. It is the Job of the PO to discuss with the client and make sure that the change is the best option (not just change because of changes sake). Thus they should resist (in council that is generally bad) but should facilitate if that is the best option. They should also remind the customer that the sprint is short for a reason so that you don't need to change often.
â€“Â Martin York
May 13 '16 at 19:11

@TheWanderingDevManager: I think we actually agree on what should be done. I just want to emphasis that to get the best ROI does not mean agreeing to whatever the customer wants just because they are the customer. There Job is not to act as the yes man for sprint change but to act as the point of reason and make sure the customer is willing to pay the cost for a change in the middle of a sprint and to try and prevent the team being randomized by changes. But if the sprint must change then they are responsible for it and must do the change correctly.
â€“Â Martin York
May 13 '16 at 19:19

Â |Â
show 1 more comment

gnasher729 70.7k31131222 · Answer 12 · 2016-05-13 21:37:19Z

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.

o.m. 992158 · Answer 13 · 2016-05-13 17:14:58Z

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.

I disagree with the first bullet. Wiggling more stuff into a sprint even if small requires wiggle room. Either a) there are unspent sprint points (bad) b) drop some story to fit the new ones (adequate) c) overwork the sprint (bad). d) Set it aside for the new sprint (recommended, but not always possible given the PO agenda)... Never use hot-fix/bug process for new features. — May 13 '16 at 18:29
@Mindwin, we are always reserving some time to look at new bugs, prepare powerpoints to explain things to management, cope with one or two sick days, etc. If the sprint is 100 percent full, you are not making enough allowance for the unexpected. — May 14 '16 at 9:12

Paul Sweatte 20514 · Answer 14 · 2018-03-29 07:51:43Z

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

Search This Blog

Iyfjky

Product owner demands new features while sprint has started

7 Answers
7

Your Answer

Post as a guest

7 Answers
7

7 Answers
7

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

Product owner demands new features while sprint has started

7 Answers 7

Your Answer

Sign up or log in

Post as a guest

Post as a guest

7 Answers 7

7 Answers 7

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

7 Answers
7

7 Answers
7

7 Answers
7