In this video, we will discuss what is the product backlog? Who creates the Product Backlog? When should we create a Product Backlog?
And how to conduct an initial Product Backlog creation exercise. Hey Friends! Welcome back to the channel.
If you're new here, my name is Vibhor. I am an Executive Agile and Leadership Coach based in Toronto, Canada. And this is the fifth video in an ongoing series where I'm trying to simplify the process of planning an Agile product, starting with the product vision, followed by product roadmap, release plan, finally learning how to create product backlogs full of effective bite-sized user stories.
So if you're a Scrum Master or an Agile Coach consider subscribing to learn some actionable and super effective ways to be Agile. There are timestamps available, so feel free to skip around the video if you feel like it. For now, let's get started.
So what is a product backlog? At the most basic level a product backlog is a list of everything that needs to be done as part of the product. For a new product, it is a list of all the features, functional requirements and non-functional system requirements.
For existing products, the list may also include enhancement requests, bug fixes, infrastructure changes, or other activities that the team may deliver as part of the changes to be made to the product in future releases. Something to keep in mind is that a product backlog is a single source of things that the development team works upon. It is a repository that feeds a product's evolution.
That means if it isn't on the product backlog, it isn't getting done. This brings us to the next question. Who all participate in the initial product backlog creation exercise?
And the simple answer is Business & IT. To elaborate, from the business side we usually have the product owner or the product manager and all key business stakeholders who have a vested interest and can either affect or be affected by the product's operations and future performance. From the IT side, we have the members of the development team.
Development team provides the technical insights in terms of what is required to create the features and functionality wished for by business stakeholders. In a small team, we usually invite everyone. The Programmers, the QAs the BAs and everyone else.
In case of big initiatives involving multiple agile teams, we invite key representatives who could provide technical input on behalf of the teams. We also invite experts like Architects and UX Experts, to help set guidelines in terms of key elements of the software solution. In a nutshell, everyone that can contribute towards achieving the final vision will be part of this session.
A mistake that I have seen a lot of organizations make is that they don't involve scrum masters or agile coaches in this exercise. The initial product backlog creation or requirements gathering, as some people call it, is crucial to set strong foundation for a robust product in the coming future. Product backlog creation not only involves getting all the right requirements and features, but prioritizing them in a way that satisfy the business needs, while keeping the cost as low as possible.
Agile coaches and scrum masters are expert facilitators who can help achieve this objective using various facilitation and prioritization techniques. So if you have them, the recommendation is to use them. Next.
When do we conduct this exercise? Now, there is not a lot of prescription on when to do it, but ideally we conduct this exercise during product planning, after creating a rough product roadmap and as the first step of the release planning process. One thing to keep in mind is that this exercise is not the same as refinement sessions.
Product backlog is evolutionary in nature, and we evolve it using regular refinements sessions that we conduct in the middle of the ongoing Sprints. More on that later. Okay.
Now that we know what a product backlog is when to create it and who creates it, let's see, how can we start creating one? Let's imagine, you have everyone you need to create an initial backlog in the room. You have the product owner the business stakeholders, along with the members of the development team, waiting for your instructions about what to do next.
If this group of business & IT professionals is new to agile ways of working, you start by giving a brief overview of what is a product backlog. Followed by a quick walk through of the strategy highlighted in the product roadmap. I've already covered how to create product roadmap in earlier videos.
If you haven't already, I recommend that you check them out. Link to the playlist is in this corner or in the description. If you're watching this on YouTube.
Back to creating the product backlog. Starting with the initial list of the high level features that we captured in the product roadmap, we invite everyone to brainstorm additional features, functions, and requirements that need to be part of this product. And although not necessary, a typical Agile team, describes each of these items in a user story format.
Which as shown on the screen is a short template divided into three simple sections. The first section describes the WHO. Second describes the WHAT.
And the third describes the WHY. I recommend using this template from the get-go to avoid team falling into the trap of habitually, writing the one-liners. An examples user story could be, "As a website user, I want to retrieve my forgotten password, so that I can log back into the application.
I will cover writing effective user stories with detailed lessons on how to Write, Split and Estimate them in future videos. So if you haven't already please consider subscribing. The purpose of the product backlog creation exercise is to generate as many user stories as we can.
Some user stories will be too big, some too small. It doesn't matter at this point. We just want to list to the best of our knowledge, EVERYTHING we need to build the product.
Emphasis on "EVERYTHING". As we don't just want to collect functional requirements and features. We also, as part of this exercise, want to collect non-functional requirements, which usually address such aspects of the product like usability, reliability, portability, security, scalability, and performance, which essentially are the key differentiators of the product.
Also, as we go through this exercise of creating a list of initial user stories, we may come across a situation where the development team is unable to provide a definite solution. In such cases, the development team is required to conduct some time-boxed technical investigations, to determine how some unknown things could be done. These research stories, are called SPIKES, and these can easily be captured with the template that goes like this, "In order to [achieve some goal], [a system or user] needs to do some action.
For example, "In order to split the user story "X", the tech leads needs to do some detailed design. Enough to split the story. Do not worry about detailing the product backlog items just yet.
It is important to understand that at this point, we can keep the items big and capture them at a high level or at the level of an Epic. Which is nothing but a large user story or a collection of multiple user stories. This is because we don't want to populate our initial backlog with thousands of small items that are difficult for us to work upon and difficult to identify the key elements that we want to consider for future releases.
In the next video, we will learn how to order and prioritize our initial product backlog items that we just created, to ensure that the development team works on the most important items moving forward. So there you have it. If you liked this video, then give it a thumbs up subscribe and don't forget to provide your valuable feedback in the comments.
I'll see you in the next video.
