## Introduction

The number of myths around [Scrum](/blog/first-steps-to-learn-scrum/) is still growing. Let’s be honest, frameworks or methodologies that use  [Scrum](/blog/first-steps-to-learn-scrum/) terms incorrectly do not help.

Today I would like to list the most common  [Scrum](/blog/first-steps-to-learn-scrum/) myths that I’ve seen in my career. I know that these myths have been constantly repeated and passed from company to company. But as you know, this blog is about education, so I want to debunk these myths. 

## Myth 1 - Scrum is just about Scrum events and roles

Many organizations decide to implement  [Scrum](/blog/first-steps-to-learn-scrum/), but they **end up only using roles, events & sometimes artifacts**. 

What is the result? They focus only on the way how to change processes or the way of working without really using [Scrum values](/blog/the-importance-of-scrum-values/) & **empirical approach principles**. This behavior is called: **"Mechanical Scrum"** and doesn’t work well in the long term. 

To be honest, [Scrum](/blog/first-steps-to-learn-scrum/) is much more about **changing the mindset and empowering teams** than anything else. I am not saying that events and roles don’t really matter, but they will not work without proper mindset and values. 
Implementing  [Scrum](/blog/first-steps-to-learn-scrum/) is the same like building the house, you need to have the proper **foundations**. 

## Myth 2 - Daily Scrum is a status report meeting

[Daily Scrum](/blog/scrum-events-3-daily-scrum/) is frequently misused by the [Scrum](/blog/first-steps-to-learn-scrum/) Teams as a **status report meeting** where individuals mention what they did, what they plan to do and what are their impediments.
You can ask - "Wait, but what is wrong with that? Aren’t these just the examples of the questions listed in the Scrum Guide version from 2017?"

The answer is - "Nope". There is one really important part missing here - the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it/). The [Sprint Goal](/blog/sprint-goal-why-do-we-need-it/) is frequently treated by Scrum Teams as an unwanted element.They either don’t have one or they have multiple, so they don’t really use them.

What does [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html#daily-scrum) say about [Daily Scrum](/blog/scrum-events-3-daily-scrum/)?

> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

[Daily Scrum](/blog/scrum-events-3-daily-scrum/) is not about **discussing the status** of individuals’ work. It should be time when Developers discuss **their progress toward the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it/)** and **create their plan for the next day of work**.

Again, it’s about their plan **collectively** as a group of people who want to achieve the same goal. When we focus only on individuals, this element of **teamwork** can be easily lost and it prevents them from collaboration.

![Status report](img/status_report.jpg "Status report")

## Myth 3 - Agile means Scrum

It is a common mistake that people use terms **Agile & Scrum interchangeably**. There is no point to blame anyone, because it can be really confusing to remember all **Scrum** related terms plus using **"Agile"** term has been popular and fancy recently.

Let me make this one straight:

* Term **"Agile"** has been used in [“Manifesto for Agile Software Development”](https://agilemanifesto.org/) created in 2001. It reflects the **set of values & principles** that people who wrote manifesto wanted to promote in software development. Nowadays Agile is way above software development.  It remains a **philosophy** that can be used in many fields & industries. 
* **[Scrum](/blog/first-steps-to-learn-scrum/) is a framework** dedicated for generating value in a **complex** environment. Term [Scrum](/blog/first-steps-to-learn-scrum/) was used first time in 1986 and popularized in the early 1990s by Ken Schwaber and Jeff Sutherland.

**These terms are not the same.**

[Scrum](/blog/first-steps-to-learn-scrum/) can be recognized as one of the **Agile practices**. I really like using the below visual representation of the [relationship between Agile & Scrum](/blog/relationship-between-scrum-and-agile/). I hope it will help you to understand the difference. 

![Agile mindset vs Agile practices](img/Agile.png "Agile mindset vs Agile practices")

Source: https://www.agilesherpas.com/agile-mindset-marketing-agility/

## Myth 4 - Sprint Review is just a demo

Another common myth is treating [Sprint Review](/blog//scrum-events-4-sprint-review/) as **just a demo** of the work that was accomplished during the [Sprint](/blog/scrum-events-1-the-sprint/). Of course we want to show what was done, but that’s not the only purpose of this event.

What can we read in the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-review) about it?

> The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
>
> During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.

[Sprint Review](/blog/scrum-events-4-sprint-review/) is another opportunity for **inspection**, but also a really important moment in the [Sprint](/blog/scrum-events-1-the-sprint/) when the **Scrum Team can collaborate with stakeholders** and get their **feedback**. We don’t want to just show whatever was done and move on to the next [Sprint](/blog/scrum-events-1-the-sprint/).

It should be a moment to **stop, reflect** on what was done. We want to **adjust the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/)** based on stakeholders’ feedback and discuss the future direction. 

## Myth 5 - Scrum Master doesn’t do anything

This one is the most painful myth for me as a [Scrum Master](/blog/scrum-roles-3-scrum-master/), because I know how many things that [Scrum Master](/blog/scrum-roles-3-scrum-master/) does are **invisible** and do **not recognized** by people.

Of course there are people out there who don’t do their job well and maybe they really don’t do anything. But to be honest the [successful Scrum Master](/blog/secrets-of-the-successful-scrum-master/) **shouldn’t be really too shiny and loud**.

There are so many small steps that need to be done by SM everyday that simply **will not be visible** for people if they don’t know about them. I am talking about **asking the right questions**, **talking** to individuals, **coaching** Product Owner, **searching** for new techniques that can help the team, **analysing** behaviours, preparing for workshops and so on.

