WHY A PRODUCT BACKLOG?
The Product Backlog is:
- The most important of the Scrum artifacts and any agile approach.
- The representation of the work to be done. It gives a shared vision of what the team will produce. It thus ensures transparent monitoring of the work and the client’s “requirements” with regard to the expected final product.
- The WHAT of an agile project. As such, it must be established, maintained, updated and disseminated as quickly as possible.
- The single source of requirements for all changes to be made to the product. The Product Owner is responsible for the Product Backlog: its content, distribution and scheduling.
- The Product Backlog is not a functional specification document: it describes the WHAT rather than the HOW. Therefore, additional functional documentation may be required on a project.
WHEN TO DO A PRODUCT BACKLOG?
- The Product Backlog must be established from the beggining of the project, either by the Product Owner on the client side, or from the pre-sales phase.
- During the first workshops, the Product Owner adds the initially identified requirements to the Product Backlog.
- The Product Owner regularly updates the Product Backlog until the end of the project.
- The Product Backlog persists as long as the product exists, it has no end.
WHO CREATES AND MAINTAINS THE PRODUCT BACKLOG?
- The Product Owner is responsible for the Product Backlog: its content, distribution and scheduling.
- The Product Backlog is not fixed. In an agile context, it evolves in line with changes in the product and its user environment.
- The Product Backlog is therefore flexible, undergoing continuous changes to align with the evolving needs of the product in order to deliver value.
HOW DO YOU BUILD A PRODUCT BACKLOG?
Product Backlog Content
The Product Backlog lists the items that define the product:
- Main features: The key features of the product or project.
- Technical tasks: The technical work required to implement features.
- Bugs and fixes: Problems to resolve and corrections to make.
- Improvements: Suggestions for improvements or optimizations to the product.
- Business Requirements: The functional and non-functional requirements of the customer or users.
In an agile framework, we recommend writing items in the form of User Stories.
Product Backlog items are ranked according to their Business priority. Estimation comes later, when selecting items to include in a given sprint.
The Sprint 0
The Product Owner holds several meetings to create the Product Backlog. Methods used include:
- Work workshops.
- Individual interviews.
- Use of questionnaires.
Each meeting with users should have a specific objective, agreed upon when scheduling the meetings. If necessary, the Product Owner can be assisted by the Quality Analyst and/or the Business Analyst.
It is possible to organize a meeting halfway through Sprint 0 to present the first progress.
In general, during Sprint 0, we identify the Minimum Viable Product (MVP) , which consists of defining the product with the minimum number of features necessary to satisfy the user and obtain initial feedback.
Formalization
The Product Backlog can be created in Excel table, with for each item of the Product Backlog, at least:
- Description: As< role> , I can< action> in order to< result>
- Priority: within the Product Backlog
- Size: in load and/or complexity
- A Business Value: Business Value of the User Story
- Acceptance criteria: Given< a state of the application> , When< action> SO< result>
- The Epic’s benchmark
Other columns can be added in ad hoc mode, as you go along, such as an iterative distribution column, a status column (“New”, “Ready”, “In Progress”, “Done”)
Refinement (Grooming) of the Product Backlog
Early items in the Product Backlog are more detailed, allowing for a more accurate estimate, while later items are less detailed.
The elements of the next Sprint are refined to be achievable in one Sprint and are ready for planning.
Attention !
- In case of extreme emergency.
- When a User Story has become obsolete.
- After negotiation, in exchange for the deletion of a User Story of equivalent size that has not yet started.
- By taking care not to overload the team, because it is committed to a simple and well-defined scope.
It is possible to modify the rest of the Product Backlog, but it is essential to take the scope into account, particularly in the context of a fixed-price project.
Product Backlog Estimation
The Backlog estimation process is an ongoing process that occurs as follows:
- The initial estimate is made during the pre-sales phase, which represents the initial size of the Backlog.
- During Sprint Planning meetings and Product Backlog reviews, the estimate is revised to reflect the current size.
The Development Team is responsible for the estimate, although the Product Owner can influence by providing information and guidance, it is the team members who provide the final estimate.
Focus on Technical Tasks
It is essential to include technical tasks in the Product Backlog and estimate them.
Example of non-functional technical task:
As a front-end developer, I want to optimize website images using lossless image compression, so that the site loads faster for users and improves user experience.
Recommendations: Mistakes to Avoid
The ten mistakes to avoid in Product Backlog management:
- Not having a Product Backlog.
- Having multiple Product Backlogs for a single product (or other spurious sources).
- Not sharing the Product Backlog with the entire team.
- Do not update the Product Backlog during the project.
- Not prioritizing items or giving them equal priorities.
- Having elements that are too precise and/or too vague in the Product Backlog ( INVEST criteria).
- Not having enough ready elements to supply the development team during the next Sprint.
- Constantly adding new items without evaluating their value or priority.
- Not actively involving the Product Owner in managing and updating the Product Backlog.
- Ignore end-user feedback when adding or editing items in the Product Backlog
0 Comments