When to build the Sprint backlog?

The Scrum Guide is pretty clear that the Sprint Backlog, which is the set of "Product Backlog Items selected for the Sprint plus the plan for delivering them", is created during Sprint Planning. The Sprint Planning session has two portions - the first is the selection of the work that can be done (selecting Product Backlog Items) and the second is developing a plan for delivering them. The plan is usually decomposing the work (however, not all of it needs to be decomposed and fully planned at the Sprint Planning, just enough to give the team sufficient confidence that the items selected can be done within the Sprint timebox). A Sprint Goal is also crafted to help the team focus on the objectives of the Sprint.

I think the key here is also understanding what you mean by "Created". What I'm getting at is I know many teams that will start their Sprint Backlogs several sprints ahead but it is not completed until Sprint Planning. If you have an idea of the items you plan to work on in the future, what is wrong with adding them to the Sprint Backlog before you get into the sprint planning? So long as you're not completing the Sprint Backlog prior to the Sprint Planning meeting for the current sprint, I don't see anything wrong with this approach. 

The Sprint Backlog is created immediately a Sprint starts. It is the set of Product Backlog items selected for the Sprint. Until items are planned in, the set will be empty.

I think the key here is also understanding what you mean by "Created". What I'm getting at is I know many teams that will start their Sprint Backlogs several sprints ahead but it is not completed until Sprint Planning. If you have an idea of the items you plan to work on in the future, what is wrong with adding them to the Sprint Backlog before you get into the sprint planning? So long as you're not completing the Sprint Backlog prior to the Sprint Planning meeting for the current sprint, I don't see anything wrong with this approach.

I've seen teams work in this manner, but I don't think it's a good idea. I actively discourage it for a number of reasons. Stakeholders may see items in a Sprint, figure out when the Sprint is scheduled start and end, and get the idea of commitments or firm plans in their head. But these aren't firm - the idea is that work can be reordered or shuffled based on what has been done in the past, the changing situation, things learned from other Sprints, and team capacity. Anything that resembles long-term planning is risky to put before anyone who may not understand how the teams work and the nature of agile development methods.

My interpretation is the the Sprint Backlog for the current sprint is finalized during Sprint Planning as @Ian and @Thomas described.  AND...

@Curtis suggests a method that I have used but I don't see those as Sprint Backlogs.  I see them as a way of segmenting the Product Backlog into items that are already understood enough to pull into a Sprint and do not need further refinement.  We use Jira at my current employer.  On a number of the teams here, there is a "sprint" created that never gets started and never ends.  We usually call them something like "Ready for Planning".  Items are moved into that "sprint" when the team feels they are ready to be worked and need no more refinement.  Those items are the first ones considered for a Sprint Backlog at Sprint Planning.  But there is also a possibility that any of the items in the other part of the Product Backlog might be needed to be pulled in based on newly found information.  Then the negotiations begin. 

TL;DR Sprint Backlog is created during Sprint Planning.  Product Backlog can have segmentation based on level of refinement to help make Sprint Planning easier and more efficient. 

I do not like to have multiple "pending" sprint backlogs ahead. Also not for segmenting the product backlog.

It reduces transparency and might interfere with input from feedback loops.

You might be tempted to keep work in the future sprint backlog because it already is there, even though empiric evidence would tempt you to do completely different things.

You might be setting an implicit expectation to stakeholders that certain things will be picked up at some point.

You might be not updating the future sprint work since it is already ready and known, even though new information or feedback is available.

You might not have a clear overview of the work a product backlog holds, since part of the PB work is already in sprints and thus no longer on the PB stack.

And I can go on....

If the purpose is to segment PBIs into ready and not (yet) ready, you have multiple ways of indicating this while on the PB, especially when using software like Jira, where you can tag and label the hell out of everything

I agree with the risks you mentioned Xander, they are real. However, remembering the transparency pillar, having PBIs grouped into forecasted sprints will enable everyone interested to see forecasted progress across many sprints. If they then treat it as plans - then it will be POs job to teach them about these not being plans set in stone. If PO makes predictions across many sprints, what better place to store these would it be if not backlog, possibly segmented, if a particular tool allows it.

@Xander, I completely agree with having multiple future sprints and that is why I will only coach on segmentation.  And it takes a while, and a bit of telling they are doing it wrong, for everyone to start understanding that the segment is not set, it just an indicator.  

BTW, I don't say they are doing it wrong.  I just say that in my head and instead suggest ways to better use the method. It has worked well with most teams but I've had a couple where they tried to make it an absolute no matter much I coached.  On those, I usually start nudging them towards stopping the use of it.  As always, there isn't a right way, there is only a way that works for each individual team.

I also concur with both Xander and Filip's concerns and observations.   With my teams, we frequently "stage" future sprints, even referring to them as "tentative future sprints".   We find that this practice aids the PO in visualizing and managing potential release points, and helps the Development Team to understand when potential future items may be offered.   

However, such staged sprints are always subject to change based on stakeholder feedback and changing business priorities.

Thanks all

The reason for the question is I was kicking around on the PSD open assessment and it asked about CI work and it prompted me to this in the Scrum Guide (SG):

“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”

Now (slapped wrists) I see the SG as a guide not gospel so when working in teams or trying to help them I’ve added this sort of thing to either DoD or chat with the PO/stakeholders about it so adding the work to the PB. By the SG statement the SB is formally started after the retro with this action.

But as the discussion shows there are multiple ways of creating spring backlogs so thank for the input and discussion.

Should be Prior to the Sprint Planning meeting.

The Scrum Guide does not mention the Sprint Backlog as an input of Sprint Planning

"The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team"

Sorry, I mean during the Sprint Planning meeting. I've tried to edit my previous comment but cannot :D