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

Get in Touch

Claire Sanders and Em Campbell-Pretty March 24, 2021

Category:

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 the 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 GoogleMaps 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 so 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 ART 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 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 teams PI Plan.

Illustration of how we get from epics, to features, to stories in SAFe

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 -

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.
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
The team asks clarifying questions & whiteboards the updated solution whiteboard drawing. Be sure to clarify and capture feature boundaries.
Ask “What do we not know and need to know?” Take actions to resolve any outstanding big questions/concerns/architectural guidance
Estimate the work in story points
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.

Tags: Discovery, Feature Defintion, SAFe, Scaled Agile Framework

< How Planview Supports SAFe