Product backlogs are very important in Scrum since the entire product is “manufactured” by developing the set of product features and functionalities contained therein. A product backlog is a prioritized list of product features and contains short descriptions of all the functionalities envisioned in the product. While starting with a project in Scrum, it is important to write down “everything needed” to develop the product in totality. The stakeholders provide a “wish” list of all features desired in the product. Subsequently, the product owner creates a product backlog based upon the wish list. When enough “items” are created in the backlog, the actual Scrum process commences with a sprint planning meeting in which a few product backlog items having high business values are selected in the sprint backlog for development purposes.
The product backlog can “change” over time as the project begins. New features in the form of user stories or product backlog items may be added to enhance the product’s value in the market. The stakeholders may desire additional functionality in already developed product features to remain “in tune” with end users requirements and market-specific demands. It is important to carry out routine “grooming” activity and keep the backlog updated at all times to ensure that the business value of the project is maintained at all times – even while the product is being developed.
The product backlog items or user stories primarily consist of:
- Product features and functionality
- Epics – “Large” or “un-grained” feature items
- Technical reference/documentation
- Knowledge acquisition process/activity
User stories may also consist of other technical “stuff” and aspects but generally, include the above.
Properties of a Scrum product backlog
To be useful and effective, a Scrum product backlog should exhibit certain characteristics.
1. Visible to everybody
The entire Agile team needs to refer the product backlog at some time or the other. The product owner and the development team may access the product backlog on a daily basis, while the stakeholders may desire to check the business value of backlog items on a periodic basis to ensure that the business value of user stories is maintained. The Scrum master may refer to it to ascertain the acceptance criteria during the daily sprints. The product backlog should be easily accessible to all. Moreover, Scrum advocates transparency in all of its processes. The backlog should be visible to everyone.
2. Be a “single source” and reflect the “truth”
It is important to maintain a “single” copy or version of the product backlog. More than one “versions” of the backlog can lead to confusion – the team may erroneously start picking up user stories from outdated versions simply because it is unsure which version is most updated and should be followed. Moreover, the backlog should be properly refined from time to time through the grooming sessions. User stories in the backlog should be updated with respect to their business values so high priority stories can be selected in the sprint backlog during sprint planning sessions. The project should maintain its “business worth” at all times – even while the product is being developed.
3. Be dynamic in nature
The product backlog functions as a “living” artifact in Scrum. It is constantly updated and groomed by the product owner and team members. When the market conditions change or stakeholders feel the business value of the product can be further enhanced through the addition of new features, the backlog is updated to include those changes. Old or undeveloped user stories, which have lost their business values, can be removed from the backlog. The backlog items keep on “changing” all the time, and the backlog rarely remains “static”. The backlog should be dynamic in nature.