Iteration execution in SAFe

The Program Increment (PI) loop can be seen as a PDCA learning cycle and is represented in SAFe by the following ART events and activities: 

Plan – The PI Planning event is the plan step of the cycle. 

Do – PI execution is the do 

Check – The System Demo is the check 

Adjust – The Inspect and Adapt (I&A) is the adjust

The PDCA cycle

We have seen how the PI Planning Event is running so we will now focus on the Do part, the Program Increment execution.

Iteration Execution 

Iterations are the basic building blocks of agile development.
Once the PI planning is complete, each team starts working on their own iterations and this follows the classic Agile principles we have already seen in the past. In fact, all ceremonies and artefacts at Team level are left to each Team’s decision and way of working.

Here are a couple of things to keep in mind when dealing with a scaled process.

Iteration Planning flow 

All begins with planning the iteration, an exercise very similar to a classical Sprint Planning in Scrum.

This meeting is by and for the team so other stakeholders are not required but they can be asked to attend if there is any clarification needed.
The Product Owner leads the Iteration Planning while the Scrum Master facilitates the meeting and ensure the PO doesn’t influence the team to overcommit and that time is allocated to address improvement items from past retrospectives and the technical debt.
Input is the Team Backlog and Objectives and the output are the committed goals and the committed backlogs which contains now detailed stories with estimations.

As everything, this meeting is also time-boxed (max half day).

Here is a typical schedule:

1. Establishing capacity 

The team quantifies the available capacity to perform work in the upcoming Iteration: each team member determines their availability, acknowledging time off and other potential duties. 

Then the team allocates the capacity to the Team Backlog: the PO in collaboration with the team selects the highest priority backlog items for each ‘slice’ of the capacity allocation to implement in an Iteration. 

All this should go very fast since it was already prepared in the PI planning.

2. Story analysis and estimating 

The Product Owner presents the Stories (a short description of a small piece of wished functionality that can be completed in one iteration) in order of priority and each Story:

  • is discussed and analysed by the team 
  • has its acceptance criteria defined and refined 
  • its estimation is revised

The process continues until the estimation of the Stories has reached the capacity of the team 

3. Detailing Stories 

Detailing Stories is mostly used by new teams. Here the team members discuss: 

  • who would be the best person to accomplish it 
  • how long would it take to accomplish, approximately 
  • what are the dependencies it may have to other Stories 

4. Developing Iteration goals 

Iteration goals provide clarity, commitment, and management information. 

They serve three purposes: 

  • align team members to a common purpose 
  • align Agile Teams to Pl Objectives and manage dependencies 
  • provide continuous management information 

5. Commit to the Iteration goals 

Remember that a team’s purpose is to do everything they said they would do in the Iteration; when this becomes not feasible, then they raise immediately the concern.

These team commitments are not only internally but also towards other teams, the program and the stakeholders.

This is always a critical part of the Iteration part and needs time to practice it: too much commitments or holding to them can lead to burnout, inflexibility and quality problems.
Too little commitments can lead to unpredictability and lack of focus. 

The Iteration progress 

Each team will progress their defined stories in the same way as we have seen for the single team.

Many scrum teams use Iteration burn-down charts which count the remaining effort (Stories, tasks, etc.) and we have seen them. As SAFe doesn’t advocate tasks (prefers to focus on Stories), it’s preferred to use burn-ups. In the burn-down charts is also hard to distinguish between work added and not done.

In addition, when there are multiple teams to be synchronised inside the same Iteration, SAFe advocates to organise other sync points: a mid-PI re-planning, a scrum of scrums, a PO sync.

Scrum of scrums and other sync events should be one of the first things to adopt when scaling.

Scrum of Scrums 

Agile Teams are synchronising through Scrum of Scrums (SoS) which is a cross-team meeting as a synch-point for dependencies and interactions. There is some differences over who attends and what the focus of the meeting is (team ward, leader-ward, status, synchronisation, etc.) but the idea is quite sound and necessary for multi-team efforts.

The Release Train Engineer (RTE, a SAFe-specific role) typically facilitates a weekly (or twice a week, better) Scrum of Scrums (SoS) event, acting as a Chief Scrum Master. 

The SoS helps coordinate the dependencies of the ARTs and provides visibility into progress and impediments. The RTE or Chief Scrum Master, mandatory representatives from each team (often the Team Scrum Master) and others (where appropriate) meet to review their progress toward milestones and PI objectives, and dependencies among the teams. 

The event is time-boxed for 30-60 minutes and is followed by a ‘meet after’ where individuals who want to do a deeper dive into specific problems can remain behind. 

A suggested agenda for the SoS event is:

  • what did your team accomplish since last meeting?
  • what will your team accomplish between now and next meeting?
  • are there any blocking issues?
  • are you about to put a block in someone else’s way? 

The RTE has the primary responsibility for communicating any major blocks, challenges or impediments to key stakeholders.

In SAFe Scrum of Scrums is therefore a meeting for Scrum Masters to gain visibility into team progress and program impediments.

Anti-patterns to avoid:
Team gets no input from scrum of scrums and the Scrum Master does all of the synchronisation, so the team is incapable of doing it themselves

PO Sync & the ART Sync

In a manner similar to the SoS, a PO sync is often held for Product Owners and Product Management. This event also typically occurs weekly, is also time-boxed (30 – 60 minutes) and is followed by a meet after. 

The PO sync may be facilitated by the RTE or better by a Product Manager. The purpose is to get visibility into how well the ART (the Agile Release Train, a SAFe term) is progressing toward meeting its PI objectives, to discuss problems or opportunities with Feature development, and to assess any scope adjustments. 

The event may also be used to prepare for the next PI (see below) and may include Program Backlog refinement and backlog prioritisation ahead of the next PI planning event.

Note: sometimes the SoS and PO sync are combined into one event, referred to as an ART sync

Collaboration with other teams

In general, the team should: 

  • Integrate their work often with other teams on the ART (at least multiple times per Iteration) 
  • Work with the System Team on automated system-level tests 
  • Join other teams’ daily stand-ups, demos, or planning when important issues arise 
  • Work with the System Architect to better manage dependencies with other teams 

The backlog refinement event

Finally,  another useful event is the Backlog Refinement, which is important also for single teams.

This is a weekly (or so) event and is as usual time-boxed (1-2 hours).

It provides time to identify dependencies and issues that could impact the next Iteration, helps the team to reconsider new Stories prior to Iteration planning and ensures that we have a ready backlog for Iteration Planning. 

Agile Team members are in attendance and actively engaged; subject matter experts and other teams’ members are invited as needed 

Sample Backlog Refinement Event Agenda 

  1. The PO presents the set of candidate Stories for the next Iteration
  2. The team discusses whether the set of candidate Stories should be reduced or increased ; Stories are added or removed
  3. The PO guides the team through the candidate stories one by one:
    • The team discusses each Story , estimates it, and splits it if necessary
    • The PO clarifies or supplements the acceptance criteria 
  4. Action items are summarized for all Stories that still require external input or action 

The goal is to maintain the right level of a deep backlog vs ready backlog for two Iterations but is also a chance to out as early as possible if the team thinks they will miss Iteration goals or Pl Objectives. Objectives can be changed mid-PI and – as far as it’s transparent – it’s actually the right thing to do.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s