Chapter 5

Getting the Most Out of Sprints

IN THIS CHAPTER

Benefiting from the daily scrum

Swarming to get to done

Running effective sprint reviews

Finding the key elements of the sprint retrospective

Sprints are the essence of scrum, so it’s worth spending an entire chapter on them. You have the gist already: Sprints are fixed timeboxes designed so that your development team can create a development rhythm. They also nurture the inspect-and-adapt premise.

But that’s not all that sprints do. This chapter introduces the daily scrum — an invaluable 15 minutes every day that will focus and organize your short-term goals like never before. Facilitated by the scrum master, the daily scrum keeps your project on track as the scrum team deals with impediments and coordinates the day’s priorities.

This chapter also exposes you to the sprint review and sprint retrospective. These two meetings take the concepts of inspection and adaptation to new levels. Stakeholders review the product developed and give the product owner immediate feedback; the scrum team itself assesses how the sprint went and incorporates any improvements into the process.

The Daily Scrum: Stage 5

The daily scrum is one of the five scrum events and Stage 5 on the Roadmap to Value (see Figure 5-1).

© John Wiley & Sons, Inc.

FIGURE 5-1: The daily scrum is an integral aspect of the sprint and Stage 5 in the Roadmap to Value.

Planning is huge in scrum. You don’t set a goal, forget it, and then gather together six months later to see what happened. You inspect and adapt every single day, and even throughout the day.

Because a development team swarms each day to attack a single requirement, coordination is key. The removal of impediments is also crucial for developers who work closely together to deliver potentially shippable increments within short periods. The daily scrum is how the development team coordinates.

If you manage your projects by weeks (that is, with weekly project manager status reports that may not get reviewed promptly), you slip by weeks. In scrum, you may still slip but only by a day, because scrum teams manage by day through the sprint backlog, the daily scrum, and daily and direct interaction. You look more closely at this comparison in Chapter 6 of Book 5.

Defining the daily scrum

As its name implies, a daily scrum takes place during each sprint. The timebox is 15 minutes maximum, no matter what the overall length of the sprint is. Meetings in scrum, like artifacts, are barely sufficient. Anything longer than 15 minutes would eat into valuable developing time. Besides, 15 minutes is plenty of time to accomplish everything necessary.

The purpose of the daily scrum is to coordinate the day’s sprint activities and identify impediments keeping the development team from accomplishing its sprint goal. Every member of the development team participates, so everyone is dialed into what the entire team is working on. If an impediment comes up during the daily scrum, it’s dealt with following the daily scrum. The event is a coordination meeting, not a problem- or complaint-solving meeting.

The scrum master either removes impediments or facilitates their removal. Some impediments may need to be removed by the product owner or require discussion between a team member and someone outside the team.

Participants in the daily scrum are the development team members and the scrum master. The scrum master ensures that the meeting takes place, and the development team directs it. The product owner should attend (and must attend if specifically asked to do so by the development team). The product owner may provide clarifications on prioritization as needed, and anyone else who’s involved and interested can listen in but can’t say anything. This way, they can enjoy the daily transparency and be involved in the daily process, but they can’t hinder or derail it.

The daily scrum is how a development team self-organizes and self-manages. Each day, the team decides who will do what and who will help whom. Work isn’t dictated by a project manager or some other nondeveloper.

If a daily scrum starts to feel like a status-report meeting or development team members start addressing one person (such as an informal team lead or the scrum master), the meeting has missed the point. A daily scrum should be peer to peer.

The key takeaway from a daily scrum is clarity about what it means to be successful that day. Then the team swarms if necessary to do the highest-priority work. (Find out more about swarming later in this chapter.) The team finds value in this ceremony only if team members achieve relevant clarity and purpose about the day’s goals. Daily scrums offer an opportunity to inspect and adapt in the moment.

Scrum meetings ask the same questions daily: What was accomplished yesterday? What are you working on today? Do you need any help? A common misconception about the daily scrum is that it’s a time for the development team to report to the product owner or a time for product owners to introduce new requirements or update a sprint goal. Don’t let the daily scrum become a business-status-reporting meeting; it’s a coordination meeting to enable high performance.

Scheduling a daily scrum

Because a daily scrum lasts only 15 minutes, everyone needs to be on time and ready. You’ll find a direct correlation between how late a meeting starts and how loose the focus is after the meeting starts. You may have different ways of encouraging punctuality, such as the following:

