Backlog

I use the term backlog to mean a prioritized list of work items for a product. First, I often use it as a short form for product backlog. Second, I distinguish the sprint backlog as the subset I plan to finish in the current sprint. For example, I keep user stories, technical tasks, and administrative tasks in the product backlog, and I list them in the order of processing. Therefore, the top items reflect the most important work, and the ordering stays clear even when scope grows.

I prefer one logical backlog across teams. However, I create team views when needed. For instance, I define team filters on a common product backlog. Alternatively, I create virtual team views. In both cases, all items together form one logical backlog. In scaling frameworks such as Nexus, SAFe, and LeSS, I follow the same idea; in SAFe, I link different lists by scale so each level contains items at the right level of detail, and teams refine program-level work into team-level work.; and in addition, teams may add items that arise from local context, while I keep shared goals visible for everyone.

I split complex requirements when I must. For example, I split a hardware-interface requirement into two items. Then, Team A manages the hardware interface in its backlog. Meanwhile, Team B manages the app connection in its own list. Thus, teams can work independently. At the same time, I keep the logical backlog consistent across teams.

I prioritize backlog items based on value and risk. Therefore, I expect the product owner to set order. Then, developers provide estimates. Because of that, I base planning on both order and effort. I recommend clear prioritization for the next two to three sprints. Moreover, I avoid vague priorities far down the backlog. Consequently, teams know what to pull next, and stakeholders understand what will happen soon.

I use standard practices for good items. For example, I apply the INVEST criteria. In short, I make items independent, negotiable, valuable, estimable, small, and testable. Then, I break down high-priority items into detailed descriptions. Also, I keep lower-priority items more vague. Thus, I maintain a continuous backlog.

I use tools to visualize and measure progress. For instance, I use a task board to show the sprint backlog. The board moves tasks from To Do to In Process to To Verify and Done. In addition, I use a burndown chart to track remaining effort, and I update this chart daily. Consequently, I see whether the team meets the sprint goal.

I support self-organizing teams and collaborative decision-making. Therefore, I structure teams to reduce dependencies. As a result, teams decide independently about implementation details. In this way, teams respond faster to stakeholder feedback. Moreover, teams deliver end-to-end features.

I estimate items with the development team. Then, I refine estimates and acceptance tests during conversations. Finally, I use the card-and-conversation approach. Thus, when I demonstrate acceptance tests at the end of an iteration, I confirm that the team delivers what I need.