Sprint Backlog and Product Backlog: A Nerd's Guide

Sprint Backlog is more or less a subset of Product backlog, which is used in Scrum. Sprint Backlog contains a specific list of features that are expected to be done during the course of the next one sprint i.e., within a time-bound period of 30 days . Since, Sprints are a time box it would be good for teams to estimate effort of stories that's why more focus is given on breaking down stories into tasks during Sprint planning( aka grooming) meetings .

Sprint Burndown Chart with Definition

The burned down chart is nothing but actual progress made by the team in terms of story points . As you can see in the image below, the X Axis depicts sprints while the Y axis represents stories with respect to their status : To do / In Progress / Done / Not done.

The blue line depicts the ideal burndown which is nothing but the sum of all story points expected to be done till end of sprint . For e.g., assume that there are 6 stories in the sprint, then the ideal burndown would be 6 if the team can do 1 story point per day . So, for a 30 days sprint, the ideal burndown would be 30 .

Product Backlog is nothing but a list of stories (maybe user story) ready to be executed in future sprints. It is the aggregation of all queue items that are yet to be done . So, ideally, Product Backlog will have a backlog for the entire product horizon or business value delivered by the team and decision making will depend on who can execute the work of the sprint backlog.

A sample product backlog may look like below:

Please note that the above image is just an example and not a real product backlog . We actually don't know what type of stories are there in the product backlog . They could be Epic , Theme , Sub-theme or Backlog Item etc.

Sprint Backlog and Product Backlog differences are:

1. Sprint Backlog contains only the stories that the team will deliver during the sprint . It is a subset of Product Backlog and hence, contains fewer items.
2. Sprint backlog should be ready before the start of every sprint while product backlog is not necessary to be ready before each sprint . Also, we can say that product backlog will contain larger or more number of items than sprint backlog for any given iteration.

Also Read: 4 Types Of Product Strategy: Which One Is Right For Your Business?

1. If our iteration length is one month , then Product Backlog may contain few epics/themes/sub-themes whose value delivery may take longer than one month whereas in case of Sprint Backlog, it should contain all user stories / tasks which can be done within one iteration (may be 1 week or 2 weeks or 3 weeks but not more than that).
2. The order of Product/Sprint Backlog is not important while order of Sprint Backlog is very much important as tasks have to be done in sequence i.e first task, second task and so on...
3. Product backlog contains priority which can be changed over time whereas Sprint backlog doesn't contain priority . However, the priority may change at any point of time for any given user story / tasks depending upon its value delivery during iteration.
4. We don't know the exact number of items (user stories) until the end of the Sprint Planning meeting, however we are sure about our sprint target or number of iterations for a sprint . You probably guessed it right! It means that the technical team has to estimate user stories and their size before the start of the Sprint Planning meeting.

Also Read: 7 Qualities That Make A Great B2B Saas Product Manager

1. Product backlog varies across the additional sprints whereas Sprint backlog stays constant .
2. There can't be multiple product backlogs for one project however it is possible that you have many different sprint backlogs created based on number of teams working together in development, testing or maintenance activities at any given time. You just have to ensure that team does not create more than one sprint backlog per scrum team, if so happen then technical group should be called as scrum of scrums where each sub-team lead will take part in its own daily stand up meeting with their respective sub-teams which are collaborating during iteration(s).
3. Backlog grooming sessions can take place any time. You can do it before handoff (handoff meeting is required if you are working with multiple scrum teams) or during iteration planning (required if you are working with a single scrum team).
4. It is difficult to estimate, however with the experience of backlog grooming and sprint planning meetings estimation becomes very easy.
5. You need to create separate sprint backlogs for each product backlog item, they cannot be clubbed together in one single backlog which is a very common mistake most scrum teams make during the implementation phase. If that's the case then all sub-teams will share the same estimates during development only then variation will be observed when they meet at the last day of iteration based on number of item(s) completed.
6. Another common mistake is if a few product backlog items are going to be developed in a single sprint, then only those should be clubbed together and all other product backlog items should be kept as separate sprint backlogs.
7. It is also difficult for scrum teams to analyze the current velocity during each iteration planning meeting, so it's better to keep this analysis until the release planning meeting at last week of Sprint.