A sprint backlog is a number of product backlog Items (PBIs) that have been committed to a sprint.
A product backlog is a list of potential work items, prioritised by relative order of value. The agile product delivery framework Scrum uses time boxes to pursue its goal of incremental delivery, so for every sprint the most valuable items on the product backlog that can fit into the prescribed time box should be ring fenced – and these become the sprint backlog. The sprint backlog is then just a sub-set of the product backlog.
Compiling the sprint backlog
The process for getting the items from the product backlog to the sprint backlog is what should happen in sprint planning. With the product backlog in priority order, sprint planning should involve the product owner asking the development team about how many of the highest value items can fit in to the sprint time-box and then ask the team to deliver them.
Remember, the product owner just has the prioritised backlog to run the session with, it is the team that chooses how many of those items they can commit to. The original reason for this was that agile practices require the teams to work at a sustainable pace as much as possible, so getting the team to make a commitment on how much they can do is a good way to do this.
Over time, the team will start to become used to how much work they can do in a sprint. This will start to build some historical data through which predictions can be made about how long it will take to build all items in the product backlog. This is useful for planning and forecasting.
A sprint backlog is a tool that allows the development team to focus on completed and rationalised ideas that have been agreed for their transformation from requirement to product increment. As the sprint backlog is smaller than the product backlog, it means they can take ownership of it whilst the sprint is in progress.