Skip to main content
Get a FREE
BVOP® Certified Project Manager mock exam
Join the modern BVOP® Agile teaching $ 0.00 mock exam fee. Free self-study Get a FREE Trial
Get Certified

Product Backlog management

Product Backlog management activities, techniques and approaches

Share on Linkedin Facebook
Product Backlog management activities, techniques and approaches

The following article is part of the self-preparation for the modern BVOP® Product Management Certification program.

This chapter explains Product Backlog Management in Agile and Scrum practices.

  1. What is Product Backlog Management?
  2. Activities, techniques, and approaches for effective Product Backlog management
  3. Product backlog items
    1. Product backlog items types
    2. User story
    3. Change request
    4. Defect
    5. Research activity
    6. Technical improvement
    7. Use case
    8. Business requirements
    9. Functional requirements
    10. Non-functional requirements
  4. Major product backlog items attributes
    1. Name
    2. Content
    3. Type
    4. Acceptance criteria
    5. Definition of done
    6. Size
    7. Priority
  5. Additional product backlog items attributes
  6. Characteristics of the product backlog items 
  7. Adding items to the product backlog

What is Product Backlog Management?

In the Scrum framework and other Agile oriented product development practices, Product Backlog management is performed by the Product Owner role to optimize the available collection of items (requirements, user needs, tasks, etc.) and to provide easier and more organized work to development teams.

Activities, techniques, and approaches for effective Product Backlog management

The activities, techniques, and approaches related to Product Backlog management most often relate to the creation of Product Backlog Items. Creating items often requires defining an appropriate title, content that clearly expresses the needs of the business or users, and adding any other relative elements that may support development teams and other stakeholders.

The report describes all popular examples of Product Backlog Items and their features.

The product backlog is a popular term in product management and is considered as a list of items (user stories, requirements, or activities) needed to create the product. The entire product management office, product teams, and other organizational departments have access to it.

The product backlog may be considered as an alternative to detailed documentation in project management practices where it doesn’t exist as an artifact. Many modern product-oriented organizations, which do not need to document scope and detailed initial requirements, and have no formal approval of documentation phases, rely entirely on the product backlog as a source of information and requirements about the product’s needs. In this case, the product backlog may serve as a guide for both product teams and business stakeholders.

Product backlog items

Product backlog items types

Types of product backlog items may be:

  • User story
  • Change request
  • Defect
  • Research activity
  • Technical improvement
  • Use case
  • Business requirements
  • Functional requirements
  • Non-functional requirements

User story

An informal and brief description of needs that may be part of the product. It is usually a written form representing the perspective of a potential user of the product regarding functionality or a feature. The user story describes the user who needs functionality or a feature, their contexts, and goals. A user story may match the following format:

As a (role), I need (capability), so that (receive benefit).

(role) - defines who needs something.
(capability) - the exact need
(receive benefit) a positive outcome for the requesting party (the user).

Example using this format:

As a customer, I need a solid package so the product can be transported safely.

Adding more context to user stories usually is useful for the product teams to define detailed product specifications. 

Example of adding more context to user stories:

As a user who has forgotten their password and does not remember the registration email, I need my account to be restored via phone, so I can continue to use it.

Product teams may use user stories as a source for detailed product specifications or create prototypes, sketches, graphics, and concepts.

Change request

If a change to the current product has undergone a change request process, the modifications may need to be added to the product backlog. 


Defects found on the product.

Research activity

Specific needs and functionalities may require preliminary research before real development. The research may cover technologies or development approaches.

To be adequately written down in the product backlog, the research activity should describe what exactly should be learned and the expected outcomes. “Spike” is one popular term for a research activity of this kind.

Technical improvement

Technical improvements can be executed if technical teams have previously developed rapidly parts of the product at the expense of technical quality.

