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 you’re facing any of these misconceptions, consider registering your team for the Applying Professional Scrum class. Applying Professional Scrum is the best class for those practicing Scrum without formal knowledge about the framework and want to expand their team’s productivity and practices.
If you are currently practicing the Scrum Master accountability, consider signing up for the Professional Scrum Master class. The Professional Scrum Master course is the best class for Scrum Masters who are looking for ways to improve the efficiency of their Scrum Teams.
If you are currently fulfilling the Product Owner accountability, consider signing up for the Professional Scrum Product Owner class. The Professional Scrum Product Owner course is the best class for Scrum Masters who are looking for ways to improve the efficiency of their Scrum Teams.
If you are an Agile leader looking for clarity on how to lead an Agile team, sign up for the Professional Agile Leadership class. This is the best class for managers or supervisors of individuals who work on Agile or Scrum teams.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.