Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Confuse about a point related to Sprint.

Last post 10:34 am May 21, 2019 by Eugene M
9 replies
04:34 am July 3, 2014

Hello,

I have a question about Sprint as below:

In Scum-Guide (Version July 2013, page 7) , there is description about Sprint:

"During the Sprint:

.
.

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

Could you help to explain what does "Scope" mean here ? I am confusing because there was some where say that: The number of work is not allowed change during a Sprint.

Thank you.


04:41 am July 3, 2014

In this context, "scope" means the requirements that have been planned for actioning in the current Sprint.

These requirements are never frozen, but are revised and replanned as needed in order to meet the Sprint Goal.

If you have read somewhere that the scope of the current Sprint is not allowed to change, then the material containing that information is incorrect.


05:20 am July 3, 2014

Thank Lan for your help explain to me

Now i am clear about this.

The doc: "Scrum Training Manual" of mgmtplaza.com said that "The Sprint Backlog is frozen after the Sprint Planning".
Now i kow that it is wrong.

Again, thank you alot.


05:58 am July 3, 2014

Hello there,

I have another question related Sprint, it is about Sprint planing meeting.

In Scrum-Guide, i found 2 activity occur in same time: "End of this meeting"

1."Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less."

2. "By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work.... "

Could you help to clearify my confuse ?

Thanks


06:18 am July 3, 2014

Hi,
the planning has 2 main purposes:
A) select PBIs for next sprint
B) create a plan for how to get them done
The two points mentioned by you both refer to the second purpose. 1. is a suggested way to create the plan, and 2. is a way to validate this plan exists.


06:20 am July 3, 2014

I am cleared.

Thank you


07:18 am July 3, 2014

just be careful of where you study if you're prepping for the PSM exams ... often some scrum sources will describe the items taken from product backlog and then planned into the sprint planning, where the team commits to how much work they can complete and add it to the sprint backlog, THE SPRINT BACKLOG IS FROZEN AND DOES NOT CHANGE DURING THE SPRINT IS WRONG !!
The Sprint Goal doesn't change , if the team realises it has too much work , work that could have been discovered during the sprint from a backlog item, they should raise the issue with product owner, and discuss the issue - then negotiate "the scope" of the sprint ... remember what the scrum guide says , each Sprint can be considered a mini project. Any project scope , by either parties should be negotiable ... unless it makes the project (or sprint in this case) pointless to do or finish.


08:04 am May 20, 2019

What could be example of work planned for the first days of the Sprint to be decomposed? Why not the work planned for the whole Sprint?

Apologies. I am confused on this part.

 

 

 


04:48 am May 21, 2019

The planning of work for a whole Sprint can be useful, because it makes a forecast for achieving a Sprint Goal transparent. However, does this advantage always justify putting development and delivery in delay?

What if teams first plan just enough to get started on the Sprint Goal, and then replan on a just-in-time basis?


10:34 am May 21, 2019

What could be example of work planned for the first days of the Sprint to be decomposed? Why not the work planned for the whole Sprint?

 

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. SG

 

Would you say it's wise/effective to plan (especially considering the unknowns) for the whole Sprint? If your sprint is one week long, I can (to a certain degree) agree with the argument, but even then I have doubts. Why not start with a few steps, keep the sprint goal in mind, inspect and adapt daily (DS) towards success (a done increment)?

 

Say you want to spend about a week exploring a mountain range (camp & all) you've never checked. Lots of knows and a few (or, perhaps, many) unknowns. Would it make sense to plan every single day of your journey, or would you plan for the first day (or half a day), then decide when time comes? And decide again and again.


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.