3

This question is about how a backlog can grow into a hairball and how to keep it manageable.

You've done PI planning, understanding the vision, planning the quarter, understanding capacity and dependencies and a view for what might be accomplished in the next quarter. So you've come out with a PI board containing high level story breakdown with estimates for the quarter and a view of prioritisation. So far so good.

Now you get back to your desk and you need to track the quarter. So you put all the high level stories into your team backlog with their high level estimates. The next sprint planning will break down the stories that are highest priority so you can start work.

Continuing to do this you use the high level estimates to track the roadmap items identified at the PI Planning and optimise your sprints using backlog refinement and sprint planning, etc.

As the quarter progresses the backlog gets bigger and bigger as you break down stories, re-prioritise, discover work, address bugs, welcome late changes, etc. As the backlog gets bigger and bigger it's gets harder and harder to see the wood for the trees and perform basic scrum practices such as backlog refinement and sprint planning because there are hundreds of stories across multiple features to sift through. You will also have story hierarchies and dependencies to deal with.

This is common in my experience and I would like to hear others experience and how they have dealt with this situation.

Improve this question

1 Answer 1

Reset to default
3

When you do PI Planning, you aren't planning at the Story level. PI Planning looks at the Program Backlog, which holds Features and Enablers. The Team Backlog has Stories along with Enablers.

Going into PI Planning, the intention is that Product Management and System Engineering are refining the items in the Program Backlog. Through this refinement, the Product Managers and System Engineers clearly define the Features and Enablers and work with the teams who are likely to do the work to ensure technical feasibility and find ways to split the work into smaller chunks (Stories and smaller Enablers). The split work may not be exactly what ends up on the Team Backlogs, but it is close. This act of decomposition can help the teams develop better estimates and plans for the PI.

Prior to PI Planning, Product Managers and System Engineers work with Product Owners to get more insights and refinement prior to involving all the Agile Teams in PI Planning. This usually happens in the two or so weeks leading up to the PI Planning events. This often aligns with the Innovation and Planning Iteration.

It's expected that, throughout the Program Increment, more work will emerge. By doing the work, the teams will find more things that they need to do or that work is more complex than initially thought but may also find that some work that they expected is not necessary or less complex.

You'll mitigate some of the problems if you spend more time just before and during PI Planning to put the more detailed work into the Team Backlogs, instead of putting the items directly from the Program Backlog into the Team Backlogs. Establishing traceability between the ongoing refinement at the Team Backlog level and the work in the Program Backlog selected for the Program Increment would help to support visibility.

The biggest issue is welcoming late changes, which is a principle of Agile Software Development. Developing a plan for a Program Increment of 8 to 12 weeks (2 to 3 months) with reasonable confidence is difficult if your environment is changing at a faster rate. Stable long-term plans and welcoming late changes, either in the form of newly discovered bugs or in changes to stakeholder needs, are at odds with each other. It's compounded by the fact that these bugs or more urgent needs may not align with the Features or Enablers selected for the Program Increment and the organization is forced to make a choice to welcome these changes or hold to the plan.

The long-term planning aspects of SAFe are one of the reasons why people say that it isn't an agile methodology. The long-term planning at the portfolio, solution, and program levels can hamper a team's ability to respond to changing requirements and new information that is learned by demonstrating or delivering working software. The best option to better handle change is to shift away from some of the SAFe structures that push planning down from the organization onto the teams.

Improve this answer
2
  • Thank you Thomas. Our first error is to put the high level stories from the PI Planning straight into the team backlog. Second error is not to do enough prep prior to the PI Planning. I can't really imagine how traceability between the program backlog items and the team backlog items would look. The question from senior management that we need to answer is , "Are we there yet?" Can you please elaborate on how that can be address in practice, considering their eye is on the program backlog while the work is being done in the team backlog?
    – Jack Leon
    Jul 11, 2022 at 16:59
  • 1
    @JackLeon How you implement the traceability depends on your tooling. I'm familiar with Jira, so I would do it by creating a Jira project to stand for the Program Backlog and one Jira project per product under the Program. If it's small enough, you could use a single Jira project for both backlogs with different issue types. Using the built-in issue links and automation functionality, you can transition the Program Backlog items through their workflow as linked issues transition through their workflows, keeping everything synchronized, and publishing notifications.
    – Thomas Owens ♦
    Jul 11, 2022 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.