Product Backlog VS Sprint Backlog difference In Agile Methodology

1. What is a Product Backlog

The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog,(s)he is the one who prioritize it based on the customers feedback or business value. For details about how to write user stories, template, examples and acceptance criteria are already covered in our previous blog

1.1. Characteristic of a Product Backlog

It is a very active document where all the wishlist and user requirements are gathered
Product owner makes sure that content of product backlog “user stories” are defined in detailed level
user story in product backlog should be enough in sizing to be fit in one sprint
All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
The product backlog acts as an input to the sprint backlog when comes to functionality
There are also bugs/issues, epic, user stories and themes are included in the product backlog
There are also bugs/issues, epic, user stories and themes are included in the product backlog
To put it short: The product backlog is the wish list for the product for the whole lifecycle. It defined with its detail nature what to be implemented.

1.2. Techniques Used To Maintain Product Backlog Effectively

1.2.1. DIVE

Product backlog items are prioritized in linearly ordered based upon DIVE criteria

Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
Insure against risk (business and technical)
Business Value
Estimated Effort

1.2.2. DEEP

Detailed
Estimated
Emergent
Prioritized

1.2.3. INVEST

Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable A user story must deliver value to the end user.
Estimable You must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable The user story or its related description must provide the necessary information to make test development possible.

2. What is sprint backlog

There are also bugs/issues included in the sprint backlog for each sprint.

Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Onwer set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in timebox.

2.1. Characteristic of a Sprint Backlog

Sprint backlog is dynamic in nature,each sprint the above scenario is repeated. Good practice is to keep the sprint backlog aka sprint goal as static as possible during a sprint.
During each sprint planning session, the team returns back to product backlog to pick recently prioritized user stories for the sprint.
Sprint backlog is a subset of product backlog
Sprint backlog is an output of a sprint planning meeting.
In Sprint backlog, scrum team works on how the user stories would be implemented in a sprint by dividing it further into tasks and estimating it.
Assuming Product Backlog has stories: 1, 2, 3, 4 , 5 and 6. The team decides to do stories 1,2 and 4. As during sprint planning team realized that there still some question which is not answered well by the Product Owner, so they decided not to include the user story no: 3 and jump to user story no:4, which was defined well.
Sprint backlog is owned by the Development Team and contains what and how it get’s delivered
Lastly in sprint backlog team implementing (converting) the most prioritized product backlog items into working software. For each iteration (sprint) the team creates a new plan, based on what is in the top of the Product backlog when starting the sprint.