Product Backlog In Scrum

Product Backlog In Scrum
People prefer using lists when they plan activities or things to do. While planning projects, people still prefer using lists to remind them about what activity they are supposed to do, at what time, and in what manner. It is important to record what has been accomplished, and what more needs to be done in a project. Things are not much different in Scrum. A Scrum project commences when a list is created which contains what all needs to be done to develop a product. The list is known as the product backlog.

What does a product backlog in Scrum actually consist of? To understand the product backlog, it is imperative to know how Scrum actually works. In Scrum, the entire product is broken down into its basic features and functionalities which are developed through product incremental cycles known as “sprints”. Each product feature and functionality is “described” individually in list items known as “product backlog items” or “user stories”. The list items – all of them – are combined together to form the “master” list or the product backlog in Scrum. In short, a product backlog is an ordered list of “everything” needed to develop the product in totality. The backlog functions as a “single” source of all requirements, and everyone uses this list to develop the product by selecting a few list items, or product backlog items, having high business value and developing them in daily incremental cycles or daily sprints.

The product backlog is managed by the product owner – a person who represents the project owners or stakeholders, and functions on their behalf in the project. The product owner is often helped by the development team and the Scrum master to maintain the product backlog. The main function of the product backlog is to:

  • “Capture” and store all requests for developing the product. It can include new features, functionalities, related documentation, testing or “acceptance” criteria, etc. Moreover, each list item – the product backlog item – can be updated as and when necessary, primarily by the product owner based upon the feedback received from the stakeholders and the development team.
  • Provide developable “items” in the form of “useful” user stories to the development team so it can “program” and create the features through the daily sprint cycles.

Product backlog items

Product backlog items form the “heart” of the product backlog. Agile Scrum does not attempt to define or state what exactly a product backlog item should be like, but rather suggests what it should ideally contain. When backlog items are “goal-oriented” and focus upon the “what” aspect rather than the “how” aspect, they prove to be more useful and effective when they are developed. Moreover, backlog items should be listed or “designed” from the end user’s perspective. That way, each item can maintain its usefulness and worth from the market point of view. Furthermore, large backlog items commonly referred to as “epics” in Scrum should be “broken down” and made simple so they can be easily managed and developed by the team during the sprints.

Product backlog items can be of different types depending upon why they have been created and what they represent.

1. User stories

Depicting new features or functionalities.

2. Bugs

A defect in an existing feature or functionality which needs to be corrected.

3. Chores

Work or activity required to be carried out to initiate or complete a process. The activity has no direct business value but it is essential to carry it out.

4. Epics

Large user stories that are too “generalized” and cannot be developed as a “whole”. Epics are generally created at the time of project inception and later “refined”, and made more “granular”. Epics need to be broken down into simpler forms which are easily manageable and developable during the daily sprints.

Do you want to create product backlog?