“Technical debt” is one popular term for such cases. It regularly arises when the product needs to be delivered to an audience quickly or when deadlines are being met. Once the demonstrations have passed, technical improvements can be planned and added to the product backlog for further implementation. 

Use case

The Use case is usually a list or scheme describing the steps and events needed to complete a process. It can describe how functionality or parts of the product work or are supposed to work. The use case can be part of particular product backlog items or can be added to the product backlog itself as separate items.

Business requirements

Business requirements describe the high-level needs of business stakeholders related to a product. They can be considered as a more abstract concept than user stories.

Depending on their format and content, business requirements can be the equivalent of user stories if product teams and business stakeholders can operate efficiently using them (instead of user stories).

As a result, the business requirements describe a high-level presentation of business needs. Good practice when writing business requirements is adding a brief description of why a need is required and what value it adds to the product or organization. This addition is a good alternative to context and benefits detailing in user stories.

Product teams can use business requirements as a source for detailing product specifications or creating prototypes, sketches, graphics, or concepts.

Functional requirements

Functional requirements are created and used by technical teams. They typically describe the activities of a system or part of a product that needs to be implemented, so business requirements are satisfied.

Non-functional requirements

Non-functional requirements are often related to product quality. They do not describe behaviors, systems, functionalities, but rather requirements of quality, usability, efficiency, and other parameters.

Major product backlog items attributes

Each product backlog item may include the following major attributes and contents:

  • Name
  • Content
  • Type
  • Acceptance criteria
  • Definition of done
  • Size
  • Priority


The name describes the item in short.


The actual content of the item. It may be a text, graphic, sketch, animation, or any other format depending on the item type and the needs of product teams and business stakeholders.


The type can be useful for differentiating and filtering different kinds of product backlog items.

Acceptance criteria

Acceptance criteria is a popular term in software engineering and is closely related to acceptance testing procedures where parts of the product undergo different types of testing.

Acceptance criteria may be considered as a scope description of a particular product backlog item and of the exact created and tested needs in the context of the item.

They are usually created for teams that develop and test the product and are used as strict guidance. Informally, the acceptance criteria explain when the work on a product backlog item may be considered as completed.

Definition of done

The definition of done is a written description that formalizes that a product backlog item is really done in terms of development, testing, deployment, delivery, or formally accepted by stakeholders or customers. It may include particular steps, activities, and roles involved in the actual acceptance of the work.


Describes the approximate amount of work needed for a product backlog item to be fully completed.


Shows the priority of a product backlog item.

Additional product backlog items attributes

Product backlog items may have many and unlimited attributes. Additional attributes can be “Status”, “Feature”, “Release”, “Start date”, “Completion date”, and many others, depending on the needs of the organization and teams.

Too many attributes, however, can make it difficult for teams to work and use the product backlog.

The BVOP suggests using business attributes that describe the business value of each product backlog item. Details are introduced in the Product Backlog Prioritization section.

Characteristics of the product backlog items 

The content of the product backlog items and all their attributes must be understandable to all teams and stakeholders involved in the product.

Incomprehensible content and attributes may result in product delays and cause misinterpretations and wrong implementations of parts of the product.

Too specific terminology may only be used if all participants in the product development are aware of it, and if this terminology usage will not lead to any loss of any kind.

Too long and complicated documentation or product backlog items may lead to delays in the work of the teams, as can insufficient information, which may also be the cause of waste, and wrong implementations.

The accuracy of the information is also of particular importance for fast and optimized product development.

The Business Value-Oriented Product Management (BVOPDM) office, together with development teams and business stakeholders, decides the attributes of the product backlog items, their types, and content.

Adding items to the product backlog

Backlog items are added in stages when new needs are identified as opposed to initially creating complete documentation or an extensive list of product backlog items.

New items added to the product backlog contain short content that only describes the needs briefly. Item attributes may also be skipped initially.

Details to documentation and product backlog items are added in stages when business stakeholders or development teams need them. 

