<img alt="" src="https://secure.wauk1care.com/164394.png" style="display:none;">

A Real-World intro to SAFe – Part 2

Posted by Paul Raybould on 29/09/2020

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?

PI Planning is a chance for all teams to get together and review what we will be working on in the next increment. As part of the preparation for this event EPICS at a Portfolio level have been broken down into FEATURES which fulfil user requirements.

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)



*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.Digital Transformation & Quality Assurance

Topics: Agile,, Software Test Process, softwaretesting

nFocus Blog

Welcome to the nFocus software testing blog. As thought leaders and technical innovators, we created this blog to distil our thoughts, ideas and musings on improving software quality.

Fill out the form below to receive future communications from nFocus including our latest:

  • Blog articles
  • White Papers
  • and plenty more!

Follow us

Follow us on LinkedIn to see our latest content!

Subscribe Here!

Recent Posts

Posts by Topic

see all

Posts by Topic

see all