• Start your daily scrum half an hour after the normal workday begins. This schedule gives your development team members time to get coffee, answer emails, discuss the previous evening’s antics, and cover anything else in their morning rituals.

• Penalize members for being late in a friendly, spirited way. Have team members pay a certain amount into a celebration fund for each minute they’re late or have them sing their college song at full tilt. Get creative and make the penalty uncomfortable enough to stop tardiness.

  A scrum team in Portland implemented a “$20 or 20 pushups with multiplier” incentive. The first time he was late, a team member paid $20 or did 20 pushups. The next time he was late, he paid $40 or did 40 pushups, and so on. This penalty was invented by the team members, not imposed on them. It worked for them and was successfully prevented tardiness.

A key disruptor of the daily scrum is distraction. Some teams have a regular habit of each member focusing on his or her own laptop screen. Some members even attend via phone while driving to the office. Listen for indicators such as “Can you say that again? I missed it.” No electronics should be the rule during the daily scrum.

Conducting a daily scrum

Imagine a scrum team gathering around its sprint backlog or task board at the beginning of the day. Each person can see at a glance the progress made the day before; then each person proactively chooses a new task for the current day. Team members coordinate where help is needed to accomplish a task before the day ends; then they go straight to work.

Each team member should make three statements about how he or she is helping the team achieve its sprint goal:

• Yesterday, I accomplished …
• Today, I’m going to focus on …
• The things impeding me are …

Scrum masters should participate beyond facilitation by addressing the impediments that are identified and/or in progress. The scrum master might say after the team members have spoken:

• Yesterday, I removed this impediment.
• Today, I can remove this impediment.
• The impediments I can’t remove are … , and I’ll see whether so-and-so can help me.

As discussed in Chapter 4 of Book 5, tasks should be broken down so that they can be accomplished in a day or less. Even then, when developers are left to themselves for days on end without coordinating and swarming as a team, they can get bogged down in unnecessary details or problems that could be easily resolved with help.

Daily scrums synchronize a team, and everyone goes to work helping each other do what it takes to get to done. Together they completely own the outcome. Come the next day, the team members are excited to talk about their progress.

Making daily scrums more effective

The following tactics can keep your daily scrum meetings quick and effective:

• Diligently start on time. See the earlier section “Scheduling a daily scrum” for some tips on enforcing punctuality.
• Conduct the meeting standing up. Studies have shown that meetings conducted standing up are 34 percent shorter than those conducted sitting down. No one has a chance to slump in a chair and relax; it’s as though everyone is already on the move.

• Focus the meeting on coordination, not problem-solving. Impediments get removed after the daily scrum.

  When impediments are uncovered in the daily scrum, the scrum master can deal with them by hosting an after party immediately following the daily scrum. This event involves only those who need to be involved and is for addressing any issues that came up during the daily scrum.

  A backlog of these “team topics” can also be kept so that the topics can be addressed by the team during the after party when appropriate or during the team retrospective. Not all topics raised during the daily standup need to be addressed that day, but they should be recorded in the backlog.

• The scrum master is the meeting facilitator and, as necessary, keeps the meeting on time and on track, and makes sure that only development team members participate. The scrum master’s touch should be as light as possible.
• Cover only immediate issues and priorities in relation to that day in support of the sprint goal.
• Gather around the task board to ensure context and focus.

• Don’t assign a set speaking order because when people know the order, they tend to check out until it’s their turn. In some cases, they don’t even show up until just before their turn.

  You can toss a squeaky dog toy to a random member of the development team when that person should speak. If anyone takes too long, you can switch to a timer ball with an alarm. An alternative is to toss a ream of paper (which weighs 5 pounds) and let the person talk for as long as he can hold the paper out to his side. These tactics keep the daily scrum fast, forward-moving, and fun.

• Don’t allow vague statements or rely on team members’ memories of what’s in the sprint backlog (see the next section, “The Team Task Board”).

The Team Task Board

A task board is one way to display the sprint backlog. Although it’s common for scrum teams to manage their sprint backlog in digital format, all you really need are some wall or whiteboard space, 3x5 cards, sticky notes, and tape. Figure 5-2 shows a sample task board.

The task board, like the product roadmap, increases engagement and flexibility because it’s tangible.