Providing details when they are needed achieves speed and flexibility of the product development, while obsolete requirements and unnecessary work are avoided.

Adding items to the product backlog is recommended only as a result of the following activities and circumstances:

  • Agreed and defined requirements in project management stages.
  • Defined product requirements (user stories, business requirements, functional requirements) as a result of already discussed users or business needs, or other product research events.
  • Requests from users with high product knowledge.
  • Logical dependencies between user needs and business requirements.
  • Requests from key stakeholders.
  • Identified innovative breakthroughs.
  • Functionalities and features, defined after competitive analysis.
  • Collected needs, defined as important, after testing the product with users.
  • Found defects.

If functionalities or product features are required by teams, offices, or stakeholders that do not have sufficient product knowledge, the requirement needs to be discussed with the requesting party repeatedly until the business value of the required functionalities or features is apparent.

The number of items in the product backlog should have a reasonable count in order to avoid chaos, lack of order, and massive product backlogs containing nonvaluable items.

The following issues related to chapter "Product Backlog management" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of March 18, 2023, 2:49 pm

ID Issue Time Category
0 Product backlog items 60 sec PDM, PM
1 User story 60 sec PDM, PM
2 Research activity 60 sec PDM, PM
3 Functional requirements 60 sec PDM, PM
4 Business requirements 60 sec PDM, PM
5 Priority 60 sec PDM, PM
6 Size 60 sec PDM, PM
7 Definition of done 60 sec PDM, PM
8 Activities, techniques, and approaches for effective Product Backlog management 60 sec PDM, PM
9 Additional product backlog items attributes 60 sec PDM, PM
10 Major product backlog items attributes 60 sec PDM, PM
11 Change request 60 sec PDM, PM
12 Content 60 sec PDM, PM
13 Defect 60 sec PDM, PM
14 Use case 60 sec PDM, PM
15 Type 60 sec PDM, PM
16 Product backlog items types 60 sec PDM, PM
17 Acceptance criteria 60 sec PDM, PM
18 Technical improvement 60 sec PDM, PM
19 Name 60 sec PDM, PM
20 Characteristics of the product backlog items  60 sec PDM, PM
21 Non-functional requirements 60 sec PDM, PM
22 What is Product Backlog Management? 60 sec PDM, PM
23 Adding items to the product backlog 60 sec PDM, PM

Comments on “Product Backlog management activities, techniques and approaches”

  1. Lucas Thompson

    Does anyone know historically where the Product Backlog practice originated? I am interested in Product Backlog Management if it is an activity that was created for the Scrum framework or if it is a practice that is included in Scrum.

Web site
Your Comment

The BVOP Certificates

Certified Chief Executive

The BVOP Chief Executive is the core driver of the Business Value-Oriented Principles and the most advanced figure who has the organization’s best interest.

Get Certificate $1290   $270

Certified Program Director

The BVOP Program Director manages the entire Program Management Office and possesses exceptional expertise and applies strategies.

Get Certificate $720   $190

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations. Take it to the next level.

Get Certificate $440   $180

Certified Project Manager

The BVOP Project Manager is an advanced and competent business, product, and technical role and a key factor for the success of the projects.

Get Certificate $280   $130

Certified Product Manager

With the advancing design, development, technical, and business knowledge, the BVOP Product Manager is a master role and decision-maker for the products.

Get Certificate $280   $130

Certified Product Owner

Responsible and skilled BVOP Product Owners balance both business and technical needs using Agile approaches and provide business value for products.

Get Certificate $180   $90

Senior Scrum Master Certification

The BVOP Scrum Master role combines skills, Agile thinking, and project management practices to enchant processes, teams, and stakeholders.

Get Certificate $140   $70

Certified Human Resources Manager

People are the greatest assets of any organization. It is important to find a balance between people and organization’s needs. Start the change today.

Get Certificate $140   $70
Become a Certified Project Manager
$280   $130
FREE Online Mock Exam