SAFe® Scrum Team Events

Due to the extensive content available from SAFe® regarding Scrum on how to execute and facilitate the events, in this section, we will share our key takeaways, experience, and tips, rather than how to execute or facilitate each event.

We encourage and recommend you visit SAFe® Studio (formerly known as the community pages) and download the following Facilitator Guides from SAFe® Studio Toolkits:

• Facilitator’s Guide to SAFe® – Iteration Planning
• Facilitator’s Guide to SAFe® – Team Sync
• Facilitator’s Guide to SAFe® – Backlog Refinement
• Facilitator’s Guide to SAFe® – Iteration Review
• Facilitator’s Guide to SAFe® – Iteration Retrospectives

Iteration Planning

The first event in an iteration is Iteration Planning, which is facilitated by the Scrum Master/Team Coach (SM/TC). During this event, team members refine stories already defined in PI Planning to meet the Definition of Ready. The maximum timebox for this event is typically four hours for a two-week iteration, but it is rarely needed. There is a law of diminishing returns, and spending more time beyond a certain point does not increase accuracy. All team members, including the Product Owner (PO), are present during Iteration Planning.

Backlog preparation

It is important to ensure that the PO attends this event with a well-prepared Team backlog, which should include any work carrying over from the previous iteration. The PO has the decision-making power, from a prioritization perspective, to exclude carry-over work from the next iteration. However, there are tradeoffs that should be considered, such as the criticality of the work, sequencing, dependencies, and the cost of task switching.

Capacity

Too often, we see teams spend upward of 30 minutes figuring out their capacity for the iteration, trying to calculate for an hour here and there or being unsure of their schedule. This activity should take no longer than 5 minutes. Coach the team that they are responsible for knowing what their schedules will be for the next two weeks. You may want to consider not adjusting capacity for anything less than 4 hours as the impact to the Capacity will be negligible.

Story Selection, Analysis, and Estimation

Backlog preparation ensures this activity goes smoothly. Time spent on Backlog Refinement is regained in Planning. Since we have a prepared Team Backlog, simply start at the top of the backlog, review the story, get any additional clarification, verify the points are still accurate and, with the team’s consensus that they can complete this in the next iteration, move the story into the Iteration Backlog.

Repeat this process, ensuring you don’t exceed the agreed capacity, and that, as you approach that capacity, the team agrees they can complete all the work that is currently in the Iteration Backlog. This also means that all stories will meet the Definition of Done (DoD).

It is often helpful to have the DoD readily available for the team. If you have a team room, keep it posted; if it’s virtual, ensure that all team members know where it is and can access it regularly.

It’s important to call out that the team does not have to plan to capacity. For example, if the team capacity is 25 points and the team reaches an agreement at 23 points that this is the most work they can commit to, there is no obligation to find a couple of 1-point stories or a 2-point story from farther down the backlog for the team to complete.

Additionally, the team could also decide that while their capacity is 25, they want to attempt to do 26 points this iteration based on the stories they have selected. The consensus of the team and their commitment and agreement are more important than meeting or exceeding the estimated capacity.

Tasking

Not all teams create tasks for their stories. However, we find this practice helps many teams initially as they start to mature. It helps the team to understand the work required to deliver the story. Encourage the teams to think beyond tasks of develop, test, and deploy. Tasks don’t have to be overly detailed; they could be something as simple as “Write API to retrieve XYZ data.” Encourage the teams to keep the descriptions short.

There is a balance with tasking, with a general rule of thumb being a task should be able to be completed in 4 hours or less. The balance is that we want to prevent all of our tasks taking 15 minutes.

Use tasks to identify important steps that we don’t want to miss. Some teams will create tasks for key items in the DoD.

Ultimately, the value of tasking creates a shared understanding of the work among the team members as everyone can see what work needs to be done and how it fits into the overall story. Additionally, tasking may bring to light something that was overlooked, allowing the team to adjust their Iteration Plans before commitment.

Iteration Goals

Iteration Goals are often overlooked by many teams; however, they play an important part as this helps to keep the team focused.

Pro tip

A practice you might consider is that your Iteration Goals are “tweets” with hashtags and social media lingo. We then use those tweets to communicate to the other teams what is being worked on. Here’s an example:

Enhance the login process by implementing MFA via text. #Login #MFA #TeamAvengers

You can even create standard hashtags to allow you to quickly search your communication tools (Slack, Teams, etc.) for them. One organization created hashtags for each of its Features. Be creative!

Commitment