I hope I made it clear enough, [Scrum Master](/blog/scrum-roles-3-scrum-master/) is not just drinking coffee and chatting. Although a lot of coffee & talking to many people is part of that role. :D 

![Coffee](img/coffee.jpg "Coffeee")

## Summary

If you believed in any of the above myths, I hope this post helped you to learn something new today.

* [Scrum](/blog/first-steps-to-learn-scrum/) is a framework is not just about events & roles.
* [Daily Scrum](/blog/scrum-events-3-daily-scrum/) is not really a status report meeting.
* [Sprint Review](/blog/scrum-events-4-sprint-review/) doesn’t mean only demo.
* Agile doesn’t equal [Scrum]([Scrum](/blog/first-steps-to-learn-scrum/).
* [Scrum Master](/blog/scrum-roles-3-scrum-master/) does more than drinking coffee.

Do you know any other interesting Scrum myths? Feel free to share them here or in Let's Scrum it on social media.



Is Agile the same as Scrum? Have you ever thought that Daily Scrum is the status meeting and Sprint Review means demo? These are some of the Scrum myths I debunk in this article. Check it out!

5 Common Scrum Myths

## Introduction

Few weeks ago I started a series of posts dedicated to Scrum Events.I’ve already described the [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/), [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) and [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/).  In this post I would like to tell you more about Sprint Review. 

![Sprint-Review](img/sprint_review.png)

## Definition and length

To understand the Sprint Review, we need to start from the definition in the Scrum Guide:

>A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. 

Inspection and adaptation are two of the three pillars of **Empiricism** (third one is transparency) which is the foundation of the Scrum. In empirical process control, knowledge comes from experience and that’s exactly what is happening during the Sprint Review. 
Scrum Team together with all stakeholders inspect the increment and decide what should be done next. 

Maximum duration of the Sprint Review is **four hours** for one-month Sprint. Scrum Master needs to make sure that event takes place and all attendees are aware of the purpose and keep time limits. 

If we continue the analogy to running, Sprint Review is like the finishing line. It is the moment when we verify how fast we were running, celebrate success and then based on this we can plan our running techniques for the next race. 

![Finising-Line](img/finishline.jpg)

## Collaboration

One of the most important parts of Agile mindset is collaboration - with clients, development team and business. In my post [The Relationship between Scrum and Agile](https://letsscrumit.com/relationship-between-scrum-and-agile/) you can read more about Agile and why it is strictly related to Scrum. 

Sprint Review is focused on the collaboration of all stakeholders and Scrum Team.  In the traditional product development the final result/product is presented to stakeholders at the end of the project. If it is a complex product it can take months or even years. 

In Scrum, Ken Schwaber and Jeff Sutherland proposed different approach: 
* Frequent delivery of the increment (not fully completed product).  

* Collecting the stakeholders’ feedback during development of the product. 

* Collaboration with all of them to optimize the value.

Collaboration with the customer is necessary to satisfy them and fulfill their needs. Moreover it saves a lot of Development Team’s time, because they know the direction of the development and they adjust their work if needed. I believe that this approach is much more effective and valuable than traditional development of the products.

![Collaboration](img/collaboration.jpg)

## Done & not Done work explained

Sprint Review is the time for the Product Owner to explain what has been "Done" during the Sprint and what has not been "Done".  The Development Team should demonstrate "Done" work and answer all stakeholders’ questions about the increment. That’s the moment for stakeholders to play around with the product and check if all their needs and priorities are fulfilled. 

It is important to mention that the Development Team should make sure that they present only "Done" work using the definition that they agreed for. 

The Sprint Review event is also time for discussion about positive aspects of the Sprint (successes), issues that appeared and how they were solved. It can be a great opportunity to discuss communication between stakeholders and the Scrum Team and find the best solutions.

![Done](img/Done.jpg)

## Product Backlog - now & the future

Product Owner presents the current status of the Product Backlog and gives the estimation of delivery based on the team velocity. It’s important to mention that it is just the prediction, not fixed dates. Specific plans for each Sprint are created by the Scrum Team during the [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) session.

All stakeholders and the Scrum Team should collaborate about priorities for the upcoming Sprint. They can be related to change in the marketplace or business strategy. It is important to analyze and decide what will deliver the maximum value to the business.

The outcome of the Sprint Review should be the revised Product Backlog that will include prioritized work items for the next Sprint. It will be used by the Scrum Team in the next [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) meeting. 
![Direction](img/direction.jpg)

## Summary

The most important information about Sprint Review meeting: 
* The maximum duration of the meeting is 4 hours for one month Sprint. 

* Participants: Scrum Team and stakeholders invited by Product Owner. 

* Collaboration is a crucial part of the meeting. It is time for collection of feedback and understanding stakeholders’ needs. 

* The Product Owner should explain what was "Done" and not "Done" during the Sprint. - The Development Team demonstrates "Done" Increment. 

* It is also time for discussion about positive and negative aspects of the Sprint in order to create the best solution for the future.

* During Sprint Review Product Backlog should be presented by the Product Owner with the estimated plan for the future.  

* All participants should collaborate to decide about work priorities and the direction for the next Sprint.

Sprint Review is a great tool for Scrum Team that helps to verify if stakeholders are happy about the increment and what is the most important work that needs to be included in the next iteration. This knowledge helps to plan the work and deliver business value. 

Are you at the end of the Sprint wondering what should happen next? It's time for Sprint Review meeting! Here you can find more details about it.

2 posts tagged with #sprint review