A physical task board is excellent because it’s a quick, effective way to show the status of an entire sprint. Keeping the task board within sight of the development team and product owner ensures that everyone instantly knows what’s done, what’s not done, and everything in between.

© John Wiley & Sons, Inc.

FIGURE 5-2: A team task board.

Use these basic elements:

• Top

  • The specific sprint goal
  • The overall release goal

  Release and sprint dates can also be included.

• Columns (from left to right)

  • To Do: Requirements and tasks in the sprint that have yet to be developed

    Developers pull from the top of this list to start a new task. If two developers want to take the same task, they can pair up on it, one developer can shadow the other, or they can decide who can best handle it.

  • In Progress: The product backlog items and tasks that the development team is working on

    Each task may have different colored dots or stickers to designate ownership or to identify tasks that are blocked by an impediment. Work-in-progress limits, if used, should be displayed in this column. After developers complete a task, they look here to see who they can help. Otherwise, they pull the next task from the To Do column and verify with the team that it’s the right task to work on.

  • Accept: Requirements that are awaiting acceptance by the product owner

    If the requirement is rejected, and enough time is left in the sprint, it goes back to the In Progress column. Otherwise, the requirement gets moved back to the product backlog for consideration in a future sprint (see the later section “Handling unfinished requirements”).

  • Done: The requirements that the product owner has accepted as complete

Only the development team members can move the requirements from To Do to In Progress to Accept, and only the product owner can move them from Accept to Done. After a requirement is accepted by the product owner and moved to the Done column, the development team moves tasks with it. Otherwise, if a requirement gets rejected, the development team moves tasks back to In Progress to rework them or creates new tasks to address the reason why the requirement was rejected.

Requirements in the Accept column shouldn’t be allowed to pile up. Ideally, when a card is placed in Accept, it should either be placed in Done or rejected for further development the same day. If a delay occurs, the product owner needs to be coached to not letting stories accumulate as they wait to be accepted. You have no reason for delay if the product owner is a dedicated scrum team member who is available at any time for clarification, the requirements have been detailed to a single action or integration, and the requirements have passed the definition of done. It’s critical for the development team members to know when their work is done and can swarm the next requirement.

Swarming

Chapter 4 in Book 5 introduces the concept of swarming in the context of the sprint backlog. Swarming is all development team members working on only one requirement at a time during the sprint. Although this principle isn’t specific to scrum, it’s such an effective way for teams to execute their sprint backlog that it warrants discussion here.

One of the main benefits of scrum is that development teams start and finish requirements to satisfy their definition of done to produce a potentially shippable product increment within a relatively short timebox. The team revises the process based on lessons learned and repeat that cycle again and again. The goal is to finish, not just start, as many requirements as possible.

Swarming enables teams to enjoy the following benefits:

• Maximizing chances for success, with the skills and abilities of the entire team focused on a single requirement
• Completing the cycle of planning, designing, developing, and testing to completion for each requirement
• Resolving issues and impediments today
• Dramatically decreasing the introduction of defects into a product through pairing and single-tasking (versus multitasking)
• Eliminating single points of failure in knowledge, processes, and skill sets
• Finishing the most important requirements completely and first

When team members see all their fellow developers working on a task, and there are no other tasks left for the same requirement (the user story), it’s perfectly natural for them to consider it more productive to start a new requirement than to help other developers on the requirement in progress. This tendency can get out of hand, however, to the point where teams find themselves with multiple requirements started but none of them finished. By shadowing, pairing, researching, or helping in whatever way gets the task to done, development teams avoid this risk.

This process ensures that in every sprint, something gets completely developed and is available to show stakeholders. Every sprint produces shippable results. The development team’s efforts are focused, teamwork is enhanced, and the iterative process of scrum is put into play.

Stay focused. Stop starting and start finishing.

Dealing with rejection

If a requirement placed in the Accept column is rejected by the product owner, the developers have two options:

• Finish their current tasks and then swarm the rejected requirement: This option might be better if plenty of time is left in the sprint to complete both the current tasks and the rejected requirement.
• Abandon their current tasks to swarm the rejected requirement: This option might be better if not enough time remains in the sprint to finish both the current tasks and the rejected requirement.

The product owner decides the priority when faced with this decision. Variables other than time left in the sprint may influence the product owner’s decision. As the team inspects its learning and adapts throughout a sprint, the rejected story may become less valuable to achieving the sprint goal than the next requirement in progress, so even though time is left in the sprint to do both, the risk of not finishing the in-progress requirement may be higher than the risk of not finishing the rejected requirement.

