Recap: Understanding the Scaled Agile Framework (SAFe)

Welcome back to the second part of my blog series, exploring 'Real World SAFe'. This second part picks up from where Part 1 finished so if you haven’t read that yet I’d recommend doing so before reading on.

PI planning
So, we’ve completed our 4 Delivery sprints and we’ve got two days in our calendar for something called PI planning…and it’s offsite…and there’s names on the invite I don’t recognise?

At a team level, we review the features we are required to deliver and break these down into STORIES. This an opportunity to raise any concerns, NFR constraints or cross-team dependencies.

INVEST in a good story

• Write Stories that can be developed separately
• Write Stories in which scope can be negotiated
• Write Stories that are valuable to the Customer
• Write Stories that can be estimated
• Write Stories that can fit into a Sprint
• Write Stories that are testable

ENABLER items (If TEAM X is delivering a DB that TEAM Y is writing to and reading from – then the DB is an ENABLER and the team dependency should be staggered so if TEAM X’s DB is delivered in Sprint 2, TEAM Y cannot deliver until Sprint 3).

The planning event starts with an introduction by the RTE, then generally one or two senior stakeholders will present to the whole group. This means that everyone there understands the business value of what they have done and what they are planning to deliver. This is followed up by the Product Manager running through the prioritised feature list.

Then we get into breaking down features, we highlight dependencies on other teams or enablers (Infrastructure, Architecture, Exploration or Compliance). When a feature is broken down into stories and accepted by the team, the feature is placed on the Program Board which represents the whole PI and any dependencies are highlighted (with actual bits of red string). This gives us a chance to reassess the sequencing of story delivery to avoid dependencies.

These features then become our PI objectives (however, at Day 1 of planning, this is all a draft at this point).

We can also have ‘uncommitted’* objectives, so we may not commit to delivering one of these during the PI but we may deliver some research or a proof of concept in line with the objective.
*In versions of SAFe earlier than V5 these uncommitted objectives were called ‘Stretch’ objectives.

A typical PI Planning Agenda (Presented by the RTE at the start of both planning days)

DAY 1

DAY 2

*Risks are categorised into Resolved, Owned, Accepted or Mitigated

What to expect in Part 3

Watch this space for the last part of my series on SAFe. In the last blog, I’ll cover Inspect and Adapt, WIP Limits, CALMR DevOps, Measuring Flow and more.