The Why, What, Who and How of a Product Backlog in Agile Development

"Many ideas grow better when transplanted into another mind than the one where they sprang up." -Oliver Wendell Holmes

Why

About a decade ago, a new method for developing software efficiently and speedily began to take over the developer world. This method, Agile development, relies on a close collaboration between all team members and stakeholders. The Agile development philosophy includes keeping requirements and documentation concerning the product lightweight. In addition, the method recognizes that change is a normal, and actually an ordinary occurrence in software development. This makes close teamwork particularly important to clarify requirements and to keep all team members (including the product owner) on the same page throughout the development, and that "same page" is the product backlog in agile development.

What

A product backlog in agile development is a prioritized features list containing short descriptions of all functionality desired in the completed project. The product backlog is the system of record or the reliable data source for what teams should be working on as they develop a product or software application. In agile terms, it is also called the "information radiator," or the one place the priorities of the product owner are made clear and transparent to the team and anyone else who might be interested.

A typical product backlog is comprised of 1) features, 2) bugs, 3) technical work, and 4) knowledge acquisition. While every item, called product backlog items or PBIs, is logged into the product backlog not everything will be a direct description of a feature or function. Some PBIs might include architectural work, prototyping, and research. However, do not worry, just because numerous PBIs are there in the beginning, making the product backlog look unwieldy and all over the place, it will be "groomed" during subsequent team meetings. Grooming removes those PBIs that no longer appear relevant or that need to be reprioritized in keeping with the current understanding of the project and its objectives.

Who

A product backlog is compiled by those with a vested interest in the product being developed. It requires the input of the stakeholder or product owner and the team that is tasked with the building of the product or software. The compilation or filling of the product backlog happens in meetings, sometimes called sprint meetings, with the participation of every team member.

Focusing and giving real attention to this process is fundamental for every team member as this is the primary tool for understanding what is required for the successful completion of each sprint and ultimately the shippable product. Involving every team member in the process of the product backlog is essential, everyone can and should contribute to the creating of tasks listed on the product backlog, enabling the team to draw on different perspectives and generating a much richer list of features, functions, and knowledge acquisitions.

How

A product backlog can be as simple as post-its on a board, a white-board with items listed, or a spreadsheet. Many times each PBI is listed in the form of "user stories" and from those stories will come the task list that expresses the necessary work to be done. The hardest part of a product backlog can be the requirements list and a user story, when expressed correctly and used as intended, can describe a requirement with a bit of context, thus making whatever problem the feature is trying to solve understood.

The product backlog for a sprint includes every kind of task involved, including object modeling, coding, learning new techniques, database activities, and tests. Ideally, the team starts at the top of a prioritized product backlog and draws a line under the lowest priority they feel that they can complete in the sprint that is just starting. They may select some lower priority items that are associated with the higher items on the list because it will make sense to complete those during the current sprint.

At Contensive we practice an Agile development process that allows for total transparency. If you have any questions please do not hesitate to contact us, we want to be your online partner going forward and are ready to consult with you on your next project.