In any case, attention to priority and close daily coordination with the product owner throughout the sprint keep the entire scrum team (including the product owner) on focus and on task.

Scrum teams should always push themselves. If development teams accomplish 100 percent of their sprint backlog every time, they may not be pushing themselves to their limit. A high percentage of sprint backlog completion should be the goal, but you shouldn’t expect scrum teams to hit 100 percent every time. Scrum masters, like aeronautical engineers, help the scrum team find ways to reduce drag to become more effective and accomplish more in each sprint. As long as teams finish what they start each sprint and increase velocity, they realize the continuous-improvement benefit of scrum.

Handling unfinished requirements

Even high-functioning development teams that estimate well, swarm, and stick to a work-in-progress (WIP) limit of one throughout each sprint may end up with incomplete or unstarted requirements left on the sprint backlog at the end of a sprint. This result may be okay if team members swarmed on the higher-priority requirements to completion and have working product increments that can be shipped.

But what does the team do with those remaining requirements?

If a requirement isn’t started, or was started and not completed, the product owner puts it back in the product backlog in its entirety (keeping all notes, tasks, and documentation intact, of course) and then reprioritizes it against the rest of the product backlog. The product owner may potentially pull the requirement into a future sprint according to its new priority.

Based on what was completed during the sprint, the unstarted or unfinished requirement may no longer be necessary, or it may not have as high a value as it had before. What was done may be enough; it may be time to move on to a different feature.

Whatever effort was made on the requirement, because it wasn’t finished, it isn’t included in the team’s velocity for that sprint. If the requirement does make it into a future sprint, it needs to be refined, clarified, and reestimated based on the remaining work to be done. You can’t bank or cache story points.

An exception may occur when, after working on an unfinished requirement, you find that you can split it. You finish one part of the requirement during the sprint; the other part goes back into the product backlog to be reestimated and reprioritized.

The lesson in all this is swarm to get to Done during the sprint.

The Sprint Review: Stage 6

The next stop on the Roadmap to Value is Stage 6, the sprint review (see Figure 5-3). This scrum event is integral to the inspect-and-adapt process of scrum and takes place at the end of each sprint.

© John Wiley & Sons, Inc.

FIGURE 5-3: The sprint review is a scrum event and Stage 6 of the Roadmap to Value.

The purpose of the sprint review is for the product owner to get organizational feedback on whether the product is moving in the right direction. This review is also a great opportunity for the development team to stand up and show off what it’s accomplished. Team members get full credit for what they’ve achieved and what they haven’t.

This meeting at the end of every sprint ensures that the stakeholders are up to date on what was accomplished in the sprint and have a forum for delivering feedback directly to the product owner, with the development team listening in. Also, stakeholders have working, shippable product in their hands.

The sprint review process

The sprint review, which is timeboxed to one hour per week of sprint, takes place at the end of the last day of the sprint. Allow for this time expenditure during the sprint-planning session.

The participants in the sprint review are the entire scrum team and the stakeholders, in these roles:

• Scrum master: Facilitates the meeting, ensuring that it stays in focus and on time.

• Product owner: Briefly reviews the sprint goal and how well the scrum team met the goal, fills in the stakeholders on what items from the backlog have been completed, and summarizes what’s left to go in the release.

  The sprint review isn’t the time for the product owner to provide feedback on the completed functionality. This event is for the product owner to receive feedback from stakeholders on the direction in which they’re taking the product. The product owner accepts or rejects each requirement as it’s completed, not at the end of the sprint, and approves the requirements before they’re demonstrated to the stakeholders.

• Development team members: Display and explain the completed requirements.
• Stakeholders: Ask questions and provide feedback.

The process begins with the development team preparing for the review. Consider the following guidelines for sprint-review preparation:

• The development team prepares a sprint review for the minimal amount of time (no more than 20 minutes) to showcase completed requirements.
• No formal slides should be used in a sprint review. Rather, the development team should spend its time developing the product instead of preparing a presentation.
• Only the requirements that have been deemed done (according to the definition of done) and approved by the product owner are demonstrated.
• The development team showcases the shippable (to market) functionality of the requirement — that is, how it works in the real world.

