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.
- What is Product Backlog Management?
- Activities, techniques, and approaches for effective Product Backlog management
- Product backlog items
- Major product backlog items attributes
- Additional product backlog items attributes
- Characteristics of the product backlog items
- 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.
Defect
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
Name
The name describes the item in short.
Content
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.
Type
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.
Size
Describes the approximate amount of work needed for a product backlog item to be fully completed.
Priority
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 December 10, 2024, 11:53 pm
| ID | Issue | Time | Category |
|---|---|---|---|
| 0 | Product backlog items types | 60 sec | PDM, PM |
| 1 | Research activity | 60 sec | PDM, PM |
| 2 | Priority | 60 sec | PDM, PM |
| 3 | Non-functional requirements | 60 sec | PDM, PM |
| 4 | Technical improvement | 60 sec | PDM, PM |
| 5 | Acceptance criteria | 60 sec | PDM, PM |
| 6 | Type | 60 sec | PDM, PM |
| 7 | User story | 60 sec | PDM, PM |
| 8 | Change request | 60 sec | PDM, PM |
| 9 | Product backlog items | 60 sec | PDM, PM |
| 10 | Defect | 60 sec | PDM, PM |
| 11 | Major product backlog items attributes | 60 sec | PDM, PM |
| 12 | Definition of done | 60 sec | PDM, PM |
| 13 | Business requirements | 60 sec | PDM, PM |
| 14 | Adding items to the product backlog | 60 sec | PDM, PM |
| 15 | What is Product Backlog Management? | 60 sec | PDM, PM |
| 16 | Functional requirements | 60 sec | PDM, PM |
| 17 | Content | 60 sec | PDM, PM |
| 18 | Additional product backlog items attributes | 60 sec | PDM, PM |
| 19 | Activities, techniques, and approaches for effective Product Backlog management | 60 sec | PDM, PM |
| 20 | Name | 60 sec | PDM, PM |
| 21 | Size | 60 sec | PDM, PM |
| 22 | Use case | 60 sec | PDM, PM |
| 23 | Characteristics of the product backlog items | 60 sec | PDM, PM |
Comments from the BVOP™ community on “Product Backlog management”
Summary
Product Backlog Management is the optimization of items by the Product Owner role in Scrum and Agile practices to provide more organized work for development teams.
Creating and defining items
Product Backlog management involves creating and defining items, such as user stories and requirements, to support development teams and stakeholders. The product backlog is a list of these items, which can serve as a guide for product teams and business stakeholders. It can replace detailed documentation in project management and is accessible to the entire product management office and organizational departments.
Types of product backlog items include user stories, change requests, defects, research activities, technical improvements, use cases, business requirements, functional requirements, and non-functional requirements.
Brief description of a potential user's needs
A user story is a brief description of a potential user's needs for a product's functionality or feature. It typically follows the format "As a (role), I need (capability), so that (receive benefit)." Adding more context to user stories can help product teams define detailed specifications. User stories can be used as a source for creating prototypes, sketches, graphics, and concepts.
Changes to the product may require adding modifications to the backlog. Defects found should also be noted. Research may be necessary for specific needs and functionalities, and should be described in the backlog. Technical improvements can be planned after rapid development, known as "technical debt."
Description of the steps and events
A use case is a description of the steps and events needed to complete a process. It can describe how a product works or is supposed to work. It can be included in product backlog items or added as separate items.
Business requirements are high-level needs of business stakeholders for a product. They are more abstract than user stories. If product teams and business stakeholders can operate efficiently using them, they can be the equivalent of user stories. Business requirements describe a high-level presentation of business needs and should include a brief description of why a need is required and what value it adds. They can be used as a source for detailing product specifications or creating prototypes, sketches, graphics, or concepts.
Activities of a system or product
Functional requirements describe the activities of a system or product that need to be implemented to satisfy business requirements. Non-functional requirements relate to product quality, such as usability and efficiency. Product backlog items have attributes including name, content, type, acceptance criteria, definition of done, size, and priority. The name describes the item briefly and the content can be in various formats. The type helps differentiate and filter different items.
Guidelines in software engineering
Acceptance criteria are guidelines used in software engineering to test different parts of a product. They describe the scope of a backlog item and when the work is considered complete. The definition of done formalizes the completion of a backlog item in terms of development, testing, and acceptance. Size refers to the amount of work needed, while priority shows the item's importance.
Various attributes
Product backlog items can have various attributes such as status, feature, release, start and completion dates, and more. However, too many attributes can make it challenging for teams to work efficiently. The BVOP recommends using business attributes that describe the business value of each item. The content and attributes of the product backlog items should be understandable to all teams and stakeholders involved in the product development. Using specific terminology is acceptable if everyone understands it, and long and complicated documentation may lead to delays. The accuracy of information is crucial for fast and optimized product development. The BVOPDM office, along with development teams and business stakeholders, decides the attributes, types, and content of the product backlog items.
New items
New items are added to the product backlog in stages as needs are identified, rather than creating a complete list upfront. Details are added as necessary to achieve speed and flexibility in development while avoiding unnecessary work. Only agreed and defined requirements, user needs, key stakeholder requests, innovative breakthroughs, competitive analysis, collected needs, and defects should result in new backlog items. Requests from those without sufficient product knowledge must be discussed until the business value is clear. Keep the backlog at a reasonable count to avoid chaos.
- Previous article Product research practices
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.