Enterprise-level Product Backlog Organization

A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives. Scaling small, single team projects to large, complex, enterprise-level initiatives is a relatively new area. It also requires a different approach to structure an enterprise-level product backlog.

Product Backlog Planning

Product Backlog organization can be very different on large, enterprise-level projects.  On small single-team Agile projects, the predominant thinking seems to be that

  • You only need to plan the backlog a few sprints in advance
  • You just prioritize the stories in the backlog, and
  • Then pull them off as needed to start a sprint. 

That method starts to break down as you scale projects to large, complex enterprise levels.  There are a number of problems I’ve seen with that approach:

The Importance of Planning

If you don’t plan the backlog further in advance, it’s difficult to assess the overall scope of the project and determine the resources required for the project. For example,

  • I’ve seen a project that just started development with a small, single Agile development team and
  • After two years of development still had no end-in-sight of when the project would be completed 

When we re-planned the entire backlog at a high level, the company management was very surprised to find that the project was going to take more than two years to complete with the current level of resources.

Large Product Backlogs

When you have a large product backlog with hundreds or perhaps even over 1,000 stories, understanding the inter-relationship of the stories becomes important.  When you make priority changes among stories in the Product Backlog, it often doesn’t make sense to do it the level of individual stories:

  • If one story up in the Product Backlog is moved, what about the other stories that are inter-related with it? 
  • Wouldn’t you want to move all of those stories together as a group? 
  • Organizing the Product Backlog into epics and perhaps themes provides a way to make priority decisions at a higher level that is more appropriate for enterprise-level projects
  • At that level, priority decisions are often more based on a higher-level of epics and themes rather than at the level of individual stories within an epic or theme

Architecture

Another major problem area is architecture.

  • If you take a piecemeal approach to doing individual stories without planning and considering the entire solution,
  • It can lead to poor architectural decisions and possibly significant rework later on

Multiple Teams

Finally, it becomes even more essential to organize the work to be done with multiple-team projects. Properly segmenting the work among multiple teams is essential to avoid requiring excessive amounts of coordination overhead among the teams.

Higher-level Decision-Making

I recently wrote an article on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies. Those levels (such as Program Management and Product/Project Portfolio Management) need to be integrated.  In a large company,

  • Organizing the Product Backlog is essential to support effective decision-making at those higher levels of management and
  • That is often critical to ensure that all of the projects in an organization are well-aligned with the company’s overall business strategy.

Overall Summary

There are many things that need to be done differently on large, enterprise-level projects. Product Backlog organization can be one of them.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Leave a Reply

Your email address will not be published. Required fields are marked *