If you spend your time showing stakeholders what could or should have been done, you’re giving a rigged demonstration and haven’t done anyone any favors. Stakeholders never expect less; they always expect more. By making it look as though your product increment works when it really doesn’t, you increase your workload for the coming sprint, because you’ll have to make work what you showed should work, as well all the new work you’ll plan for. Demonstrate only working product increments.

Stakeholder feedback

Critical to the success of the sprint review is stakeholder feedback. A constant cycle of communication keeps the project on track and produces what stakeholders want. Although stakeholders can’t tell development team members how to develop requirements, they can give feedback to the product owner about the requirements and features they want developed and about how well the implementations serve customers’ needs.

The feedback loop is a lean principle of continuous improvement. It also serves another purpose: The feedback loop keeps the development team involved and, therefore, emotionally engaged in the project.

Feedback is a common theme throughout scrum. Figure 5-4 shows how many layers of feedback are involved in the scrum framework. Each time feedback is received, it gets cycled back into the product backlog and sprint-planning sessions — truly inspection and adaptation.

© John Wiley & Sons, Inc.

FIGURE 5-4: Multiple layers of feedback exist in a typical scrum project.

Product increments

The product increment is the final of the three scrum artifacts. (Chapter 2 in Book 5 discusses the product backlog, and Chapter 4 in Book 5 discusses the sprint backlog.)

Within a single sprint, the product increment is working product deemed done by the product owner and now ready to go to market. It’s potentially ready to go to market because the product owner may not decide that the product is ready until later. But it’s ready to ship as soon as the product owner is ready.

A product increment has been

• Developed
• Tested
• Integrated
• Documented

During the sprint-review meeting, this product increment is demonstrated to stakeholders. The inspect-and-adapt sprint life cycle continues as feedback is taken and translated into requirements. Then these requirements may be enhanced during product-backlog refinement; they may rise in priority for consideration in future sprints and eventually become new product increments.

The sprint review is about improving the value of the product. The sprint retrospective is how scrum teams can make this continuous improvement happen for their team and process.

The Sprint Retrospective: Stage 7

The seventh and final stage in the Roadmap to Value is the sprint retrospective (see Figure 5-5). This scrum event takes place after every sprint.

The purpose of the sprint retrospective is to provide an opportunity for the scrum team — scrum master, product owner, and development team members — to assess what went well in the sprint that was just finished and what can be improved. The process is inspection and adaptation one more time, with a focus on the people, processes, and tools that the scrum team uses.

© John Wiley & Sons, Inc.

FIGURE 5-5: The sprint retrospective, the seventh and final stage in the Roadmap to Value.

The outcome of the retrospective should be plans of action to continuously improve scrum, people, processes, and tools in every sprint. Although the scrum framework is simple — three roles, three artifacts, and five events — and doesn’t require tweaking, each scrum team has quirks and nuances because of their product, organization, and development methods. Through the process of inspection and adaptation, you can aim those individualities toward the project goals.

Because the sprint retrospective asks for input and feedback from all scrum team members, it increases ownership through engagement and a sense of purpose. Team spirit is enhanced, which in turn leads to an increase in productivity and velocity, which is self-management.

It’s critical in sprint retrospectives to create a trusting environment. Each person’s view is listened to and respected, and nothing is taken personally. Trust is the key to keeping the retrospective from being a labyrinth of euphemisms or politics. The scrum master plays a pivotal role in creating an environment of trust.

The sprint retrospective may unveil problems within the team. An adept scrum master can facilitate the event so that these issues are dealt with in an equitable, low-intensity environment. A sprint retrospective isn’t for venting, but for actionable plans for improvement. Be on the lookout for passive-aggressive speech and personal agendas.

The sprint retrospective process

The sprint retrospective takes place at the end of every sprint, after the sprint review and before the next sprint’s planning session. For each week of the sprint, 45 minutes is timeboxed for this event, so a two-week sprint has a timeboxed retrospective of 90 minutes.

The entire scrum team participates, and at the team’s discretion, other people may be invited (such as customers and stakeholders) if the team believes that these people have valuable insights about needed improvements.

In preparation for the retrospective, everyone should consider how the sprint went and jot down any ideas or concerns. As always, use simple tools such as sticky notes; avoid formal presentations.

Although the scrum master facilitates the meeting, everyone participates at a peer-to-peer level. The purpose of the sprint retrospective is to inspect the sprint that just ended to

