A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives and there is a limited amount of information on what needs to be done to scale small, single team projects to large, complex enterprise-level initiatives and how to structure an enterprise-level product backlog.
One of those areas that often needs to be done differently on large, complex, enterprise-level projects is Product Backlog organization. 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:
- Without planning 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. It was a major surprise when we stepped back and re-planned the entire backlog at a high level to find that the project was going to take almost another two years to complete with the current level of resources.
- 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 you move one story up in the Product Backlog, 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 even 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.
- 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.
- Finally, when a project grows to the point that multiple teams are involved, it becomes even more essential to organize the work to be done in a way that it can be segmented among multiple teams without requiring excessive amounts of coordination overhead among the teams.
In another article I recently wrote on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies that need to be integrated such as Program Management and Product/Project Portfolio Management. In a large company, organizing the Product Backlog into a hierarchical structure can be essential to support effective decision-making at those higher levels of management above the level of a single Agile team 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.