Chapter 7: The Sprint Journey

So far in this book, we have learned about the Scrum Team, events, and artifacts, things that form the basis of the Scrum framework. We also explored some standard practices used by Scrum Teams for planning and forecasting. What all of the aforementioned have in common is that they take place or interact with each other during the main Scrum Event, that is, the Sprint. The Sprint is a container event, within which the Scrum Team selects, plans, and delivers value in the form of one (or more) increments.

In this chapter, we'll discuss the activities that take place inside a Sprint, beyond and in addition to the previously examined Scrum Events. Specifically, we will learn how to deal with all the things that take place within the Sprint, such as the following:

• Refining the Product Backlog
• Preparing for the first Sprint
• Monitoring progress with a Scrum Board
• What to do when the Sprint Goal is not achieved
• Managing defects
...

Refining the Product Backlog

Before we can start a Sprint, we must have a refined Product Backlog. Product Backlog refinement is the activity of breaking down backlog items into more concise and manageable items and providing more details. During refining, the Scrum Team analyzes, discusses, estimates, and orders backlog items. The purpose of the activity is to enable Developers to start working on items with the least amount of disruption or ambiguity.

So, a refined backlog is one in which items are detailed, estimated, and ordered. We have already learned how to create detailed and descriptive backlog items as user stories or features in Chapter 5, Scrum Artifacts. We have also examined how to estimate items in Chapter 6, Planning and Estimating with Scrum. In this section, we'll delve more into the one remaining aspect of backlog refinement we haven't covered yet: ordering.

Tip

Some Scrum Teams hold weekly refinement meetings, usually led by the Product Owner...

Preparing for the first Sprint

In Scrum, every Sprint is treated exactly the same as any other Sprint. It is a time-boxed event in which the Scrum Team delivers value by creating an increment of potentially releasable software. No Sprint is special in that respect. Some teams, however, especially teams inexperienced in Scrum, tend to treat the first Sprint a bit differently than the others.

Tip

Avoid the Scrum 0 anti-pattern. A Scrum 0 is a Scrum dedicated to setting up infrastructure, creating a design or architecture, initial backlog refinements, and other preparatory work. Scrum 0 is just a set of preliminary activities and does not produce an increment of potentially releasable software. Sprints designed not to produce a Done increment undermine the Scrum principles and should not be pursued.

A common misconception about the first Sprint is that because it's not expected to produce user-side functionality, then it's a special Sprint and can be used as a repository...

Tracking progress with a Scrum Board

A Scrum Board is a tool that helps Scrum Teams visualize Sprint Backlog items and track their progress. The board can have different styles and content, depending on the team and organization where it's being used, but its purpose remains the same. The board is updated by the team and shows all items that need to be completed for the current Sprint. Items on a Scrum Board are usually represented as cards. Each card has a title, description, and other metadata, and can be colored and labeled in different ways.

Scrum Boards are not strictly defined. Some have fewer columns than others. Some have differently named columns. What they all have in common, however, is that they allow us to visualize our workflow, to know how our team is doing, and to get a feel for the direction our development is heading. A minimalist Scrum Board is depicted in the following diagram:

Figure 7.1 – A Scrum Board

Let's examine...

What to do when the Sprint Goal is not achieved

Occasionally, the team will realize they are not able to reach the Sprint Goal by the end of the Sprint or that the Goal hasn't been achieved at the end of Sprint. This usually happens because of two reasons:

• The Developers haven't been able to deliver all the Sprint Backlog items.
• The increment is not in a usable state.

Let's examine both causes, starting with the first one. When one or more Sprint Backlog items have not been finished by the end of the Sprint, this is sometimes due to extraneous circumstances (for example, a Developer has fallen ill). Most often, however, it happens because the Developers did not estimate the items correctly. Unfinished items by the Sprint's end are not uncommon, although this tends to happen more often during the early Sprints, when the team hasn't yet established its internal rhythm and delivery cadence.

Important note

Some teams and organizations refer...

Managing defects

Defects are an unavoidable part of software development. No one is perfect and no methodology is foolproof; as a result, every Scrum Team will deal with defects at some time during product development. Scrum provides plenty of opportunities for inspection and adaptation, thereby helping to take steps to minimize the occurrence and impact of defects. The way we deal with defects in Scrum depends largely on when the defects are discovered:

• In-Sprint defects are defects discovered within the current Sprint.
• Out-of-Sprint defects are discovered in previously released increments.

Before delving into these two scenarios, let's talk a bit more about defects.

Knowing how to triage defects

A defect is a discrepancy between the software's actual and expected behavior. A defect is usually caused by a coding or design error (a bug) or by a misunderstanding of the user requirements. When the Scrum Team becomes aware of a defect, they should ensure...

Canceling the Sprint

A Sprint may end in one of two ways. The vast majority of times, the Team will have worked throughout the Sprint's duration and will have ended up achieving, not achieving, or partly achieving the Sprint Goal. We have already discussed how to deal with these eventualities in the previous sections of this chapter. However, there are some very rare occasions where the team won't get to the end of the Sprint, as the Sprint gets canceled. Let's examine this more closely.

Canceling a Sprint is a very rare phenomenon. It generally happens when a new situation or extraordinary circumstances shift the team's commitment and focus. A Sprint must not get canceled if the Scrum Team simply decides that it cannot complete the work, or that it cannot reach the Sprint Goal. Frequently canceled Sprints should ring alarm bells. They may be a sign that the Scrum Team is lacking focus and commitment, the product is lacking a vision, or the organization does...

Summary

In this chapter, we learned about managing the Sprint itself. Practices for refining the backlog, using a Scrum Board, or managing defects are not part of the Scrum framework and aren't explained in the Scrum Guide. However, they are vital parts of a Sprint and essential knowledge for a skilled Scrum Master.

The first thing we learned is how to order the Product Backlog. A properly ordered backlog makes adding items to the Sprint Backlog so much easier and optimizes the value delivered in the Sprint. We then examined how to prepare the team for the beginning of product development and the first Sprint. Getting prepared before the Sprint development cycle begins ensures that the first Sprint will go smoothly and that the Scrum values and principles are not compromised.

Next, we discussed how to use a Scrum Board to track our progress through the Sprint and how to cope with different scenarios, such as when defects are found or when the Sprint Goal cannot be achieved...

Questions

1. Which activities are performed during Product Backlog refinement? (Choose all that apply.)

   a) Estimating backlog items

   b) Ordering backlog items

   c) Analyzing, discussing, and explaining backlog items

   d) Creating tasks required to complete backlog items

2. In which ways is the Product Backlog ordered? (Choose one answer.)

   a) Items with the highest value go to the top.

   b) Items with the lowest cost go to the top.

   c) Items with the lowest risk go to the top.

   d) Whichever way the product owner decides.

3. Certain Sprints, such as the first Sprint, are treated differently as they do not produce a Product Increment (TRUE or FALSE)

   a) True

   b) False

4. When should a Sprint be canceled? (Choose one answer.)

   a) Never. A Sprint should always be completed.

   b) When two or more developers are ill or otherwise absent.

   c) When the Sprint goal becomes redundant.

   d) When developers cannot complete the items in the Sprint Backlog.

5. During the Sprint, a defect is discovered related to an item currently...

Further reading

• Zombie Scrum Survival Guide (The Professional Scrum Series), Christiaan Verwijs, Johannes Schartau, Barry Overeem, Aug 2020
• Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth S. Rubin, Addison-Wesley, Jul 2012