Skip to main content

How to make changes to the Sprint Backlog

Last post 08:26 pm November 2, 2015 by Ian Mitchell
2 replies
12:11 pm October 31, 2015

There are a few posts on this topics in the past. But I wanted to clarify a few things.

Sprint Backlog has 3 components
1. Sprint Goal.
2. PBI's.
3. Tasks.

How and when these three components can be changed during the sprint.
My understanding is
1. Sprint Goal: Never changes during the sprint.
2. PBI's: These can be added, removed or edited during the sprint. But both PO and Dev team need to be agree.
3. Tasks: These can be added, removed or edited during the sprint. Dev team alone can make these changes.

Please clarify.


04:01 pm November 2, 2015

Sprint Goal
IMHO if the team is adding or removing backlog items from the sprint, the sprint goal may need to change.

Sprint Backlog Items
As long as the product owner and development team agree, items can be added or removed from the sprint backlog. If an item is added to the sprint the team needs to understand that they are accountable for having the new and existing items meet the definition of done by the sprint review.

The team should discuss if they want to create tasks during the planning meeting or to create them as needed. My team starts with one or two tasks per PBI at the planning meeting. Then during the sprint we add tasks as needed.
We haven't run into this but you can run the risk of discovering a task that increases the effort needed to mark a PBI done. In which case the team needs to determine if they can finish the PBI with the new task or if a new PBI should be created. In either case they need to make the choice visible to the product owner, no one wants a surprise at the review.

During the sprint retrospective the team should discuss why any of the above occurred. And after determining the "why" create a plan to minimize these events from happening in the future.

08:26 pm November 2, 2015

> Sprint Backlog has 3 components 
> 1. Sprint Goal. 
> 2. PBI's. 
> 3. Tasks. 

A Sprint Backlog is the forecast of work needed to meet the Sprint Goal. This forecast will include the selected PBI's and a plan for achieving the Goal. The plan is often represented as tasks, but does not have to be.

The Sprint Backlog is wholly owned by the Development Team, while the Goal is shared between them and the Product Owner. Therefore the Goal is not a component of the Sprint Backlog, but is a point of reference around which the backlog may be replanned and changed.

> My understanding is 
> 1. Sprint Goal: Never changes during the sprint. 

Correct, although if the Goal becomes obsolete then the Sprint may be abandoned.

> 2. PBI's: These can be added, removed or
> edited during the sprint. But both PO and Dev
> team need to be agree. 

Correct, although strictly speaking the Development Team *could* change the PBI selection unilaterally if this is necessary for the agreed Goal to be met. They own the Sprint Backlog and it is theirs to replan. However, in a good Scrum implementation the PO and Dev Team would collaborate extensively on such matters.

> 3. Tasks: These can be added, removed or
> edited during the sprint. Dev team alone can
> make these changes. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.