4.3: Product Backlog Taxonomy - Video Tutorials & Practice Problems

<v ->Now that we have defined the product backlog,</v> let's talk about product backlog taxonomy in Agile. We already know that Agile requirements are presented as a combination of user stories. Similar to those that we can see on the combine board here. So, let's dive deeper into the structure of a user story. We know that user stories define requirements. But this is usually not sufficient to establish the right level of detail. We need to implement and specify all relevant scenarios For this purpose, user stories contain acceptance criteria. Acceptance criteria could be expressed as a list of statements. For example, for an online bookstore, those statements could include, a user shall be able to view a book. A user shall be able to select a book. A user shall be able to place a book in a shopping cart. A user shall be able to review recommendations based on the book that they selected. A user shall be able to view the first three to five page of their book without a print option and so forth. However, this is not the most accurate way of defining acceptance criteria. The most accurate way has become popular over 10 years ago when acceptance test driven delivery or a TDD, took the conditional format used in the software languages, such as Gerkin, and became defining acceptance criteria in a table format given when done. Besides the title description and acceptance criteria, user stories may contain components such as database, UI, business logic, category, priority. Any constraints could be timelines based on market regulations, or laws, or business conditions. It has to contain estimation of complexity or time to completion. We will talk about estimation techniques a little bit later in this lesson. Comments to establish a full audit trail. Attachments, wire frames, data models, links to repositories and artifacts, and many other relevant data points. Let us talk about Invest. The acronym "Invest," is an mnemonic introduced by Bill Week. It helps to remember a list of criteria to assess the quality of a user story. I, stands for independent. User stories have to be as independent of each other, and external, and prerequisites as possible. N, stands for negotiable. It talks about what has to be done, not exactly how it should be done. It's a matter of negotiation between the product owner and the development team. V, stands for valuable. The business value of any user story should be listed in the user story description. And each story should be of value to a specific user type. E, stands for estimable. The effort required to complete the story can be estimated. So, the team can plan their work successfully and establish predictability for the delivery. S, stands for small. A user story should be small enough so that it can be completed within the short period of time. Usually at least within one sprint and testable. There has to be a clear way to verify whether the user story has been completed and we already discussed the acceptance criteria. That's the best way to identify whether the story has been completed or not. However, Agile requirements are not just a collection of individual user stories. Given that for larger systems, there are usually hundreds of user stories developed. Sometimes even over a thousand. Those user stories need to be prioritized, sequenced, and organized in a meaningful way. This way of organizing, prioritizing, and maintaining user stories is the product backlog. Let's look at the definition of a product backlog. The product backlog is a collection of prioritized discrete items of different types. Connected by parent-child relationships. Relationships between product backlog items are referred to as the Product Backlog Taxonomy. Agile does not prescribe the types of elements in the product backlog. Traditionally though, functional requirements are represented in user story format. The team uses product backlog and determines which format they choose to use. They look at the backlog items as reminders of the aspects of the solution that the team may work on. Besides user stories, other product backlog elements may include the following, epics. Epic captures a large body of work. It represents a feature that may be independently released to end users. It is usually written in the same format as a user story. For example, as a customer, I want to pick a flight ticket so that I can travel to a conference. This epic will include selection, criteria, user story, view details, functionality, and select functionality. Next one is technical task. Tasks do not provide user functionality but they're necessary for software development. For example, deploying applications on the cloud, building test environments, implementing security features, upgrading software tools, and so on. Now spikes. Spikes have research items. They're created to research the tool, to find the strategy, test performance, compare implementation methods, and so forth. They have a clear outcome which is learning and potential implementation, or tooling decision. But, they by themselves do not produce shippable products. They're prerequisites for user stories. The next one is sub-tasks. All of those user stories, app technical tasks, and sometimes even spikes, may be broken down into sub-tasks. Sometimes, also referred to as tasks. While each of those backlog items provides either end-to-end functionality or provides an answer to a specific question, sub-tasks are used to define responsibilities between team members. One person does coding, another tests, another one designs, and so forth. So, sub-tests are very helpful in planning and in aligning as a team during the execution phase. This is a sample product backlog taxonomy. The reason why I say sample is that as you know by now, Agile is a framework. It's not a very specific prescriptive methodology. It doesn't prescribe specific taxonomies or formats for product backlogs. Each organization optimizes against its needs and processes. For example, there may be other item types in agile organizations, such as bugs, risks, and so forth. It depends on organizational size, structure, reporting, and tracking mechanisms. Since Agile assumes continuous improvement, many organizations experiment with the most efficient structure that they want to use for their product backlog.