• Identify what went well in the sprint with the processes, tools, and team dynamics.
• Discuss and discover opportunities for improvement.
• Define an action plan for implementing the improvement(s).

During the retrospective, be sure to emphasize and give equal air time to what went well. It’s important to focus on the positive and to identify what’s working well so that you can keep doing it. Rejoice as a team in successes. Especially during initial scrum implementation, it’s important to recognize the wins — big and small.

An effective way to keep things positive and avoid isolating people during a retrospective is the sandwich technique. Start with positive, work through negative, and end with more positive.

A retrospective discussion is action-oriented and doesn’t focus on justifications. When you hear the word because, that’s a good indication that the discussion has turned to justifying why someone did something a certain way. Keep moving forward by saying something like “This is what I experienced, and this is what might work better going forward.” Don’t say “I did it this way because …”

The Derby and Larsen process

Esther Derby and Diana Larsen wrote an excellent book called Agile Team Retrospectives: Making Good Teams Great (published by Pragmatic Bookshelf). Check it out for more tips and techniques on sprint retrospectives and other agile practices.

In Agile Team Retrospectives, Derby and Larsen point out that there is more to finding out what went well and what improvements need to be made than simply asking the same three questions at the end of every sprint. Retrospective facilitation takes preparation and strategy to get maximum participation, candor, and useful data from team members. The Derby and Larsen model for structuring a retrospective consists of answering these questions:

• What do you think went well?
• What would you like to change?
• How should we implement that change?

To maximize retrospective effectiveness, consider the Derby and Larsen process:

1. Set the stage.

   You want to establish ground rules for productive communication and clarify expectations and purpose from the beginning. Prepare the team for open and honest discussion.

2. Gather data.

   Making decisions based on superficial, bad, or incomplete data can do more harm than good. You want to uncover important topics, jog memories, and correlate experiences that need to be addressed. You want to know not only what people think, but also how they feel about it.

3. Generate insights.

   Many teams gather data but do nothing with it. Just as the best designs come from self-organizing teams, the best insights come from teams that take time to explore what the data means.

4. Decide what to do.

   Only through action can change and adaptation take place. Action requires a plan. Deciding what to do shifts the team’s focus to moving forward — to the next sprint.

5. Close the retrospective.

   Closing provides the opportunity to scrum the retrospective through activities that evaluate the effectiveness of the retrospective experience and identify ways to improve it. It also encourages expressing appreciation.

Each aspect of the retrospective can be facilitated by a number of activities that are engaging and provoke individual thought and group discussion. Try doing an Internet search for Triple Nickels, Five Whys, SMART Goals, Temperature Reading, Team Radar, and Mad Sad Glad, which are all good activities to use during a retrospective.

To stimulate discussion in retrospectives, organize activities around specific questions such as the following:

• What is keeping us from increasing our velocity from 36 to 38?
• Does everyone have the tools needed to do the job?
• Do any impediments keep repeating?
• Is our daily scrum effective in identifying impediments and coordinating daily priorities?
• Is our team lacking certain skills, and if so, how can we gain them?

Some scrum teams need to be coaxed and prodded to get engaged. They may be hesitant at first to say what they truly feel. Others may want to talk at once and are bursting with ideas and input. A perceptive, proactive scrum master adapts to work with either type of group, or anything in between, to achieve the best results.

Find only one action to take each sprint. At the beginning, it may be tempting to address all issues the team discusses. Instead, find an action that is both high-impact and easy to implement. Pick the low-hanging fruit.

The results from the retrospective should be put into the product backlog as improvement items. The scrum team should agree that at least one improvement action goes into every sprint. Bring at least one priority retrospective item into the next sprint, perhaps from the latest retrospective. After all, why wait? The purpose is to inspect and adapt, so don’t delay the adaptation part!

Inspection and adaptation

Scrum is about planning the right things at the right time. It’s about responding to changing markets and lessons learned. It’s about continually learning and assessing, minimizing risk, and maximizing value at every step — each point of work.

The inspecting and adapting perspective provided in the official Scrum Guide (http://scrumguides.org) is a good way to wrap up this chapter. The italics have been added for emphasis:

Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

The scrum guide goes on to state that adjustments are made as soon as possible. Adjustments occur as soon as an inspector realizes that the work has moved outside the limits and will cause an unacceptable product.