Agile Product Backlog vs. Sprint Backlog

Instructor: Pedro Acevedo
This lesson explains the main differences between a product backlog and a sprint backlog in agile software development, how each of those backlogs is used, and the responsibilities that the customers and developers have in relation to those backlogs.

Product and Sprint Backlogs in Agile Software Development

There is a common joke that goes, 'How do you eat an elephant? One bite at a time.' This means that large tasks can be achieved by breaking them up and working on those smaller pieces. This principle applies to just about every type of work you can think of. In this lesson, we will learn how it applies to agile software development.


Agile software development is a way of developing software that emphasizes frequent communication with the customer and small, frequent releases. These small releases are developed during periods of time known as sprints, which are usually no more than a month long. The list of all required (but not yet implemented) features for that software product constitute the product backlog, and a subset of those features are selected at the beginning of each sprint to become the sprint backlog; that is, the set of features that the team is expected to deliver at the end of the sprint.

Let's think about that elephant for a second. We can compare the product backlog to the elephant, and the sprint backlog to the individual bites. The product backlog can get quite long, and the development team cannot work on all of the features at the same time, so they take a few bites out of the elephant - the sprint backlog - during each sprint. The customer is likely to continue adding requirements throughout the product's lifetime (it's a magically regenerating elephant), so this exercise in picking a subset of the backlog to work on is repeated regularly.

Eating the software elephant with agile silverware.
Elephant on a dinner plate

The ElephantCo Product Backlog

Suppose a company called ElephantCo has hired your team to produce a website that showcases elephant recipes from around the world. The product backlog initially looks like this:

  1. Allow the user to search for recipes
  2. Allow the user to leave comments on each recipe
  3. Allow the user to submit new recipes
  4. Display an image for each elephant recipe

There is no specific format in which product and sprint backlogs should be kept. Some teams write the product requirements on index cards or sticky notes on a board. Maybe your team decides to use specialized software to track your backlogs instead. Whatever method you use, the customer owns the product backlog and is responsible for making sure that it is always ordered according to which items they consider most valuable. After all, ElephantCo has already done all the market research for elephant recipes and knows better than you do which features chefs will find most useful.

Having the customer take care of prioritizing the work means that you don't need to spend time thinking about what to do next, but rather how to do it. And since ElephantCo is responsible for ordering the backlog, they can also reorder it at any time according to business needs, technical limitations, or other reasons. Elephant cooks are notoriously fickle, so don't count on their priorities remaining the same from one sprint to the next.

Biting into the Elephant: the Sprint Backlog

Even though ElephantCo owns the product backlog, you and your team collaborate with ElephantCo to make sure that you all agree on what each backlog item requires, or obtain any needed clarification. By ensuring that the backlog items are clearly stated and that your team understands them, the customer helps your team estimate how much work each item will require. These estimates, in turn, help you know how much of the product backlog you can 'bite off' to work on during the sprint.

In this case, after meeting with the company's Chief Elephant Officer, your team decides that they can implement features #1 - #3 during a two-week sprint. Even though the customer decides which features are the most valuable to be worked on, ElephantCo cannot force the developers to take on more work than they estimate they can finish within the sprint's time frame. The development team owns the sprint backlog.

There is a good reason for this: you know better than ElephantCo how your team works, and you are in a better position to tell when an unexpected turn of events might require a change to the agreed-upon sprint backlog. For example, your team discovers that item #1 requires much more work than expected. You hadn't realized that letting users search by method of cooking (stew, bake, stir fry) requires completely different code than searching by type of dish (appetizer, main course, dessert). With this newfound knowledge, you realize that you will not have time to implement all three features that you selected for the sprint backlog, so you go back to the CEO and explain that there isn't enough time to get everything done.

To unlock this lesson you must be a Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use

Become a member and start learning now.
Become a Member  Back
What teachers are saying about
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account