Welcome back to the second part in 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.
So, we’ve completed our 4 Delivery sprints and we’ve got 2 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 re-assess 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 in my series on SAFe. In the last blog I’ll cover Inspect and Adapt, WIP Limits, CALMR DevOps, Measuring Flow and more.