This is the exit criteria for Iteration Planning. There are numerous ways to get the commitment, including Fist of Five, verbal agreement, or a simple yes/no vote. Regardless of how you do it, be sure that everyone participates, and their concerns are heard.

Team Sync

The Team Sync (formerly the Daily Stand-up or DSU) is a 15-minute meeting with a Meet After to resolve or discuss any items. It is important that everyone in the team participates and that it does not become a status meeting.

The Team Sync is important for the team to stay aligned with the work that is occurring to deliver the stories they committed to in the iteration.

Pro tip

As a Scrum Master/Team Coach, you want to make sure everyone gets a chance to speak and actively participate in the event. A simple technique to pass around a speaking token (e.g., a ball or a baton); when the token is passed (or thrown) to you, it is your turn to provide an update.

Encourage the team to actively talk to and even move the tasks or stories they have been working on to the appropriate column on the board during the Sync. Track and ensure items aren’t stuck in a state for too long (more than a day). Some teams even discuss when they expect to have a particular item done and capture that in the tool as well.

The Meet After is a timebox that allows for the team to further discuss any issues or topics that came up during the Team Sync. Ensure that Meet After items are captured and visible so team members can quickly determine whether they need to participate.

Backlog Refinement

Backlog Refinement is the opportunity for the team to identify and address potential obstacles and dependencies, estimate the stories, and provide input into the sequence and importance of the stories.

Pro tip

The biggest mistake I see teams make is not dedicating enough time to Backlog Refinement. Too often, the first practice I put into place with teams (and ARTs) is mandatory Backlog Refinement of 2 hours per week. I recognize that may seem a bit extreme; however, what teams quickly discover is the time spent on refinement leads to reduced time spent on planning, improved predictability, and overall improvement in morale.

We encourage a rolling-wave approach to Backlog Refinement, where we track stories that have already been refined and do a quick check for any adjustments to those stories before working down the Team Backlog to stories that need additional information and conversations.

Be sure to capture relevant information from the conversations during Backlog Refinement with the stories, including any drawings, diagrams, and so on.

With the rolling-wave approach, teams should eventually be able to get their backlogs to have a PI plus 1 Iteration worth of work at decreasing levels of readiness. Here is an example you may want to consider, noting there are no hard guidelines and that it will take the teams some time (usually at least a PI) to get anywhere near these recommendations:

Next Iteration	95%+ Stories meet Definition of Ready
2 Iterations out	85% of Stories meet Definition of Ready
3 Iterations out	50% of Stories meet Definition of Ready
4 Iterations out	25% of Stories meet Definition of Ready
5 Iterations out	Stories have descriptions and most Acceptance Criteria are defined
6 Iterations out	Stories identified, some description, and Acceptance Criteria

Iteration Review

The Iteration Review, sometimes called the Iteration Demo, is important for the team to be able to present their work to key Stakeholders, and also to assess their progress toward their PI Objectives. Too often, that assessment by the team is missed or skipped.

We have experienced numerous Iteration Reviews, both good and bad. We recommend one of two patterns when looking at all the stories the team completed. Either review each story on a story-by-story basis in backlog order or, if there is a natural sequence to show the stories, you could follow that model. A pattern we recommend staying away from is person-by-person. This is a common format when we have individuals rather than the team working on a story.

Remember that the Iteration Review is the opportunity to review ALL the stories the team worked on, not just those that are finished. Ensure that the team takes the opportunity to discuss and show the work that was completed on stories that aren’t done as well. Outlining what work remains helps the team continuously improve and can serve as input into the Iteration Retrospective.

Lastly, this event is also an opportunity to discuss the Team Backlog and adjust based on feedback from the Stakeholders and the team. Ensure that the Product Owner and team capture any adjustments for inputs into Iteration Planning or Backlog Refinement.

Iteration Retrospective

The Iteration Retrospective is the capstone to the iteration. It reinforces the SAFe® Core Value of Relentless Improvement.

Ensure that the team understands the importance of the retrospective and that it doesn’t become stale. Change up the retrospectives the teams participate in. The book Agile Retrospectives: Making Good Teams Great [9] is a great resource for ensuring effective retrospectives.

Ensure that the improvement items the team identifies are captured; many teams or ARTs will use an Improvement Backlog or capture it as an Improvement Story.

At the beginning of each retrospective, review the improvement items from the last retrospective to determine their efficacy and if the team wants to continue or stop them.

Iteration System Demos

We cover the Iteration System Demos in detail in Part 2; however, we wanted to call out that the teams attend and may participate in them. Ensure that the teams have this event on their calendars and attend. It’s a key event for measuring progress and maintaining alignment across the ART.