Scrum Events: Myths and Facts

Myth

The Sprint should be a month or less. The vast majority of teams sprint in 1–4 week cycles (weeks are easier to schedule around than months). Two weeks is becoming most common in the industry.

Myth

Asking the team to commit to delivering a particular set of work limits their ability to react to new learnings during the sprint, threatens their work-life balance, and encourages cutting corners.

Myth

The purpose of the sprint is to deliver a working, potentially-releasable “Done” increment that accomplishes the Sprint Goal.

Fact

Yes, this is a “SMART” goal. This mnemonic is useful to Product Owners and teams when creating their Sprint Goal. See ap.tips/smart.

Fact

Yes, the Product Owner, Scrum Master, and Development team must work together to accomplish the Sprint Goal.

Myth

Only the Product Owner can formally decide to cancel the Sprint. They are most likely to do so when the Sprint Goal is no longer relevant.

Myth

Per Agile Principle #4 (ap.tips/principles), “Business people and developers must work together daily throughout the project.” It is all too easy for the Scrum Team to develop the wrong product based on a simple misunderstanding, even with comprehensive documentation.

Fact

The Development Team and Product Owner can collaborate to clarify and change the Sprint’s scope as more is learned, but the Sprint Goal should be preserved whenever possible.

Myth

Although a team conducting one-week sprints would have two Sprint Planning (ap.tips/planning), Sprint Review (ap.tips/review), and Sprint Retrospectives (ap.tips/retro), the Planning and Review events take about 40% less time for one-week sprints because there are fewer Backlog Items to plan and review with stakeholders and end users.

Myth

This is simply a traditional, phased-gated fixed planning approach delivered two weeks at a time. Even if it’s just a clickable prototype, try to start building something that you can get feedback on from stakeholders in your first sprint.

Fact

Exactly!

Myth

It typically takes 1–2 hours per week of Sprint duration to plan a sprint well. If the team cannot complete Sprint Planning within 2 hours per week of Sprint Duration, they should consider performing more Backlog Refinement in advance.

Myth

The entire Scrum Team should attend. We need the Product Owner to help craft a good Sprint Goal, clarify the work to be done, and answer questions about whether or not the planned approach is likely to satisfy the customer.

Fact

It’s not common as much of their feedback will come to the team at Sprint Review, but the Scrum Team is welcome to invite anyone who could help.

Fact

Holidays and voluntary time off most often occur on Mondays and Fridays, so you’ll wind up having to reschedule events more often or miss important participants.

Myth

The Product Owner should come to Sprint Planning with a prioritized Product Backlog, but only the Development Team can choose how many of those stories make it into the Sprint Backlog based on their historical performance whenever possible.

Myth

Absolute time-based estimates are usually less accurate and take longer to identify than relative estimates such as Story Points.

Fact

This is a very important but often overlooked part of Sprint Planning. Tasks are to “Engineering Requirement Documents (ERDs)” that Backlog Items are to “Project Requirement Documents (PRDs).” This discussion creates alignment about the anticipated approach and helps reduce risk.

Fact

Our attention span lasts about 60–90 minutes at best. Nobody can sit through a 2+ hour meeting and remain productive without a mental and “bio” break.

Myth

It’s far better to underpromise and overdeliver. If the team’s historical velocity and capacity suggests a forecasted velocity of 30 points this sprint and the team wants to take on 40, try to complete the 30 points early and pull in additional work mid-sprint.

Fact

This consistency makes things much easier. Some teams will cancel the Daily Scrum on the last day of the sprint, but we recommend against that as the team could use this to coordinate their final effort against the Sprint Goal.

Myth

While stakeholders and other subject matter experts may always attend, the goal of the Daily Scrum is to inspect and adapt progress against the Sprint Goal, not update stakeholders (including the Product Owner or Scrum Master).

Myth

The Scrum Guide suggests that the Daily Scrum is required for the Development Team. The Scrum Master need only ensure that it’s happening and well. On the other hand, most Agile coaches would suggest that the entire Scrum Team should attend and some even suggest that the Product Owner and Scrum Master give updates, too.

Fact

Fact

Distributed teams should consider scheduling more than 15 minutes for this event. The Daily Scrum itself is still time-boxed for 15 minutes, but it can be very useful to keep the video conferencing bridge reserved for “Parking Lot” topics. Distributed Scrum Team members are less likely to speak to one another informally throughout the rest of the day.

Fact

Within a few days, attendance should improve as being late to a meeting in progress is more uncomfortable than being late to a meeting that hasn’t started yet.

Fact

If any Scrum Team member feels that a discussion during the Daily Scrum is taking too long and threatens the time-box, they can suggest further discussion be held for the “Parking Lot.” Anyone who wishes to do so can stick around after the Daily Scrum and discuss these topics: participation is fully voluntary at this point. 

Fact

Fact

Exactly. This is not a status meeting. It’s an opportunity to inspect and adapt progress against the Sprint Goal.

Myth

While the Development Team has a great deal of autonomy over how the Sprint Backlog will be accomplished, they are accountable to the Scrum Team for staying focused on the activities that help the team meet the Sprint Goal. If they truly believe that they should be working on something, they owe the rest of their team transparency.

Myth

Remember Agile Principle #7: “Working software is the primary measure of progress.” If we take credit for partial work, we create the illusion of progress and often wind up starting a lot of work that we don’t finish.

Myth

