The following article is a sample from the full BVOP™ Ultimate Guide and is part of the preparation for the BVOP™'s modern Agile Product Management Certification Program.
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 the product backlog may not 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 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
- 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 feature. The user story describes the user who needs functionality or 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 my account.
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 task should describe what exactly should be learned and the expected activity outcomes. “Spike” is one popular term for the research activity of this kind.
Technical improvements can be executed if technical teams have previously applied a rapid development of 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 the product backlog items or added to the product backlog as separate items.
Business requirements describe the high-level needs of business stakeholders related to a product. They can be considered as a higher and abstract level than user stories.
Depending on their format and content, they can be the equivalent of user stories if product teams and business stakeholders can operate using business requirements instead of user stories.
As a result, the business requirements describe a high-level presentation of business needs. Good practice in writing business requirements is a brief addition 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 activities on 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.
Major product backlog items attributes
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 types of product backlog items.
Acceptance criteria is a popular term in software engineering and are closely related to Acceptance testing procedures where parts of the product undergo different types of testing.
They may be considered as a description of the scope of a particular product backlog item and of what exactly needs to be created and tested 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, Started date, Completed 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, while insufficient information may also cause waste, delay, 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
Adding items to the product backlog takes place in stages when new needs are identified instead of 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 without going into great detail. 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 communicated users or business needs, or other product research events.
- Requests from users with high product knowledge.
- Logical dependencies of needs and 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 communicated back to the requesting party until the business value of the required functionalities or features is demonstrated.
The number of items in the product backlog should have a reasonable value to avoid chaos, lack of order, and massive product backlogs containing not valuable items.