Skip to main content

Any Pre-conditions to be fulfilled for Sprint Planning

Last post 02:44 pm November 14, 2017 by Ian Mitchell
7 replies
01:56 pm January 11, 2016

I recently came across the below question in Product Owner Open and wanted to check the suitability of option E (i.e Enough "Ready" Product Backlog to fill the Sprint) since Scrum Guide talks about Product Backlog items being deemed "ready" for selection in Sprint Planning through the Product Backlog Refinement exercise.

What pre-conditions must be fulfilled in order to allow Sprint Planning to begin?

A) A fully refined Product Backlog
B) Formal budget approval to conduct another Sprint
C) A clear and non-negotiable Sprint Goal
D) A clear but negotiable business objective for the Sprint
E) Enough "Ready" Product Backlog to fill the Sprint
F) There are no such pre-conditions


03:44 pm January 11, 2016

Suppose that no Product Backlog exists at all. Would that stop a team from eliciting one when planning their first Sprint?

In Scrum, the Sprint is the fundamental mechanism for delivering value and gathering empirical evidence. The imperative is to start, no matter in how small a way or in how seemingly trivial a manner. Transparency over value delivery, inspection, and adaptation are not behaviors that we would want to put in delay.


01:15 pm January 12, 2016

Thanks Ian. In short, getting the Product Backlog items "ready" though aids in subsequent Sprint Planning, does not necessarily restrict one from holding the Sprint Planning without this refinement exercise (especially during the first/initial sprint). I can relate this to the first/initial sprint where the focus is to get started. But, this brings another aspect, namely, if we are to extend this refinement exercise beyond the initial sprint and into the subsequent Sprint Planning sessions, will it potentially take time off and effectively knock off the Planning activity (completely in some case) to be able to accommodate this Refinement exercise then. The Refinement activity is expected to consume not more than 10% of the Development team capacity (which again depends on the number of dev team members, sprint duration, etc.,) whereas the Sprint Planning is for a maximum of 8 hrs.


02:07 pm January 12, 2016

> if we are to extend this refinement
> exercise beyond the initial sprint and
> into the subsequent Sprint Planning
> sessions, will it potentially take time off
> and effectively knock off the Planning
> activity (completely in some case) to be
> able to accommodate this Refinement exercise then.

Product Backlog Refinement helps to expedite Sprint Planning, because the items will have been prepared and brought into a "ready" state. They will have been ordered, rewritten as needed, estimated, and understood.

Time for refinement should be accommodated within the Sprint itself and not subtracted from any of the formal events within it. The maximum time for Sprint Planning (e.g. 8 hours for a 1 month Sprint) *must* be available to a team should they need it.

Nevertheless, if refinement has been conducted conscientiously, the chances of the team *needing* the full timebox for planning may well be reduced. I have known mature teams, who refine their backlog thoroughly, to complete planning for a 2 week sprint in under an hour. Even so, the event in such cases is still time-boxed to 4 hours, the team members simply being free to leave early.

Note that task planning for certain items may be deferred to later in the sprint, and after the Sprint Planning timebox has expired. This may reduce the time spent in formal planning and reduce overall replanning effort, if more timely information is then available. However as a general rule this should only be allowed by exception, as it can make transparency over work remaining (such as may be represented by a task burn-down) unclear.


03:31 pm January 12, 2016

While i agree Ian that Backlog Refinement helps expedite the Sprint Planning, not sure if i made clear my earlier query arising out of this refinement not necessarily a pre-condition for subsequent Sprint Planning.

Since the backlog refinement is not a pre-requisite for carrying out the Planning activity of any Sprint, assuming that a Scrum Team directly gets into the Sprint Planning without this refinement exercise, will this activity of refinement (that should have done typically during the earlier Sprint(s) for these Product Backlog items) be carried out during the Planning session and hence take up the time of the same.


05:25 pm January 12, 2016

> Since the backlog refinement is not a pre-requisite for
> carrying out the Planning activity of any Sprint, assuming
> that a Scrum Team directly gets into the Sprint Planning
> without this refinement exercise, will this activity of
> refinement (that should have done typically during the
> earlier Sprint(s) for these Product Backlog items) be
> carried out during the Planning session and hence take
> up the time of the same.

Yes. Sprint Planning is the very first thing to happen in any Sprint. As a Scrum Event, it is a formal inspect-and-adapt opportunity and the Product Backlog may be subject to revision. For example, it is common for estimates and order to be improved during Planning. If the Product Backlog is completely empty, then by the end of the event a Product Backlog must exist to which the work of the Sprint Backlog can be correlated.

In my opinion, the only essential pre-conditions to Sprint Planning are an hypothesis to be tested and a team of at least 3 people who can start doing the work.


02:26 pm November 14, 2017

> Suppose that no Product Backlog exists at all. Would that stop a team from eliciting one when planning their first Sprint?

In that case, would it be permissible to exceed the 8 hours time box for sprint planning if neede?


02:44 pm November 14, 2017

If the rules of Scrum are no longer observed, for whatever reason or justification, would the result still be Scrum?


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.