Day-To-Day within an Iteration

Let’s take a look at the events we hold at the team level as it will provide the foundation for what we largely replicate in a fashion at the ART level. We will look at the events role by role to ensure we align with the basic expectations for teams on the ART.

Iteration Events and the Product Owner

As we discovered in Chapter 2, the Product Owner (PO) is critical to the team. The PO spends a lot of time working with Product Management, Stakeholders, and customers to understand the direction the ART is headed, and then with the team to identify, plan, and coordinate that work. It’s a constant balance of today’s versus tomorrow’s work.

Figure 3.1 outlines the key responsibilities of the PO; however, let’s look at how the PO executes these responsibilities through the various team events.

Figure 3.1 – Product Owner Responsibilities (© Scaled Agile, Inc.)

During the iteration, it’s important that the PO is present and involved with the team every day.

The Product Owner and Iteration Planning

Iteration Planning is one of the most important events for the PO. The PO helps the team understand and select the most important work that needs to be accomplished, and in return, gets a commitment on what will be completed at the end of the iteration.

The PO will provide clarity about the stories or Acceptance Criteria and, collectively with the team, establish the Iteration Goal.

The PO will need to prepare for this event and the preparation is a key part of their responsibilities. As we saw in Figure 3.1, Managing and Prioritizing the Team Backlog is a key responsibility, and the Team Backlog is the primary input into Iteration Planning.

The Product Owner and the Team Sync

At the Team Sync (formerly known as the Daily Stand-up or DSU), the PO should actively participate; answering questions, providing clarity, understanding when items are ready for review. We encourage the PO to attend the Team Sync every day as they are a member on the Agile Team with a speciality role.

The Product Owner and Team Backlog Refinement

Backlog Refinement, just like Iteration Planning, is critical for the PO. The PO will want to ensure that they are capturing the conversations and questions from the team, and then get answers to those questions. The PO will need to provide clarification and feedback on every story or connect the team with customers and/or Stakeholders to get direct answers.

The Definition of Ready (DoR) helps hold the PO and Agile Team accountable for the quality of the stories.

The PO may need to work with Technical Leads or the System Architect on Enabler Stories and also ensure that the Backlog has the right balance (Capacity Allocation) of Enabler versus Stories.

Pro tip

If you are finding that your teams are struggling with their Iteration Planning, it is a sign that you might need more effective Backlog Refinement.

The Product Owner and the Iteration Review

At the Iteration Review, the PO will share with the Stakeholders the Iteration Goal and the progress the team has made toward that goal. The PO will then solicit feedback from the Stakeholders on the work done by the team and share the work likely to be planned for the next iteration.

This is also an opportunity for the PO to seek help from the Stakeholders on challenges the team might have.

The Product Owner and the Iteration Retrospective

The PO needs to be at the Iteration Retrospective as they are a member of the team and are also responsible for helping the team to continuously improve. The PO can contribute ideas to improve the team’s effectiveness just like any other team member. The PO should help the team incorporate the improvement items into the next Iteration Backlog or Team Backlog.

Pro tip

I am often asked, “Does the PO need to be at the Retrospective?” This is a clue that there may be some challenges within the team and, most often, the quality of the stories (also known as we aren’t following or don’t have an agreed upon Definition of Ready), or the PO is wearing multiple hats and isn’t available. The team usually then takes the opportunity to complain about the PO rather than working together to relentlessly improve.

As a Coach, you will often get what seems like an innocuous question; ensure that you dig in a little bit to understand the real root cause of the question.

Iteration Events and the Scrum Master/Team Coach

It’s critical for the Scrum Master/Team Coach (SM/TC) to be involved with the team every day, especially new teams. The Scrum Master/Team Coach carries a lot of the burden in ensuring that the teams are successful and executing effectively.

Figure 3.2 captures the key responsibilities the Scrum Master/Team Coach is responsible for; however, like the PO, the devil is in the details when it comes to the everyday interactions with the team.

Figure 3.2 – Scrum Master/Team Coach responsibilities (© Scaled Agile, Inc.)

The Scrum Master/Team Coach never has two days that will be the same. The team is constantly evolving, the work is changing, dependencies need to be resolved, and the systems are updating. The one constant is that the Scrum Master/Team Coach is the glue that keeps it all together.

There is a common misperception that the Scrum Master/Team Coach is the team administrative assistant, often because the Scrum Master/Team Coach typically schedules and facilitates the Team Events. While the latter is true, without the support and drive to relentlessly improve from the Scrum Master/Team Coach, the team will stagnate.

The Scrum Master/Team Coach and Iteration Planning

The Scrum Master/Team Coach is the facilitator for Iteration Planning. The Scrum Master/Team Coach should help ensure that the PO and the team are ready for planning and with a prioritized Team Backlog. As the facilitator of the event, the Scrum Master/Team Coach will need to pay close attention to the time and help capture and follow up on any new questions that arise.

The Scrum Master/Team Coach often works with the team ahead of time to understand any planned leave that needs to be accounted for in the team’s capacity. The Scrum Master/Team Coach will often have to help the team to make sure they don’t over-plan or commit to more work than they can deliver.

