Why Don’t We Pre-Write Stories for PI Planning?

This is a question I’m occasionally asked, but having been asked twice this week it prompted me to write this post.

Why not pre-write stories for PI Planning? Sure, it takes the stress and pressure out of the two days of PI planning; however, it is a SAFe anti-pattern. You may be wondering why.

Here are a few reasons:

Firstly, it’s double-dipping. PI Planning, as the name suggests, is for planning! If you break features down into stories, size the work, plan it into iterations, and write your PI Objectives prior to PI Planning, then you have already completed planning! So, instead of PI Planning, you will likely be catching up on Instagram/Facebook/The Economist (depending on how you like to spend your free time).

Secondly, PI Planning is supposed to be a collaborative workshop; it’s for collaborating! If you have already completed planning, what will happen when another team wants to talk to you about the details of your Feature, or the Product Manager points out that perhaps the Feature boundary lines aren’t quite right, or the Architect makes a clarification about the solution? Will you brush them off as you have already nutted out your plan? That’s not very collaborative! Or will you re-work the plan, potentially making all your pre-work waste?

Thirdly, consider what drives a team to pre-write stories before PI Planning. Often it is the need to get clarity on the details to increase the team’s confidence in their estimates and willingness to commit to PI Objectives. While the intent here is admirable, it can also be an indication that there are mismatched expectations in the organisation. PI Planning is not supposed to result in teams writing and committing to 12 weeks of small (1, 2, or 3 point) stories.

PI Planning is high-level, mid-range planning. I see this as akin to what Mike Cohn describes as Release Planning in Scrum. The goal of PI Planning is to understand what features fit in the PI, agree on the dependencies and flush out risks. At the end of PI Planning, teams commit to PI Objectives, which are summaries of their plan, not individual stories. This approach is deliberate as detail ages badly.

Finally, in pre-writing stories, what did you give up? Some cool innovation time? Your team might have invented the next Google Maps or Instagram. You might be on your way to being famous right now!

OK, you probably get the idea....

If being prepared for PI Planning is required for a successful planning event, what do you do instead? 

 At Pretty Agile, we have a practice we call “Discovery” or, in SAFe terms, it’s Analysis as a part of Continuous Exploration. We prefer the term Discovery as it tends to result in more collaboration and communication and fewer (if any) documents, which is what we typically see out of activities called “Analysis”.

What is Discovery? 

Discovery is a time box used by teams on the Agile Release Train to learn about, refine, and size Features likely to be prioritised for the next PI ahead of PI Planning. The team may break down the Feature into rough pieces of work in order to understand the work better, but this is not story writing. It is at a much higher level!

When do we do Discovery? 

It’s a continuous process that is planned and executed in every Iteration (at least on Pretty Agile trains!) and fed back into the cadence-based prioritization process (WSJF) in order for stakeholders to have a better conversation about potential future work. We recommend trains allocate approximately 10% of their capacity every iteration to Discovery. This should be included in the team's PI Plan.

How do we do Discovery?

The purpose is to discuss and align understanding of the Feature as a team as well as work towards completing a Feature definition and estimate. This will set the team up for success in PI Planning and will prove a better use of time than pre-writing stories.

These are the broad steps - 

1. Bring together the Agile Team (who has pulled the Feature for discovery), Product Management, System Architect and Subject Matter Experts (if required) for a conversation - ideally around a whiteboard or similar online collaboration tool.
2. Ask, “What do we know about the problem we’re trying to solve?” Product Management & System Architect(s) explain the feature & the business problem it aims to solve
3. The team asks clarifying questions & whiteboards the updated solution whiteboard drawing. Be sure to clarify and capture feature boundaries. 
4. Ask, “What do we not know and need to know?” Take down actions to resolve any outstanding big questions/concerns/architectural guidance
5. Estimate the work in story points. 
6. Complete the Feature definition template together.

Suggested time-box - 2 hours (plus follow up if required).

Do you want to know more? Check out Pretty Agile’s Staying Alive - Feature Disco Your Way to PI Planning on Vimeo or contact info@prettyagile.com to understand how we can guide you through this in your context.