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
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.
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.
Types of product backlog items may be:
- User story
- Change request
- Research activity
- Technical improvement
- Use case
- Business requirements
- Functional requirements
- Non-functional requirements
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.
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.
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 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.
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 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 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 are often related to product quality. They do not describe behaviors, systems, functionalities, but rather requirements of quality, usability, efficiency, and other parameters.
Each product backlog item may include the following major attributes and contents:
- Acceptance criteria
- Definition of done
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 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.
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.
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.
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.
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 November 24, 2020, 4:03 pm
|0||Name||60 sec||PDM, PM|
|1||Content||60 sec||PDM, PM|
|2||Type||60 sec||PDM, PM|
|3||Business requirements||60 sec||PDM, PM|
|4||Change request||60 sec||PDM, PM|
|5||Characteristics of the product backlog items||60 sec||PDM, PM|
|6||Research activity||60 sec||PDM, PM|
|7||Product backlog items||60 sec||PDM, PM|
|8||User story||60 sec||PDM, PM|
|9||Priority||60 sec||PDM, PM|
|10||Use case||60 sec||PDM, PM|
|11||Additional product backlog items attributes||60 sec||PDM, PM|
|12||Major product backlog items attributes||60 sec||PDM, PM|
|13||What is Product Backlog Management?||60 sec||PDM, PM|
|14||Technical improvement||60 sec||PDM, PM|
|15||Activities, techniques, and approaches for effective Product Backlog management||60 sec||PDM, PM|
|16||Product backlog items types||60 sec||PDM, PM|
|17||Non-functional requirements||60 sec||PDM, PM|
|18||Acceptance criteria||60 sec||PDM, PM|
|19||Adding items to the product backlog||60 sec||PDM, PM|
|20||Defect||60 sec||PDM, PM|
|21||Definition of done||60 sec||PDM, PM|
|22||Functional requirements||60 sec||PDM, PM|
|23||Size||60 sec||PDM, PM|