The Scrum Master/Team Coach should ensure commitment to the plan at the end of the event.

The Scrum Master/Team Coach and the Team Sync

The Scrum Master/Team Coach facilitates the Team Sync (formerly the Daily Stand-up or DSU). Facilitation activities in this event include the following:

• Ensuring everyone participates
• Ensuring the event keeps to time (typically 15 minutes)
• Ensuring the team is tracking their progress to the Iteration Goal and adapting plans if necessary
• Providing the team with a way of running in the absence of the Scrum Master/Team Coach
• Providing the team with a mechanism to capture impediments and address them in a Meet-After session

After the Team Sync, the Scrum Master/Team Coach will need to facilitate the resolution of the captured impediments the team raised.

Some pitfalls an Scrum Master/Team Coach will want to avoid are as follows:

• Ensuring this event is such that it doesn’t turn into a status meeting
• Not following up and closing out impediments

The Scrum Master/Team Coach and Backlog Refinement

The Scrum Master/Team Coach facilitates Backlog Refinement in conjunction with the PO. The Scrum Master/Team Coach will want to make sure that the PO is prepared for Backlog Refinement, help track the items that have been or need to be discussed, ensure questions are captured and followed up on, and generally provide support to the PO and team during the event.

The Scrum Master/Team Coach and the Iteration Review

The Scrum Master/Team Coach should ensure that the team is prepared and ready to present their work at the Iteration Review. The Scrum Master/Team Coach may need to work with the team ahead of time to identify how to best present the work.

The Scrum Master/Team Coach will need to work with the PO to determine which Stakeholders should be invited and to create an agenda highlighting the work that the team has completed.

The Scrum Master/Team Coach is a cheerleader at this event, ensuring success is acknowledged and kudos given to the team.

Lastly, the Scrum Master/Team Coach will need to facilitate the preparation and sharing of the iteration metrics and progress toward PI Objectives with the Stakeholders.

The Scrum Master/Team Coach and the Iteration Retrospective

The Iteration Retrospective is where the Scrum Master/Team Coach creativity gets to bloom by using and creating different retrospectives to garner insights from the team. At the retrospective, the Scrum Master/Team Coach needs to create a safe environment for the team to be vulnerable and share their challenges, as well as celebrate their wins from the last iteration.

Capturing and following up on Improvement Items every iteration should not be overlooked, and the Scrum Master/Team Coach is responsible for driving these items within the team.

Pro tip

It is important that the Iteration Retrospective doesn’t become stale by running the same format iteration after iteration. By a similar token, you don’t want to make the Iteration Retrospective super silly. The Scrum Master/Team Coach should focus the retrospective on key areas for improvement encountered with the iteration: for example, topics such as people, interactions, processes, tools, assumptions made, and the Definition of Done. A great reference is Agile Retrospectives by Diane Larsen and Esther Derby [9].

Iteration Activities and the Agile Team

As we look at the responsibilities of an Agile Team in Figure 3.3, we can see that they largely revolve around the work, whom it is for (customer), figuring out what the team will do (planning), doing the work, validating the work (feedback), and relentlessly getting better at the work.

Figure 3.3 – Responsibilities of an Agile Team (© Scaled Agile, Inc.)

To ensure success, there are some key events that we look to the team to participate in. Regardless of how the team is executing (Scrum or Kanban), every team needs to maintain alignment with itself and the ART. We will look at each event in the iteration and the associated responsibilities and activities.

The Agile Team and Iteration Planning

Both Scrum and Kanban teams will participate in planning. Chapter 5 provides a more in-depth look at the process. Scrum Teams will do this once per iteration, whereas a Kanban team may often plan more frequently than a Scrum Team, but for shorter durations.

The entire team needs to be present for planning to ensure alignment, provide input, and commit to the plans.

The Agile Team and Team Sync

Team members need to ensure they attend the Team Sync every day and that they are inspecting progress towards their Iteration Goal, adapting their Iteration Plan if necessary, raising any impediments, and planning their next 24 hours of work.

The Agile Team and Backlog Refinement

All Agile Teams need to be involved in the refinement of the Team Backlog so that they understand the backlog items in order to be able to develop the solution in the iterations. This will involve conversations with the PO and the Stakeholders to gain enough information to split items into small vertical slices that meet the Definition of Done.

The Agile Team and the Iteration Review

The Iteration Review is primarily used by Agile Teams as an opportunity to get feedback from Stakeholders and inspect the outcomes and compare them to the Iteration Goals they have committed to. The Agile Team should present the actual work that was completed that met the Definition of Done. It’s an opportunity for the team to celebrate their successes and to identify and address any challenges and/or stories that were not completed.

Pro tip

Avoid doing PowerPoint presentations; try showing the actual solution that the team has built.

The Agile Team and the Iteration Retrospective

To ensure relentless improvement, it’s important that teams are holding regular retrospectives, and this includes Kanban teams. Many Kanban teams will hold their retrospectives on the same cadence as the ART.

All team members need to participate and provide insight and input into how the iteration went and how to improve moving forward. After all, it’s the team that is ultimately responsible for themselves.