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 need 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 need 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.
Certain needs and functionalities may require preliminary research before real development. The research may cover technologies or development approaches.
In order 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 intended rapid development of parts of the product at the expense of technical quality.
“Technical debt” is one popular term for such cases. This usually happens 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.
This 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 users 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 users stories.
As an end 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 is a good alternative to context and benefits detailing in users 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 and typically describe activities on a system or part of a product that needs to be implemented so business requirements are satisfied. Functional
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
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
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 suggest 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 are aware of it and it is certain that this 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 a large list of product backlog items.
New items added to the product backlog contain short content that only describes the needs without going into big details. 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.
This 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 stakeholders that have a significant role in the product.
- Innovative breakthroughs.
- Functionalities and features defined after competitive analysis.
- 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 useless items.