In this lesson we are going to talk about one of the most important documents in Agile Scrum called product backlog. So, the product backlog is basically the document that contains all the requirements that are related to build the product. This document can be considered as the Brd or the business requirements document equivalent in the in Agile Scrum. So, the main difference is, in Brd, which is typically in the waterfall methodology type projects the Brd is is a static document where, you know, once the requirements are completed, the only way you can make changes to the Brd is basically through some change management process, some change control process, as compared to Brd the product backlog is a dynamic document the contents of the document key can change throughout the course of the project. Basically, you agile team and the product owner determines that which of the stories from the product backlog are going to be making it to the first release or this particular release that they're working on.

But the product backlog itself is a dynamic document you can keep adding stories to the to the product backlog as as necessary. Also, the product owner is owns this document, so he or she is accountable as well as responsible for this document. Some of the main items in this document include stories, effort estimates to build the story, priority of the story, etc. So a few concepts that I wanted to clarify in the product backlog features, islands, themes, epics and stories. So let's first talk about What do we mean by features and islands? So a feature is a distinct element of functionality that can provide capabilities to the consumer.

So feature we have thought we have dealt with in many areas in our life, including waterfall methodology and other methodologies. Basically, the definition of feature is it's a distinct element of functionality that can provide capabilities to the consumer. So that's that's what a feature is. An island, on the other hand, is a way to categorize user stories. So for example, all user stories dealing with a particular type of user can be categorized under that user. And that that would be the island for example, say any of the stories that are related to a vendor for that project that can be categorized under an island country.

Vendor. So that's kind of the difference between a feature and an island. So this pictorially just depicts that a feature can have multiple stories within it. So it's a feature doesn't have to have a one to one relationship with a story. But a feature can have multiple stories under it So, and all the features combined together from gives us the product. So that's a little bit about features and islands.

Next, we're going to talk about the themes, epics, stories, tasks. What is the difference between these four? So a theme, it's a top level objective that may span projects or products. Themes can be broken down into sub themes, which are more likely to be product specific. And at its most granular form, a theme maybe an epic so on this one Get more clear as we go through an example in the next slide. But let's kind of talk a little bit more about themes.

Themes can be used to use at both program and project level to drive strategic alignment and communicate a clear direction. So a theme, for example, can be back, we want to increase our web presence. You can spawn multiple different projects, multiple different products, in this case, maybe multiple different web applications in order to fulfill that theme. So that's, that's, uh, that's an example of a theme. And agile as epic, on the other hand is it's basically a group of related user stories. So this is, in most simple language.

This may be a bigger story, a big story, if you will. That spawns a lot of points. So you would unlikely introduce an epic directly into the sprint that that is directly work on an epic in a sprint, you will first break it down into multiple stories. So that again, if you remember the invest concept of the story, one of the pieces of it is in the s in the invest is for small, so it should be able to fit within a sprint. So, an epic on the other hand, you can just think about it's a big story. In other words, a story that is going to take a lot of points, so you have to break it down in order to become a sizeable story.

So that's what an epic is epic can also be used at a at both program and project levels. Typically you may have you may come up with an idea as an epic at an epic level as part of the product backlog and then you will break it down in into smaller stories on a chance to perform stories. As a user stories on the other hand, again, the invest concept. That is the stories need to be independent, negotiable, valuable, estimable, small and testable despite being independent, they have no direct dependencies or with another requirement. So that's kind of just just a key. I've gone through the stories in a different lesson.

So you know, I don't want to spend too much time on stories here. But that's kind of, you know, a high level on the story is that this is the basic unit of requirement in Agile is a story. It needs to be independent, negotiable, valuable, estimable, small untestable. And then finally, test testable Basically the work packages, the actionable items that need to be done in order to complete the story. So once you have in the product backlog, you basically have the stories, when when you do, when you plan for the sprint, you take the stories that are going to be part of that sprint and create a sprint backlog. And for each of those stories, you create the different tasks that need to be done during that sprint in order to complete the story.

So that's kind of the difference between a theme, epic story and task again, at a high level team can span multiple projects or products. It is basically what is the strategic initiative that the company is having, as I gave you an example that basically maybe the company is trying to increase the web presence that would be the theme. And epic is nothing more than a bigger story. And something that has, that's going to take a lot of effort to Implement. So in order to before you start a sprint, you need to break that epic down into stories and then pick from those stories that which ones are going to be part of the sprint story. Again, it's it's a basic unit of requirement, it needs to be independent, negotiable, valuable as immutable, small and testable.

And then finally, tasks are the work packages, the work the different tasks that need to be done in order to accomplish the story. So that's those are the four different items, item levels, if you will, in the product backlog. The next state will give this slide basically gives a better understanding pictorially of how these different items are related. So you have the theme so for example, increase website traffic. Epic can be add new reduce sections, Right in order to increase the website traffic, also you can have improved login page usability. So those are the epic levels, if you will, again, these are really big, for example, improve login page with usability.

What does that mean? So you break it down into user stories. So your user story for this one, for example, would be as a user, I would like the validation on the login page to be very clear, so that I can easily see when if I make a mistake when I log in, so that's the user story. And then you have the different tasks that are associated associated with this user story. So that's kind of a pictorial representation of how a theme epic user story and task are related. Here's a just a sample example of a single line from a product backlog.

This is an Excel you can have the product backlog in an hour. online tools such as JIRA as well, we are going to go through JIRA in a different lesson. So you can understand that as well. But this is just kind of an example. So you can see that you know, the different items that can make it into the product backlog. So what you have here is the story ID, the sprint This is done in the, the first the planning sprint, you basically kind of try to assign or try to estimate or guesstimate what sprint number would this story falls in Moscow, which is a prioritization, you're saying that, you know, how important what is the priority of the story?

Island as I mentioned, that's just a way to categorize the stories. In this case, this story is related to the vendors. So that's why it's it's under an ID called vendor. You can have whatever Island you want, that makes sense for your project. The name of the story is the title of the story. description is the detail around this the story, any comments, test case ID what is the test is associated with the story, who's the owner of the story, how many points would it take to implement the story what the team has decided and when was the story created?

Now, this is not the only details that are associated with the story. Obviously, you need to have more idea about how the screen should be looking like and more details around that you can basically in Agile, you can have you know, some kind of informal way you can even have like, you know, some whiteboard screen pictures or something, if you have created the, you know, screen there, if you draw on the screen there, for example, or any other requirements, you know, you can have that associated with this story. separately in order to give enough information to the agile team in order to build this product so that's a high level that's about the product backlog. Hopefully it makes sense. The different items in the product backlog and the hierarchy of the different items you know, that the theme epics story and tasks people