How to get your backlog ready for PI Planning

Backlog refinement at scale

In the beginning stages of a Scaled Agile Framework (SAFe) adoption, Big Room Planning meetings (also called PI Planning) often start with half-baked requirements. This lack of clarity results in:

  • Priority disagreements between Business Leaders and Product Managers
  • Refining features during the meeting
  • Features that are too large to be completed within a PI
  • Features prioritized or sized incorrectly
  • Being surprised by additional requirements or issues after the event

 

Avoid these problems by exposing Scrum Teams to features and stories before PI Planning. Everyone on an Agile Release Train (ART) deserves well thought out requirements so that they can efficiently estimate and commit to stories in the big room. The process I’ll detail below helps. It’s essentially an extension of Backlog Refinement – the idea that you spend a percentage of your current iteration looking at the next iteration. Or, if you prefer, Backlog Refinement at scale. Its benefits include:

  • Giving teams the time to ponder future work. Engineers love to chew on the what as they come up with the how. I always picture new requirements running minimized in their mind’s task bar. This thinking about requirements can lead to better solutions and more accurate sizing.
  • Enables requirement correction based on emergent questions. The earlier the conversation, the earlier any challenges are surfaced raised, and the more time you have to answer them.
  • Surfaces the need for more research. If you need a spike, you’ll know it sooner rather than later.
  • Clearly defining priorities. Thinking more about something helps us break down large needs into more granular requirements. Smaller features and stories provide the ART with more flexibility to take in only the highest priority items, improving the flow of value through the ART.

 

What does the process look like?

To prepare for PI Planning, the Product Management team should review, refine, and prioritize the program backlog in short, regular meetings. The meeting should involve at least one person representing the business – usually the Product Manager – along with a developer or tech lead, a tester, and an architect. Once this team confident that the feature will be included in the upcoming PI, they start a conversation with the teams. Scrum Teams then refine features and stories during their own meeting.

 

I recommend using a Kanban board to visualize your progress. If people aren’t collocated, I recommend using an asynchronous tool like CA Flowdock to capture and answer questions outside of the scope of the meetings.

 

How much time will we need?

My guidance is that it usually takes 8 weeks to prepare for a typical PI. The numbers look like this:

  • Most teams need an average of 2-4 hours to fully refine any given feature. Thus, if you’re aiming for ten features in the PI you’re looking at between 20 and 40 hours of work.
  • Meeting twice a week for 2 hours will get you to 32 hours over the course of 8 weeks.
  • Once you’ve started this cycle, you should be able to tell if you’re going to need to spend more or less time. For new programs, you’ll usually need closer to the 40 hours until everyone gets used to the process.

 

That’s a lot of time! Product Managers in particular are usually highly reluctant to add more meetings to their packed schedule. My advice for them is that it’s better to work out issues earlier rather than later (an ounce of prevention is worth a pound of cure). In addition, the first sessions are usually not very efficient, meaning that they’ll improve – and take less time – as you get better at it. Another issue is that many organizations have a low tolerance for this amount of grooming. But if you remain focused on the value of this refinement, many organizations come around.

The goal of any refinement is to gain clarity about the work to be done in the next iteration during the current iteration. And since performing short actions more frequently is much more efficient than doing long actions less frequently, explore this opportunity with your ARTs. If you can move most of the discussion about WHAT you want to work on outside of the planning meeting, you can focus the meeting on HOW you want to accomplish it: sanity checking the requirements with the larger cross-functional group, identifying risks and dependencies, and gaining that elusive alignment that makes everything so much easier.


Todd Meigs, an Agilist at heart, is a Principal Agile Coach on the Enterprise Agility…

Comments

rewrite

Insights from the app driven world
Subscribe Now >
RECOMMENDED
The Sociology of Software >How (Not) to Lie with Data Visualization >DevOps and Cloud Computing: Exploiting the Synergy for Business Advantage >