5

Team Iteration Events

Regardless of the type of team you have, the events that your team holds on a regular and synchronized cadence can’t be overlooked. Without these checkpoints, the teams will struggle to effectively and efficiently deliver and will struggle to reach high performance.

In this chapter, we will look at each of the team events, including the following:

• Iteration Planning
• Team Sync
• Backlog Refinement
• Iteration Reviews
• Iteration Retrospectives
• Iteration System Demos

This chapter isn’t just for teams executing as a SAFe® Scrum team. We will also look at SAFe® Kanban Team events:

• Planning
• Delivery
• Team Sync
• Iteration System Demos
• Retrospectives

We will also take a look at key artifacts that will help ensure team success:

• Definition of Done
• Definition of Ready
• Working Agreements

Let’s jump in and get our teams started with Iteration Planning.

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.

SAFe® Kanban Team Events

Kanban, a concept that originated in Japan, has become a widely used production planning framework across industries worldwide. In the early 1940s, Toyota, a Japanese automotive company, introduced Kanban as a means of improving inventory management, reducing waste, and optimizing workflow. The word “Kanban” translates to “visual signal” or “card,” referring to the visual cues used to manage production and inventory. Its principles involve creating a balance between supply and demand, reducing overproduction, and Continuous Improvement. Since its inception, Kanban has evolved beyond its original usage in manufacturing sectors and has been adapted to various fields, including software development, healthcare, and education. Its simplicity and effectiveness have made it an essential tool for many organizations seeking to streamline their work processes.

SAFe® is a flow-based system, and we use Kanban extensively across all levels to visualize our work. In Figure 5.1 is an example Kanban Board for a team. On the far left, we have the funnel where we capture all our ideas. Each column reflects the steps that we go through to finish an item in our backlog.

Above each column are numbers representing the Work-In-Progress (WIP) Limits. As the name suggests, this creates a pull-based system by restricting the items in each column. In doing so, we are encouraged to stop starting and start finishing.

In Figure 5.1, we can see that Integration and testing has a WIP Limit of 6, and there are 6 stories already in that column. Enforcing a WIP Limit means that we are unable to move a story from Building until we’ve created room for it. Without a WIP Limit, our developer would probably just pull another story and increase the amount of unfinished work in the system, which we see as operational debt. However, in this case, we would encourage developers to help out with the Integration and testing, thereby moving stories closer to completion.

Figure 5.1 – An example team Kanban system (© Scaled Agile Inc.)

Pro tip

For the most part, Figure 5.1 will be a good starting point. However, you will need to customize the board to reflect the steps in your processes. When I implement Kanban in some organizations, I find that leaders, or sometimes PMOs, have mandated that everyone use the same states on their boards to make reporting easier.

You will need to think about how to integrate with the Features on the ART Kanban, but make sure that it represents the work in a way that is meaningful to the team.

Planning

Planning for SAFe® Kanban Teams differs slightly from SAFe® Scrum Teams as they focus on continuous flow. Often, Kanban Teams use this approach because they struggle to plan two weeks in advance. To this end, Kanban Teams often meet once a week or as needed to plan for the week ahead and address dependencies and bottlenecks.

Although we want teams to have autonomy, they are not entirely autonomous. Therefore, it is essential that Kanban Teams share their planned work visibly. They usually display their work on a Kanban board, either physically or digitally.

As part of the ART, they also share their progress toward their PI Objectives by publishing their Iteration Goals and progress on dependencies so that they are aligned with the rest of the ART.

Team Sync

Like most Agile Teams, Kanban Teams get together regularly to ensure their work is on track. Teams often meet daily like a Scrum Team, although the Team Sync for a Kanban team is more akin to an Iteration Review. There is always a trade-off between encouraging collaboration and disrupting time in the zone.

Teams usually synchronize their syncs with the rest of the Train. It is common to start and end Iterations mid-week. Post-Pandemic, people are in the office more from Tuesday to Thursday and are more productive when face-to-face.

The Team Sync covers a lot of the same topics we would typically talk about during a Iteration Review:

1. Flow Metrics and Blockers
2. Review and Accept Stories
3. Upcoming Dependencies
4. Progress toward Iteration Goals and PI Objectives

Pro tip

I often see Team Syncs going on for far too long. I once Coached a team that struggled to keep their syncs below an hour! Make sure you keep your updates to the point and focus on what the other team members need to know. Come prepared and let people go as soon as possible.

Retrospective

Kanban Teams also prioritize retrospectives to ensure Continuous Improvement over time. During these retrospectives, team members reflect on their recent work and identify ways to improve their processes, collaboration, and outcomes.

Here are some key elements that contribute to a good retrospective (note these apply to Scrum Teams as well):

