How often do you add or remove PBI from the Sprint Backlog and who can do it?

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.  It should have enough detail that they can inspect their progress in the Daily Scrum. 

That is first and second paragraph of the Scrum Guide's section that describes the Sprint Backlog.  The Scrum Backlog changes all the time but all changes are done with the vision of accomplishing the Sprint Goal.  Tickets can be added or removed from the Sprint Backlog by the Developers because they own the work and the plan to accomplish the Sprint Goal.  I advocate that any changes that require an item to be removed from the Sprint Backlog or any item to be added from the Product Backlog be discussed with the Product Owner so that there is transparency and understanding for the reasons. 

If you will remember from the studies you had for the your certifications, the Sprint Backlog is created by the Developers.  The Product Owner does not tell them what items to place in it.  The Product Owner can help the Developers better understand the items and their importance.  The Product Owner is also involved in crafting the Sprint Goal. 

How often do you add or remove PBI from the Sprint Backlog

How often do you inspect and adapt progress towards the Sprint Goal?

and who can do it?

Who commits to achieving the Sprint Goal and does the work?

Do you set a limit or standard on how many PBI can enter or exit a Sprint? Is it 0 or unlimited? We know that the Sprint Backlog shouldn't change too much, but what is acceptable?  There should definitely be a limit on the number of PBIs added to a Sprint.  The number of PBIs added to the sprint should be based on the teams Velocity, that is the average number of story points they are able to complete in a sprint.  So, if a team's velocity is say 10 story points of PBIs per sprint, then that is the limit.

Also, who has the permission to add or remove a PBI from the Sprint? Do you allow developers to add or remove PBI with your tool? Or only the PO has the permission to do that in your tool? The general rule is that once a sprint has started, no new work is added to the sprint.  The only exception would be if the team happens to get work done in the sprint before the sprint ends and has no more work in the To Do queue, then it may be possible to add additional work so long as it can be completed with the time left in the sprint.  Now as far as who should add PBIs to the sprint, in my organization we use JIRA, and based on what the team decides the amount of PBI's they can complete then I leave it to my Scrum Master to assign those PBIs to the sprint.

How often do you add or remove PBI from the Sprint Backlog and who can do it?

When faced with a question like this, you can always fall back on the accountabilities section of the Scrum Guide.

With regards to who can change the Sprint Backlog, the answer is clear in the Scrum Guide section around Developers Accountability.

• Scrum Guide: Creating a plan for the Sprint, the Sprint Backlog;

With regards to how often? In complexity it is assumed that we can't get the plan exactly perfect in Sprint Planning, things may change throughout the Sprint, and that in doing the work we will discover more about what is needed to get the work done.

• Scrum Guide: Adapting their plan each day toward the Sprint Goal;

In summary the answer is the Developers are the only ones who can add or remove a PBI from the Sprint Backlog as they see fit. They do this as often as needed in the Sprint, using the Sprint Goal to guide conversations and decision making. The Developers may even choose the order in which the PBIs get implemented during the Sprint. The Developers often collaborate and communicate with the Product Owner around scope, but at the end of the day the Developers remain accountable to deliver on the Sprint Goal.

One big myth in Scrum is that the Sprint Backlog does not change once Sprint Planning ends, that it might be a sign that the Developers don't know what they are doing, or that they have in some way failed.

I believe the confusions happen due to the variant, and sometimes opposite explanations via various materials. for example, while Scrum Guides declares: "the Sprint Backlog is updated throughout the Sprint as more is learned";

The Scrum Master Training Manual introduced by MPlaza, describes like this:



The Sprint Backlog is frozen after the Sprint Planning and the Development Team will focus on delivering an Increment of “Done” based on this plan. The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint. (p44)

Two remarks. After checking VD trans credentials (which are unofficial but still) I understood that question is ratehr rethorical.

Of course the dude who was able to pass PSM II and PSPO II test KNOWS that PBI are removed from the Sprint Backlog WHEN ITS NEEDED TO ADD VALUE OR MEET SPRINT GOAL and that Developers can do it, in agreement with Product owner(preferably but not mandatory)

As for Vahid Ajorloo

Scrum is guided by the Scrum guide , not by the Management Plaza.

Management Plaza can release their own version of Scrum, like SAFe did(and LESS which I respect by the way), and then we shall see which version will be more sucessfull. 

Do you set a limit or standard on how many PBI can enter or exit a Sprint? 

The developers need to determine how much can be done in the Sprint. 

Per Scrum Guide: "Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts"

They typically approach this by sizing the PBIs using Story Points and observing how much they were able to move to Done (based on the DoD) in the past Sprints in Story Points value (the so-called Velocity)

The other approach might be to construct PBIs in such a way that all of them are of similar size and observe how many PBIs it was possible to move to Done in the past Sprints.

If the team doesn't have past Sprints yet or there are some other limitations, such as bottlenecks in certain skills, tools, technical dept etc.. the team might be forced to do a very detailed plan for the entire Sprint to determine what can be done.

We know that the Sprint Backlog shouldn't change too much, but what is acceptable?

Here is some misunderstanding in regards to what is changing in the Sprint vs what is NOT.

"Why" (Sprint Goal) - doesn't change

"What" (the selection of the PBIs from the Product Backlog to realize the Sprint Goal) - this can change but it needs to be done with the Product Owner involved.

Per Scrum Guide - " If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal"

"How" (the plan to deliver the Increment to realize the Sprint Goal ) - It is a plan. Plans do change anytime when things are not going exactly as planned (inspect and adapt). The PO doesn't need to be involved here.  However, the Sprint Backlog has to be a "highly visible, real-time picture". So that everybody can see how things are progressing. Some teams plan with the granularity of each day/developer to achieve sufficient transparency for themself to be able to inspect and also for others to signal the progress as well as challenges and problems. 

Even this might be not enough and in certain circumstances, the team needs to specifically inform/consult the PO or some stakeholders.