A functional backlog supports the PO’s vision and allows the team to bring that vision to life.
By BreakFree Solutions
To be productive, you need to understand your priorities clearly. This is especially true for those working in IT, where fast, efficient production is crucial for success.
BreakFree delivery team members prioritize by creating optimized backlogs. A backlog is a prioritized list of "backlog items" that the team plans to complete on their way to achieving an objective. “Plans” here is the optimal word. A good scrum team knows that adapting to change and dealing with “what is” is more important than sticking to a well-laid plan.
If teams don't prioritize backlog items, they can quickly become overwhelming. When clients struggle to meet their goals on time, and their delivery team feels lost around what task to tackle and when we look to the backlog to see how it can be optimized. Here’s an overview of how Product Backlogs are built with functionality in mind for those wondering how they can make their backlogs more effective.
Creating the Backlog
Like all things, it starts with an idea. The Product Owner (PO) has an idea for a product. They discuss it with stakeholders (those who will be impacted by the creation of this project) to determine the validity of the project and solidify their vision. They set out to make a Product Backlog to properly share their vision with others—especially their development team, to discuss how they will turn the vision into reality.
The PO owns the Product Backlog, meaning they come up with the Product Backlog Items (PBIs) and decide how those items should be prioritized. To come up with the items and priority, the PO discusses the product with stakeholders. They also continuously consider value added, as in “What value does this backlog item add to the product we’re developing?”
The development team shares feedback with the PO to ensure the items are as refined or “sprint ready” as possible. That way, they can be seamlessly moved from the Product Backlog to the Sprint Backlog when it’s time for the team to tackle those items.
For each backlog item, as they move closer to the top of the list, the PO will need to work with the team during Backlog Refinement and Sprint Planning to break up the work into many smaller backlog items, fill in the details, and estimate the effort.
Getting to Work
Once the PO has the Product Backlog prioritized and the items on the top of the Product Backlog are refined and Sprint ready, the scrum team can take items from the top of the Product Backlog into their Sprint Backlog.
Think of the Sprint Backlog as an extension of the Product Backlog. To create this backlog, the PO and their team decide which high-priority PBIs can be completed by the team in a time-bound fashion.
Once the PO moves the item from the Product Backlog to the Sprint Backlog, the team commits to finishing that work in the time of the next Sprint (typically two weeks). This is also when the scrum team begins to point or size the items (or stories). Check out our blog post here if you’re interested in reading more about the story-pointing process.
If circumstances change and the team cannot complete an item, then the item gets moved over to the next Sprint Backlog. Understanding what needs to be done to complete the item, the team’s bandwidth, how refined the backlog item is, and more factors impact whether the team will complete the item in that Sprint.
Best Practices for Healthy Backlogs
A functional Product Backlog reflects the POs vision and adapts well to changing circumstances. Here are methods we recommend for making your backlog the most functional:
Have unique acceptance criteria for each backlog item and put it right there in the backlog item. The item should include information on what the item is, including what it will take for this item to begin the process of being marked as Done.
Have an agreed-upon Definition of Done. On a team level, all items in the Product Backlog must meet the same criteria to be marked officially as Done. For example, some teams require items to be peer-reviewed or documented before being marked Done.
When new work comes in, add it to the product backlog as soon as possible, being sure to communicate with your PO or team. You don't need the details yet. Create a new item and give it a name; worry about the details later.
If you’re working on something, add it to the backlog. It can be thought of as if it never happened if it's not in the backlog.
As a team, you determine if the sprint backlog and goals represent a reasonable forecast based on previous metrics and their current understanding of the relative amount of work.
Still looking for help creating your best backlog? We're here to help!
Comments