What is a Product Backlog in Scrum?

A product can be a service, product or software. The product backlog is the list of functions and user stories of a product. The feature list is often maintained using Trello or Jira. The most valuable functions of the Product Backlog are sorted. The most important function is on top and defined as the most important function. In the refignment meeting, the scope of the functionalities is estimated. In the refignment meetings, the functions are defined and recognized by the product owner with the developers. A refignment meeting must not represent more than 10% of the development time. The product owner maintains the product backlog.

The first or initial Product Backlog, the task list is extensive when creation begins. The product owner must have a vision for the product when defining the user stories. The development team and their expertise is needed when creating the user stories. He must know the product line and roadmap of the company's products. The first functional product and accepted by the customer is Minimum Viable Product (MVP) whereupon feedback can be given for further development. Stackholders such as customers or buyers can and should help define the requirements and provide feedback.

The Product Backlog is a list of functions of the product, service or hardware. The functions of a software or hardware are determined in a "requirements workshop" using creativity techniques. The product owner builds the product backlog in which the tasks so-called product backlogs items (PBI's) are located. The items can be documented in an Excel spreadsheet or in tools like Jira. With Jira it is possible to split the Product Backlog or to sort it. Many Scrum teams use sticky notes on which requirements are written. On the back of a sticky note it is possible to describe acceptance criteria of a function. By being haptic, flexible in handling and hanging the sticky note on a wall, dialogue and communication is encouraged. The product owner prioritizes the requirements. The requirements that are important and should be implemented are at the top and are well defined, structured and can be processed in a sprint of a maximum of four weeks. The prioritizations can be done according to revenue, cost, risk, risk-value assessment and knowledge building. Tasks that have a high risk and value should be prioritized so that uncertainties are eliminated. Next, tasks that have low risk and high value are prioritized. Then prioritize tasks that have low risk and value. Tasks with high risk where no valuable increment can be delivered should not be prioritized but deleted and avoided.

A product backlog should be designed according to DEEP. Detailed. The tasks and user stories in the Product Backlog are detailed and meet the quality criteria of the Definition of Ready and other individual quality criteria for a user story. The Product Backlog should have an abundance of tasks for the next 1-2 sprints. Emergent. The Product Backlog and User Stories can be modified, extended or removed (agile approach). Estimated. The effort should be estimated so that the resources for a sprint and the implementation can be planned. Prioritized. It must be possible to sort the user story according to functions that are important to the customer. Prioritization must be based on value, complexity (meet unknowns early), implementability (entries must be able to be implemented with existing expertise), independence (user stories must stand alone). The product owner creates and maintains the product backlog with the scrum master and development team.

In Jira, the backlog looks like this; A story can be created by Create Issue:

Backlog Atlassian Jira

Product Backlog in Jira

A Product Backlog contains Product Backlog Items (PBIs). A Product Backlog Item that is at the top of the Backlog Item (and most valuable to the customer) should be designed according to the INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable) principle. Product backlog items can be functions (features), software errors (defects or bugs), technical work (infrastructure tasks, CI/CD tasks, deployment pipeline, etc.), or knowledge enrichment experiments. Features may preferably be described in a user story, use case, or free-form text. Projects may be technically deficient in design. These defects are listed as a defect (technical debt). Software defects can also be kept in a separate backlog or issue tracker. Each product backlog item must also have an estimate of effort listed.

What is a user story in the agile project management method Scrum?

The requirements are best defined as user stories. They are described in the language of the customer. The customer's expectations of the product, service or process are described. For example, a user can search the product list via a search mask and gets a result. Technical details and processes are omitted. In a good user story, the who, what, and why must be clarified. User Story's are described via a template: As a <type of user (customer, user, role); Who>, I want <a goal (function, requirement); What> so that / with it <benefit (reason); Why>. In a user story, the goal must be clearly communicated. As a user, I want to search for a customer ID so that a customer can be found faster. This representation helps the stack holders to better understand the need of the customer. The user story is sorted by priority and story point. The priority is the importance and value of a user story and the story point is the effort to implement a user story. If User Stories are more extensive, they can be subdivided and assigned to an Epic. If a user story is even more extensive, a theme is defined.

In Jira, the Epic version can be activated as follows and created with Create Epic.

Backlog Atlassian Jira

Product Backlog in Jira

A Product Backlog contains Product Backlog Items (PBIs). A Product Backlog Item that is at the top of the Backlog Item (and most valuable to the customer) should be designed according to the INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable) principle. Product backlog items can be functions (features), software errors (defects or bugs), technical work (infrastructure tasks, CI/CD tasks, deployment pipeline, etc.), or knowledge enrichment experiments. Features may preferably be described in a user story, use case, or free-form text. Projects may be technically deficient in design. These defects are listed as a defect (technical debt). Software defects can also be kept in a separate backlog or issue tracker. Each product backlog item must also have an estimate of effort listed.



Request for EXIN Agile Scrum

You want to take an EXIN Agile Scrum training? Please fill out the following form. We will then get in touch with you.

EXIN Partner




First name
Last name
E-Mail
Message