While we certainly want to foster a culture of transparency and trust between the Scrum Team and stakeholders, we also need to elicit feedback on the Increment and collaboratively improve the Product Backlog together.

Fact

The Scrum Team should update the Product Backlog to reflect stakeholder feedback and new knowledge about the product’s context, such as the competitive landscape and the company’s resources.

Fact

Exactly. We want to be transparent with our stakeholders and show the true state of our work.

Fact

There’s little value to holding a Sprint Review if stakeholders aren’t present to provide feedback and the business context.

Myth

Don’t demonstrate incomplete Backlog Items at the Sprint Review. It creates the illusion of progress and confusion about what is and isn’t done. Your stakeholders might think something is ready to ship when it isn’t (e.g., looks feature complete but doesn’t pass tests) and ask that you put it into production.

Myth

It takes about 15-60 minutes to conduct Sprint Review per week of Sprint duration. 1 hour is about right for a 2-week sprint as you need time to demonstrate the work, solicit meaningful feedback, hear updates about the market, and share information about potential release timing.

Fact

This is one of the few times in a Sprint that the Scrum Team, stakeholders, and even end-users will all get together to inspect and adapt. Now that you’re together, take the time to collaborate on the release with one another.

Fact

It can be very helpful for stakeholders to hear about the challenges the team has faced. If a stakeholder hears about a tenacious systemic impediment from multiple teams, they are more likely to believe it exists and act upon it.

Myth

This is likely to demoralize the team and incentivize raw output of features over quality. If stakeholders have concerns about the scope of work delivered, they should bring it up with the Scrum Master and/or Product Owner individually.

Myth

It really does take about 1½ hours to have a meaningful retrospective for a two-week sprint. Cutting Sprint Retrospective too short significantly impacts the team’s ability to inspect, learn, and adapt and impedes continuous improvement.

Myth

Only members of the Scrum Team may attend unless there is consensus from the team that others should be invited.

Fact

As Norm Kerth says in his Retrospective Prime Directive, “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” If someone made a mistake, it’s probably because the context they were operating in made it likely. This helps us address the most likely root cause of our challenges.

Fact

Asking why five times helps us get at the root cause. Considering “tools, process, structure, culture” also helps: for instance, are we managing dependencies (process) when we could be eliminating them (structure)?

Myth

Retrospectives are the most important event because they allow us to consider and improve how we are working together. If we do not retrospect, we are not truly in control of our tools, process, structure, or culture.

Fact

Some Scrum Masters and coaches call new Backlog Items “actions” and changes to the Definition of Done, Definition of Ready, and Working Agreement “decisions.”

Fact

The Scrum Team should consider The Scrum Team’s progress against the Sprint Goal and Sprint Backlog, the well-being of the people and relationships in and around the Scrum Team, and the effectiveness of the Scrum Team’s tools, process, structure, and culture.

Fact

It’s ideal to inspect and adapt before Sprint Planning so that we can incorporate Backlog Items related to continuous improvement in our next Sprint. However, every Scrum event is an opportunity to inspect and adapt!

Fact

Having celebratory snacks can really break the ice and create a friendly and supportive atmosphere, even if you are working remotely. The Scrum Master should occasionally change the format of the Retrospective to bring in new kinds of perspectives and help prevent it from becoming a rote exercise.

Myth

Although many Scrum Masters and Agile Coaches teach that Backlog Refinement is an event—and it can be quite effective to treat it as one—it’s not officially an event in the Scrum Guide. The Product Owner and Development Team can refine the backlog any way they like and still be true to “textbook” Scrum.

Fact

Getting together to talk about the work we expect to complete together is a very good use of time. Every minute spent in the Backlog Refinement activity is at least a minute saved at Sprint Planning, especially because it allows the Scrum Team to get crucial answers from stakeholders and subject matter experts who may not be present before Sprint Planning.

Fact

Yep! Although Sprint Planning is the last responsible moment to detail, improve, estimate, and prioritize, doing so early makes the team much more effective and reduces risk.

Myth

Although getting together as a Scrum Team can significantly improve shared understanding of the work, there is no strict requirement for everyone to participate.

Fact

Whomever created the Backlog Item should make a sincere effort to elaborate on it before bringing it to the rest of the team for discussion. They should not expect it to survive discussion unchanged, but a little preparation goes a long way.

Fact

Although the Definition of Ready isn’t an official Scrum concept, it is useful to at least agree that the Backlog Item can be completed within one Sprint.

Fact

This allows the Scrum Team to read ahead and familiarize themselves with their description, order, and value. It also helps communicate the full scope of the Backlog Refinement event to encourage brevity. If the Scrum Team gets these stories to “Ready” early it can end the event early.

Fact

The Scrum Team can invite anyone they like. It can also be useful for a Product Owner to review proposed backlog items with customers before bringing them to the Development Team.

Fact

Unless the team has a very stable velocity and estimates the work during Backlog Refinement, there’s always the risk of the team being able to pull more work into the Sprint at Sprint Planning than the Product Owner has prepared. On the other hand, you don’t want to spend time detailing work too far into the future as you may discover the work isn’t important or your user’s needs were different than you thought.

Myth

Creating a smooth flow of work is only half of the benefit we can get from estimating user stories. Suppose the developer suggesting a “1” has discovered a faster way to accomplish the work, or the developer suggesting a “5” is aware of a sticky edge case. If you differ much in your estimates, explain why and revote for another round or two until you converge.