Introduction
Let’s start with a short description:
- Product Backlog - Product backlog consists of prioritized product backlog items.
- Product Backlog Item - Product backlog item mainly specifies requirements or enhancements required.
How does “Product Backlog” come into the picture?
Say a product needs to be built by a manufacturer. The manufacturer will contact the right software company and a person of contact from their side – Product Owner. The product owner will ask the team to identify the best model/approach that needs to be followed for product development. Once, everyone agrees on using agile, the product owner will make a product backlog containing high-level features as product backlog items. From product backlog, items will be taken in sprints.
Product Backlog
The product backlog consists of prioritized product backlog items. The product backlog is never complete. It is defined as we go through the project development. Priorities might be changed in mid-way of software development as well because agile allows that. Going through product backlog items and defining the required criteria is part of the agile process.
So, product backlog has many product backlog items, but only the required and necessary ones that can be taken into next some of the sprints are well defined/detailed with requirements.
- Backlog Refinement
Taking feedbacks from stakeholders/customer, the Product owner will set a meeting with the team to refine/groom the product backlog items which are not fully defined. This meeting mostly lasts 1-2 hours and happens 1-2 times during sprint until the whole backlog is well defined and pointed. In this meeting, the below things happen:
- Ideas will be shared to groom product backlog items.
- Impediments will be shared by the team if any that can be faced during development.
- Effort/Story points for the product backlog items will be provided.
The output of the meeting
- The product backlog is reprioritized if needed
- Product backlog items are pointed as per need.
- Product backlog items that are going to be taken by the team in upcoming sprints.
Structure of Product Backlog
Product Backlog Items (PBIs)
Product backlog item is nothing but requirements specifying which part of software needs to be developed as part of it. Many people call it a “User story” as well. It can be shown in the below states:
- New - When the product owner adds it
- Approved - When there are no dependency/impediments to develop the PBI and when the requirements are clear.
- Committed - When a team is ready to commit the story during sprint
- Done - When product owner reviews the part of software developed as specified in PBI and agrees that it meets the criteria specified in PBI
Type of Product Backlog Items,
- SPIKE PBI - These are the PBIs that are being added for investigation and R&D for the requirements.
- Bug PBI - These are the PBIs added when there is any defect/bug found as part of any previous PBI.
- Product Backlog Item - These are normal and added when new requirements/enhancements are required.
Once PBI is committed and taken in sprint, it will be divided into tasks to measure the progress of it over sprint. The task will be of size mostly a day because bigger size task will not be easy to track. So, it is advisable to divide the task if it takes more than a day. A task will be taken by a team member every day. During the next day’s daily meeting, he will provide an update regarding it and the next task he is going to take. A task has three statuses New, In-Progress, and Done.
Below are some attributes considered for Task:
- Assigned - To whom the task has been assigned.
- Hours - How many hours are required to complete the task?
- Description - What has been developed as part of this task?