Finding the Right Granularity for a Cross‑Project Backlog in Agile Delivery

We have been discussing whether to adopt the method "Planning through social activities – LEGO's scaled agile" (click "read original" if interested).

Currently, our delivery team allocation is still mainly based on project budget, which leads to a local priority mindset bounded by project boundaries, lacking a global view. Different business units compete disorderly for limited delivery team resources, resulting in a backlog of work‑in‑progress, busy people but unclear value.

We hope:

Organize a monthly "parliament" of business stakeholders to rank demands from different projects.

Based on delivery team capacity, limit work‑in‑progress and decide which demands to deliver this month, achieving globally value‑driven delivery.

However, to realize this idea, we first need to organize a Backlog for discussion and ranking. This seemingly easy task has stalled us.

The project types we face are:

Large projects with clear delivery deadlines.

Regulatory‑requirement projects.

Small projects for new client onboarding and business‑process optimization.

Operations and maintenance of existing systems.

These project demands come from various business units. Overall, based on project importance and budget, most of our staff are allocated to large projects. When we ask about priority, we are told large projects have the highest priority, but this does not solve the problem because regulatory demands, new client onboarding, and process‑optimization small projects also compete for limited resources, causing chaotic staff allocation. In short, prioritizing by project granularity is meaningless unless low‑priority projects are dropped, which won't happen. Without a cross‑project global view, many staff work on deliveries that are not the highest value globally, leading to huge resource waste.

Thus we want the backlog used for ranking to be at the user‑story granularity. But pulling existing user stories from JIRA leaves us stunned. We have thousands of user stories from different projects in the Backlog, which is meaningless to business stakeholders and impossible to rank.

Therefore we need something of appropriate granularity between user stories and projects, understandable to business, clearly indicating global significance, allowing stakeholders to instantly see if it should be done this month, and executable for the delivery team. I considered Epic, but its granularity is still too large, containing both mandatory and value‑added stories, and would require uniform Epic granularity across teams, which is difficult.

Currently, this remains an unanswered question; I welcome suggestions in the comments.

About the author

Works at a Fortune 500 bank, responsible for fund‑service business software development and delivery.

Agile, Lean, DevOps expert.

Proficient in XP, Scrum, Kanban, TDD, CI, BDD, DevOps toolchain.

Speaker at GDevOps, DevOpsDays Meetup, China Software Technology Conference.

Author of "Cheetah Operation: Agile Transformation Journey in the Smoke of War".

Microsoft DevOps Technology Community is continuously recruiting.

Our DevOps community is still recruiting; interested friends can scan the QR code below to add the "DevOps Community Operations Assistant" and apply to join the group.