The Product Backlog

Let's introduce our first artifact, the product backlog. The product backlog is nothing more than an ordered, prioritized list of all the things we might do for our product. The product owner owns the product backlog and it's their responsibility to maintain that prioritization. It's really a list of everything we might do. In fact, it's the only list. It's the single source of truth for all the work we might do. There's no other way hidden list out there. We don't work based on email or sort of, you know, text messages or phone calls. We like to say if it's in the backlog, we might do it. If it's not in the backlog, there's no chance we're going to work on it. Now, the product owner, they're keeping those things in order. And the things towards the top of the list have a lot more clarity than the things that are less priority and further down the list. Now, some key characteristics of the product owner as they manage that backlog include things like clearly expressed backlog items, ordering those items to best achieve our goals and mission, and ensuring the value of the work is understood in each of the items in the backlog. Also ensuring that the backlog itself is accessible, visible and clearly open and transparent for all to see. So what are some of the item types that might be in a backlog? Well, the most common is going to be user stories. Now, user stories are written in a format we're going to cover later, but they describe pieces of value that can be delivered within a sprint. Larger user stories that can't be delivered in a sprint typically are called epics, and those things get broken down in a backlog Refinement sessions throughout the sprint, where work gets refined and clarified until stories can be created, which are then committed to at the team level. But it's not just user stories and epics. It also contains all the warts and fingernails as well. Product owners own their product, and that may include things like defects. Defects, Defects. Or technical debt or architecture and infrastructure enablement type work. It may also include things like spikes. Spikes are time, box research, time, where we go in and figure out how to solve problems. Spikes need to be accounted for in the product backlog as well. So the backlog, it's the single list of all the things we might do. And again, the commitment that comes out of that backlog is what we call the product goal, the goal of our product that this backlog fulfills. So there you have it, the product backlog again, that prioritized list of all the things we might do for the product.