• Psychological Safety: The retrospective should foster an environment where team members feel safe to express their opinions, share their experiences, and raise concerns without fear of judgment or reprisal. This encourages open and honest communication.
• Focus on Learning: A good retrospective emphasizes learning from past experiences. It encourages the team to analyze both successes and failures, identifying what worked well and what could have been done better. The focus should be on Continuous Improvement rather than blaming individuals.
• Clear Objectives: Define clear goals and objectives for the retrospective. It could be to identify areas of improvement, celebrate successes, address specific challenges, or enhance team dynamics. Having a clear purpose keeps the discussion focused and ensures meaningful outcomes.
• Structured Format: Utilize a structured format or technique to guide the retrospective. There are various frameworks available, such as the Start, Stop, Continue method, the Mad, Sad, Glad technique, or the 5 Whys approach. A structured format provides a framework for discussion and helps prevent the conversation from becoming unfocused.
• Inclusive Participation: Ensure that all team members actively participate and have a chance to contribute. Encourage even the quieter or more introverted individuals to share their thoughts and ideas. This inclusivity promotes a sense of ownership and collaboration within the team.
• Actionable Insights: The retrospective should result in actionable insights and concrete steps for improvement. Encourage the team to generate practical ideas and create a plan of action to implement changes. Assign responsibilities and set deadlines for follow-up actions.
• Follow-Up and Accountability: Ensure that the actions identified in the retrospective are tracked and followed up on. Hold team members accountable for their commitments and provide support or resources as needed. Regularly revisit the retrospective outcomes to assess progress and make further adjustments.
• Continuous Improvement: A good retrospective is not a one-time event but part of an ongoing process. Encourage the team to reflect regularly, ideally after every significant milestone or iteration. Emphasize the importance of Continuous Improvement and foster a culture of learning and adaptation within the team.

Pro tip

One of the best retrospectives I ever participated in was with a small team working on a top-secret project in an innovation lab. We were under tremendous pressure from senior leaders to prove the value of a proposition, so time was of the essence.

During the retrospective, we brainstormed ways to improve the team. When we got to one of the SMEs, he said, “Guys, this project is making me ill. I haven’t slept in weeks, and I don’t think I can do it anymore.”

What happened next was a great example of how a team can work together. Not only did we acknowledge that it wasn’t okay for him to feel that way but we immediately came up with tangible solutions for improving team dynamics. We didn’t like that we had reached that point, but we celebrated that our SME had the psychological safety to be honest about how he was feeling.

That turned out to be one of the best teams I’ve worked with, not only because of the genuine relationships we formed but also because we went on to develop a product that generated millions in revenue.

Focus on people, and the rest will take care of itself. It is essential to have tangible improvements from a retrospective; otherwise, people will start to see them as a waste of time. Remember that every team is unique, and what works for one may not work for another. Adapt the retrospective process to suit the team’s preferences and needs and be open to experimenting with different techniques or approaches to find what works best.

Team Artifacts

There are several key artifacts that we wanted to make sure we didn’t overlook. You may have others that you regularly incorporate into your teams as well; just keep in mind the Agile Manifesto Value in that we find Working Systems to be more important than Comprehensive Documentation.

Definition of Done

The Definition of Done (DoD) is the team’s checklist to ensure that the work can be considered complete. Team DoDs evolve over the life of the team and often with the maturity of the Continuous Delivery Pipeline.

We encourage the team to regularly review the DoD (the Retrospective is a prime opportunity) and ensure that the DoD is accessible, visible, and used by the team for the stories they complete.

Pro tip

Too often I see new teams have a DoD that includes something to the effect that the story is deployed to production. This leads to teams ignoring the DoD and subsequently, we see quality issues creep into the system. Leverage the Scalable Definition of Done to help teams, ARTs, and Leadership understand what should and shouldn’t be included at the different levels or stages.

Definition of Ready

The Definition of Ready (DoR) helps the team mature its backlog. This checklist should be short and outline the criteria a story must meet before it can be pulled into the iteration for a Scrum Team or worked on by a Kanban Team.

Some items teams typically include are as follows:

• The Story has clear Acceptance Criteria
• Story dependencies have been identified
• The Story has been estimated
• The Story has been reviewed with the team and pending questions have been answered

You may often find that if a team is struggling to deliver all the stories they commit to in an iteration, spending some time creating a DoR or refreshing the DoR, which can drive improvement.

Working Agreements

Working Agreements, sometimes called team norms or charters, establish a shared understanding of expectations for team members on how they will work together. This artifact can help the team get to the high-performing stage quickly.

The Working Agreements help reduce inefficiency by clarifying how the team should communicate, collaborate, make decisions, and resolve issues. Working Agreements promote transparency, respect, trust, and accountability within the team.

Ensure that you regularly review the team Working Agreements and add new items to the Team’s Working Agreement and remove items that are no longer necessary.

Summary

We learned about the importance of regular and synchronized events within a team, regardless of type. These events serve as checkpoints for the team’s progress and are crucial for effective and efficient delivery, as well as achieving high performance. We have explored various team events, such as Iteration Planning, Team Syncs, Backlog Refinement, Iteration Reviews, Iteration Retrospectives, and Iteration System Demos. We have also looked at key artifacts that contribute to a team’s success, including the DoD, DoR, and Working Agreements.

Further reading

1. SAFe® Studio https://community.scaledagile.com
2. SAFe® Scrum https://scaledagileframework.com/safe-scrum/
3. SAFe® Team Kanban https://scaledagileframework.com/safe-team-kanban/
4. Iteration Planning https://scaledagileframework.com/iteration-planning/
5. Iteration Review https://scaledagileframework.com/iteration-review/
6. Iteration Retrospective https://scaledagileframework.com/iteration-retrospective/
7. System Demo https://scaledagileframework.com/system-demo/
8. Iteration Goals https://scaledagileframework.com/iteration-goals/
9. Derby, E. & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
10. Team Backlog: https://scaledagileframework.com/team-backlog/
11. Scalable Definition of Done: https://scaledagileframework.com/built-in-quality/