Skip to main content

Sprint Backlog

Last post 10:14 pm January 31, 2018 by Ian Mitchell
4 replies
06:24 am January 30, 2018

Prod BL is dynamic. How-ever pl. clarify if : "Is Sprint BL is frozen when sprint planning is done ?"


07:22 am January 31, 2018

No it's not. What's fixed is the Sprint Goal, not the plan for getting there (i.e. Sprint Backlog). In fact, if you don't adapt the Sprint Backlog as new work emerges, you're not doing Scrum.


08:45 pm January 31, 2018

To follow up on that, doesn't the Sprint Goal emerge from the features (essentially, user stories) we are planning to deliver? 

Generally, we go into the Sprint Planning looking at the top of the backlog and deciding how much work can be completed within the next sprint. It means that the backlog will include a set of stories which will identify the sprint goal.

I understand that the tasks the team is working on can change depending on what they discover during the sprint, however, still not sure about the user stories we selected.

I guess what I'm looking for is a specific scenario example since this topic was a bit confusing to me lately.


09:25 pm January 31, 2018

Daria,

If I understand correctly, a number of product backlog items may be forecast by the Development Team as both achievable within the sprint time box, and in support of a Sprint Goal that provides focus and motivation for the team around the business value being delivered.

This forecast however, is based on what the team knows at the time Sprint Planning is being conducted.   As the Sprint is executed, the team will likely learn more about the items forecast, and may identify a better method of completing the Sprint Goal (simpler, cheaper, more efficient, etc.).   The team may then opt to change the Sprint Backlog in order to support this new strategy for meeting the Sprint Goal.   

Such changes may involve either adding or removing items from the sprint.


10:14 pm January 31, 2018

I understand that the tasks the team is working on can change depending on what they discover during the sprint, however, still not sure about the user stories we selected.

Any part of the Sprint Backlog can be revised by the Development Team, irrespective of whether they be stories or tasks or something else. It’s their plan and they wholly own it.

When a Sprint Backlog is revised to better meet a Sprint Goal, any impacted user stories ought to be re-estimated on the Product Backlog to capture however much work is thought to remain.

The Product Owner may or may not decide to retire those stories. Even if they were not needed for the current Sprint Goal, that doesn’t mean they will be unnecessary in future sprints.


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.