5 Misconceptions about Scrum's Sprint Event

Many well-meaning Scrum practitioners have misconceptions about Scrum, which sometimes leads to creating “rules” that do not exist in the framework. Scrum is deliberately incomplete because the framework is used in complex environments where simple best practices won’t fit all situations. So, there are no directions about HOW to run your Scrum team. As the 2020 Scrum Guide puts it, “Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.”

The Sprint is one of the five events defined in the Scrum Guide. It is a container event, which means that it contains all other events, including Sprint Planning, the Daily Scrum, the Sprint Retrospective, and the Sprint Review. According to the 2020 Scrum Guide, the Sprint is the “heartbeat” of Scrum. The duration of the Sprint is timeboxed to a maximum of one month, establishing a cadence within which the Scrum team works together to deliver value.

Below are five of the most common misconceptions about the Sprint.

Misconception # 1: The minimum duration of the Sprint is one week

While the Scrum framework sets a one-month maximum duration for the Sprint, there is no minimum duration requirement. Some teams may choose a Sprint of one day; others may decide on a Sprint duration of one week, two weeks or longer, up to one month.

Here’s why: To deal with the risk inherent in complex environments, Scrum uses an iterative, incremental approach. This means that the team delivers value in small pieces, more frequently, and in Done increments. Additionally, Scrum is based on the empirical process, which relies upon transparency, inspection, and adaptation. Therefore, it is essential to employ frequent feedback loops so that teams can inspect and adapt regularly. A timebox maximum of one month (or shorter) supports that regular feedback.

Misconception # 2: In a high-risk environment, the Sprint should be longer

While some Scrum practitioners working in high-risk environments might think that the team should adopt a longer sprint to mitigate risk, the opposite is true. A shorter Sprint is better than a longer Sprint in a high-risk environment.

Here’s why: Imagine that your team is working in an environment with frequently changing requirements. Wouldn’t you want to meet with stakeholders more often at the Sprint Review to get feedback? Or, imagine that your team is working in an environment with unstable technology. Doesn’t it make sense to meet frequently to review what has been done, determine whether the current approach is working, and replan if necessary?

So what is the optimum length of a Sprint? That depends on your situation. The Sprint should be just long enough to deliver a Done, valuable increment. When in doubt, choose a shorter Sprint duration over a longer one.

Misconception # 3: There should be downtime between Sprints

For those new to Scrum, it can seem overwhelming to think that there is no downtime between Sprints. In fact, because Scrum fosters work-life balance, there isn’t a need for downtime.

Here’s why: Because Scrum enables teams to manage their time and work (rather than an outside force), their pace and scope are more sustainable. With teams engaging in continuous refinement during all Sprints, they are ready for each upcoming Sprint Planning event.

Misconception # 4: Work must be released at the end of the Sprint

Many believe that the team must release its work to production to complete a Sprint. Not true. At the end of the Sprint, the Scrum Team should deliver a Done, RELEASABLE increment, but it is not obligated to put it into production.

Here’s why: While the work the team delivers must be usable and therefore potentially releasable, the Product Owner may decide to wait until a minimum set of features is ready before releasing them to production. There may be many reasons for this, such as specific legal requirements or even creating a marketing splash.

Misconception # 5: You should cancel the Sprint if the team is not on track to deliver all planned work

The purpose of the Sprint is to deliver a Done, usable increment at least once by the end of the Sprint. The truth is that sometimes this doesn’t happen. Sometimes things go wrong. Maybe the test environment unexpectedly became unavailable, or the team simply underestimated the amount of work they had pulled into the Sprint. Perhaps the Product Backlog items were not cut small enough to enable incremental delivery. Whatever the case, sometimes, the Scrum Team simply cannot deliver a Done, usable increment that meets the Sprint Goal. That’s not a reason to cancel the Sprint.

Here’s why: Rather than cancel the Sprint, view the prospect of not meeting the Sprint Goal as an opportunity to learn. The team should continue to use the Daily Scrum to inspect and adapt their progress to increase the likelihood of delivering a Done, usable increment that meets the Sprint Goal. Then, at the Sprint Retrospective, the team can discuss what happened and develop actionable improvement ideas to increase the likelihood of delivering a Done, usable increment next Sprint.

Conclusion

Digital.ai’s 15th annual State of Agile Report reveals that agile adoption grew from 37% in 2020 to 86% in 2021 for software teams. Inevitably, that rapid increase means that many individuals working within agile environments have not yet undertaken formal training in one of its frameworks. That’s a perfect storm for misinformation to spread. If your team needs a Scrum refresher, signup for the Applying Professional Scrum course with Rebel Scrum. Contact us for private training opportunities.