## Introduction

In my last 2 posts from Scrum Roles series I explained who is the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) and the [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/).

Today I would like to tell you more about the role of Scrum Master that is close to my heart, because I act as the Scrum Master in the Scrum Team. 

![Scrum-Master](img/scrummaster.png)

## Who is the Scrum Master?

Before we will start analyzing deeply the role, let’s check what Scrum Guide says about it:

> The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The most important responsibility of the Scrum Master role is to help everyone in understanding and using the Scrum framework. This will maximize the value created by the Scrum Team and will help them to build high-performance culture. 

It can sound simple, but there are a lot of skills and actions required from the Scrum Master in order to achieve the above. 

## Scrum Master - servant leader

One of the important things to remember is that: > The Scrum Master is a servant-leader for the Scrum Team. 

It is definitely not the traditional project manager, but the leader who serves the Team and helps them to understand what Scrum is and how they can use it on a daily basis. 
Scrum Master should serve the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/), [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/) and the Organization.  

As a servant leader Scrum Master is responsible for: 
* Removing all impediments during development process 

* Helping to create collaborative and safe culture within the Scrum Team and organization - Finding and proposing new solutions that will help in more efficient development of the product  

* Understanding Scrum Team and organization needs and how they can be fulfilled using an agile approach.

![Servant-Leader](img/servant_leader.jpg)

## Scrum Master - teacher & coach

When I was a young girl, I wanted to become a teacher. What is more, I have even a degree in Early Childhood Education, because teaching others and helping them to grow was always my passion.  After a lot of adventures and changes in my life I become a Scrum Master and I believe that my teaching skills are really useful in this role. 

Scrum Master needs to use coaching skills and teach all below on a daily basis. 

#### Product Owner

*  Clear expression of the business goals, scope and the purpose of the product

* Product Backlog management by finding more effective ways and techniques. This includes making sure that Product Backlog items are clear and understandable for everyone. It should be explained and arranged the way that will maximize the value of the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) work. 

* Understand and practice agility and empirical approach in all Scrum activities.

#### Development Team:
* Self-organization and cross- functionality that are crucial part of their growth

* Understand the purpose of the Scrum and practicing it in an agile way on a daily basis

* Create high-value products 

* Resolve conflicts and discuss issues when they appear.

#### The Organization:

* How Scrum can be adopted and what is required from the Organization

* The value of the Scrum in organization and what does it mean to use empirical process in development of the product

* Plan Scrum implementations, cooperate with other Scrum Masters to increase effectiveness in Scrum adoption in organization

* How Organization should interact with the Scrum Team and what will increase the productivity and what won’t.

![Teacher](img/teacher.jpg) 

## Scrum Master - Facilitator

Scrum framework consists of events that increase communication and effectiveness within the team like : [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/), [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/), [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/), [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and [Sprint Retrospective](https://letsscrumit.com/scrum-events-5-sprint-retrospective/).

Scrum Master needs to facilitate some of these events if it is requested or needed. He or she also needs to make sure that events are organized and the team doesn’t exceed the maximum time dedicated for each event. 

Scrum Master should listen to the team’s discussion and issues they are struggling with and ask the right questions in the right moment.  I would say that one of the most important, but also difficult skills for the Scrum Master is taking the step back and creating space for the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) to express their ideas and solutions. 

A lot of Scrum Masters who transformed from the traditional project management approach would like to propose the solution right away instead of giving the freedom to the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) to find it by themselves. 

The only way to help the team to be self-organized is to trust them and allow them to make their own decisions and mistakes. This empirical process is the best way to learn and grow. 

![Facilitator](img/facilitator.jpg)

## Summary

* Scrum Master is the role in Scrum Team who **promotes Scrum** and **helps** everyone to **understand** and **practice** it on a daily basis.

* He or she should be the **servant - leader** who supports [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/), [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) and the Organization in their Scrum journey. 

* Scrum Master is responsible for **helping [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/) in Product Backlog management** and making sure that everyone in the Scrum Team understands it.

* The [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) should be **coached** by the Scrum Master how to become a **self-organized and cross-functional team** and deliver the high value products. Scrum Master needs to support them and promote an agile and collaborative approach. 

* Scrum Master has multiple functions such as: **servant-leader, teacher, coach, facilitator** and more depending on what is needed. She or he needs to be the person who adapts to change quickly and helps everyone else to do it. 

Would you like to know who is the Scrum Master? What is her or his role in the Scrum Team?

Scrum Roles #3 Scrum Master

## Introduction

As I mentioned in my last [post](https://letsscrumit.com/scrum-roles-1-development-team/), Scrum Team consists of the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/), Product Owner and Scrum Master.  I’ve already described the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) and today I would like to tell you more about the **Product Owner**. 

## Who is the Product Owner

Let’s check what Scrum Guide says about it: > The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

This is important information - Product Owner is **one individual**, not a group of people. Why?  The reason is simple - multiple people mean multiple decisions, visions and increased complexity. 

![Product-Owner](img/productowner.jpeg)

## What is the Product Owner responsible for?

Based on the Scrum Guide:

> The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Ok, you may ask now - "What does it mean maximizing value?" 

First of all, a Product Owner needs to have a deep understanding of the product. Based on the knowledge about the product, he or she can decide what direction of the development will be the most valuable. It can be done based on the market situation, company strategy or analysis of the customer needs. As it was described in the Scrum Guide, it can vary across companies. 

The simple example from real life: the Product Owner receives the request from the higher management in the company that they want to implement some additional product functionality urgently. 

Before the Product Owner makes any decisions, he or she needs to analyze all implications related to technical aspects, impediments, customer needs etc.  Based on the analysis the Product Owner decides if the new action will be valuable for the product or not. 

## Product Owner & Product Backlog

As we can read in the Scrum Guide:

> The Product Owner is the sole person responsible for managing the Product Backlog. 

If you don’t know the Scrum yet, you may ask - "What is the Product Backlog?"  It is a list of everything that is required, needed in the product. 
The Product Owner is responsible for creating this list of work items called "Product Backlog items" and managing it. 

![Product-backlog](img/backlog.jpg)

**How can the Product Owner manage the Product Backlog?**
* All Product Backlog items should be clear and understandable for everyone in the Development Team. The most priority items should be fully explained to allow the team to plan their work accordingly.

* Product Backlog should be visible to everyone in the Scrum Team to make sure all requirements and vision of the product are transparent.

* Items need to be ordered by PO based on the business goals and strategy. The most important and priority work should be on the top of the Product Backlog.

* During management of the Product Backlog PO should consider work required from the Development Team and decide how to optimize the value of their work.

Some of the above responsibilities can be done by different people (selected by PO), but the Product Owner remains accountable in terms of the Product Backlog management.

## Product Owner - other responsibilities

The Product Owner is the only person who has authority to cancel the [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/). It is a really rare case, but this decision can be made by the Product Owner due to technology or market changes.

The Product Owner is also the main link between business and the Development Team. She or he needs to fully understand business needs and clearly express them to the team. 

In Scrum there is one event facilitated mostly by the Product Owner - [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/): 
* All key stakeholders need to be invited by the PO to the meeting. He or she needs to explain what Product Backlog items were "Done" during the Sprint and what is the current status of the Product Backlog.

* Together with all stakeholders and other members of the Scrum Team, the Product Owner analyzes the marketplace, budget and potential timeline.

  
![Stakeholders](img/stakeholders.jpg)

## Product Owner & Sprint Backlog

The Product Owner is responsible for Product Backlog, but what about **Sprint Backlog**?  Sprint Backlog is created during [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) and includes items selected from the Product Backlog for the new [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/).

The difference between **Product Backlog** and **Sprint Backlog** is that the first one is managed and can be changed by the Product Owner, while the other one belongs solely to the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/).  It means that the Product Owner cannot update it in the Sprint or add anything. The Development Team can change it and renegotiate selected items with the Product Owner if it’s needed. 

Moreover, the Product Owner plays the important role in **clarification of the Product Backlog Items**. If the Development Team has any concerns related to items selected for the Sprint, the Product Owner should help them and explain all unclear details.

## Summary

To sum up the Product Owner’s role, it is **one person** who makes sure that all the actions within the Sprint are **maximizing value of the product**. 

The Product Owner needs to be the **link between all stakeholders and the Development Team**. She or he should know deeply the product, business needs and marketplace in order to achieve the best results during the product development process. 

The main responsibility of the Product Owner is the **Product Backlog management** including ordering, clarification of items and optimizing the Development Team’s work. 

Who is the Product Owner? What are her or his responsibilities? Read this post to find out more about this Scrum Role.

Scrum Roles #2 Product Owner

## Introdution

Last month, I explained to you in detail all Scrum Events: [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/), [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/), [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/), [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and [Sprint Retrospective](https://letsscrumit.com/scrum-events-5-sprint-retrospective/).

Today, I would like to start a new series about **Scrum Roles**. You probably think that you can read about Scrum Events and Roles in the Scrum Guide and there is no need to write posts about them. But I believe that practical knowledge and deep explanation of terms used in the Scrum Guide is important to understand the Scrum framework. 

First posts on this blog are written to create the foundation for all interesting discussions about Scrum and Agile. Without solid basics this framework doesn’t work properly.

![Scrum_Team](img/scrumteam.PNG)

## Scrum Team

To explain the Development Team role, I need to start from the broad context.  In the Scrum all roles are part of the Scrum Team.  Based on the Scrum Guide:

> The Scrum Team consists of a **Product Owner**, **the Development Team**, and a **Scrum Master**. Scrum Teams are self-organizing and cross-functional. 

## Self-organizing?

Oh wait! Don’t they need any manager? Yes, that’s right. Self-organizing team doesn’t need to be managed by someone outside the team.  The team knows the best way to organize and accomplish their work. 

## Cross-functional?

What does it mean? It means that together in a team, they have all skills required to do the work. They don’t need to depend on others who are not part of the team. 
To make their work even more effective, the Development Team should aim for spreading the knowledge in the team. It can be achieved by practices like pair programming, learning at lunch events or changing the facilitator on each Scrum Event.
The above attributes of the Scrum Team increase productivity and flexibility of the team. What is more, Scrum Team inspired by their own autonomy is more creative and delivering complex products is much easier for them. 


## Who is part of the Development Team?

Great, we know that the Development Team is one of the roles in the Scrum Team.  Let’s check in the Scrum Guide who is part of the Development Team:

> The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint.

In the Development Team you can find everyone who gets product development work done. I will list examples from software development, but remember that Scrum can be used in any other industry. 

If we develop software products, Development Team can consists experts in:
* Software Engineering
* Designing
* Testing
* Software Architecture
* Business Analysis
* And everything else what is required to get things done.

![Development_Team](img/developmentteam.PNG)

## What is the size of the Development Team?

Based on the Scrum Guide:

> Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

Size of the Development Team should be from **3 to 9 people**. Smaller teams will be less productive and they can struggle with delivering the increment. On the other hand, a bigger team increases complexity what can cause communication and collaboration issues. 
Scrum Master and Product Owner are not part of the Development Team unless they also do the work from the Sprint Backlog.

## What are the atributes of the Development Team

The Development Team as a part of the Scrum Team needs to be **self-organized** and **cross-functional**.  They decide what is included in the Sprint Backlog and how they will achieve the [Sprint Goal](https://letsscrumit.com/sprint-goal-why-do-we-need-it/) that they planned.

The most important for the team is **delivery of the releasable increment of "Done"** product at the end of each Sprint. They create the definition of "Done" and decide how it will be verified. 

The Development Team should **consist of people with the right skills** to be able to effectively organize their own work and deliver the product increment.
 
Based on the Scrum Guide:
> Individual Development Team members may have specialized skills and areas of focus, but **accountability belongs to the Development Team as a whole**.

It is crucial for the team to remember about and support each other and collaborate effectively in order to achieve their goals.

![Attributes](img/attributes.jpg)

## Titles and sub-teams in the Development Team

Based on the Scrum Guide:
> - Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person
> - Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

**What does it mean in reality?**

It means that the Development Team should work together without anything like titles or sub-team what could divide them.  During [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) they need to estimate work considering all skills and knowledge in the team.  If there are less experienced people in the team, others should teach them and help to develop all necessary skills. 

## Responsibilities of Development Team

What is the Development Team Responsible for? 
* Getting things **Done**

* Development of releasable **increment** of product

* **Planning** their work on the [Sprint Planning meeting](https://letsscrumit.com/scrum-events-2-sprint-planning/)

* **Sprint Backlog** - it can be adjusted after agreement between Development Team and Product Owner

* Achievement of the [Sprint Goal](https://letsscrumit.com/sprint-goal-why-do-we-need-it/) planned for the Sprint

* Managing their work daily, planning and **inspection** during [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/)

* Demonstration of **"Done"** work during [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/)

* **Analyzing** their work, relationships and processes during [Sprint Retrospective](https://letsscrumit.com/scrum-events-5-sprint-retrospective/). They need to inspect and adapt if needed

* **Continues improvement** of their work and processes.

![Responsibilities](img/responsibilities.jpg)

## Summary 

To summarize, the Development Team is responsible for **"Done"** work in the Sprint and "How" it will be done. As a **self-organizing** and **cross-functional** team, they find the best solutions to deliver the product effectively. They **inspect** their work and **adapt** to achieve better results, but also to increase creativity in the team. 

They need to be **transparent** in all their actions to build **trust** and **respect** in the team and create a safe environment for every team member.

Would you like to know who is in the Development Team and what are respnsibilities of the team? Check out this post to find out more.

Scrum Roles #1 Development Team

## Introduction

In my last posts you’ve learned about:
- [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/)
- [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/)
- [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/) and
- [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/)

Today I would like to describe the last event in the Scrum Events series - Sprint Retrospective.

## Definition and length

Definition in the Scrum Guide:

> The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

As you can see, this event similarly to [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) is focused on the inspection. The main difference between [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and Retrospective is a subject. [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) is about review and inspection of the **increment**, while Sprint Retrospective is dedicated to inspection of the **Scrum Team itself**.

Regarding length and occurence of the event, based on the Scrum Guide:

> The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

**Who should attend the event?**

**Scrum Team** - Development Team, Product Owner and Scrum Master. Scrum Master needs to make sure that event is organized and everyone understands the purpose.
Before we jump into the purpose, let’s find the Sprint Retrospective in the running analogy that I used in the whole series. I believe that Sprint Retrospective is like the moment when you finish sprinting and you start analyzing your behaviour, speed and everything else that could impact your running. Before you will start preparing for the next run, you want to know what was working for you and what should be adjusted to perform better.

![Analysis](img/analysis.jpg)

## Purpose

Following the Scrum Guide:

> The purpose of the Sprint Retrospective is to:
> - Inspect how the last Sprint went with regards to people, relationships, process, and tools;
> - Identify and order the major items that went well and potential improvements; and,
> - Create a plan for implementing improvements to the way the Scrum Team does its work.

Sprint Retrospective gives the opportunity for the Scrum Team to observe their actions and learn from experience. It’s time when they can analyze:
* What went well during the Sprint? - What they didn’t like and should be improved? - What solutions can be implemented to make their work more effective?

Scrum Master should encourage the Team to improve processes and practices to make their work more fun and effective. The continuous improvement is the important part of the Scrum. Making changes and adapting to the current situation is necessary in order to increase product quality. In my opinion it is also crucial for the team and personal development of each team member.

What is the main purpose of the Sprint Retrospective in my opinion? I believe it is an honest discussion about the Sprint and ideas for improvement. I would like to emphasize how important transparency and honesty are during that meeting. It is not possible to make real improvement without honest opinions of team members.

## Celebration
Let me describe the main 3 parts of the Sprint Retrospective.

First of all this event is a great opportunity to celebrate successes and remind all positive aspects of the Sprint. It’s perfect time to appreciate what other team members did and how they did it. This approach helps to build a motivated and collaborative team.
People keep forgetting about positive aspects of their lives and have a tendency to focus on the negative situations. Without knowledge about successes and good solutions, the Scrum Team cannot keep growing. They need to know what is working for them and what they would like to continue doing.

![Celebration](img/celebration.jpg)

## 2) Did not go well

After discussion about positive aspects of the Sprint is time to face with everything that didn't go well. The important part is to create the safety space for team members to express what they think. The only way to achieve it, is creation of a blame-free and full of trust environment.

Let’s remember that during Sprint Retrospective, team members don’t focus only on their work. It’s time for discussion also about relationships or conflicts if they appeared. I would say that is the most challenging bit that they can struggle with. Talking about processes and tools is much easier than telling someone that we didn’t like their behavior or attitude. During this kind of discussion the Scrum Team needs to remember about respect to everyone and openness to feedback.

## Improvements & ideas

Once the major items that didn’t go well are identified, the Scrum Team should try to find the best improvements that can be implemented. That’s a time for brainstorming and sharing all ideas with the team. Team members don’t need to focus on the solutions for the existing issues, but they can suggest any ideas that will make their work and relationships better.
If it’s possible, they can adjust Definition of Done considering the organizational standards and processes.

When all improvements are listed, the Scrum Team needs to decide what will be implemented in the next Sprint and they should include them in the Sprint Backlog.

![Ideas](img/ideas.jpg)

## Summary

There are a lot of examples how Sprint Retrospective can be facilitated. I didn’t include them here, because I wanted to start from describing the main idea and purpose of the meeting first. I will definitely write a post fully focused on the retrospective ideas.

The most important information about Sprint Retrospective:
* It’s an event focused on inspection and adaptation of the Scrum Team itself.

* Time: 3 hours for the one month Sprint.

* When is it happening? After [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and before the next [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/).

* The purpose: inspect what went well, what didn’t go well and what should be improved in regards to people, relationships, processes and tools.

* It’s an opportunity to celebrate successes and appreciate others' work.

* Discussion about items that didn’t go well should be done without blaming others, but with openness, trust and respect to everyone.

* During Sprint Retrospective, the Scrum Team should try to find the best solutions to solve their issues and improvements that will make their work and relationships better.

Let’s talk about my favourite and last Scrum Event - Sprint Retrospective. I described when it is happening and what is the purpose of that event.

Scrum Events #5 Sprint Retrospective

## 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.

Scrum Events #4 Sprint Review

## Introduction

In my last 2 posts from Scrum Events series I described what is [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/) and [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/). Today I would like to focus on the event that can be easily forgotten or incorrectly transformed into a status meeting.
 
It’s time to talk about **Daily Scrum**.

![Daily-Scrum](img/Daily_scrum_1.png)

## Definition and length

Let’s start from definition of the Daily Scrum written in the **Scrum Guide** : 

> The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.

First of all, the same as all events in Scrum, Daily Scrum is time-boxed. The maximum duration of the event is 15 minutes. The meeting should be organized daily at the same time and place to reduce complexity and to help the Development Team get into the habit of this daily activity.

## Inspection, not a status meeting

Continuing the analogy to running, Daily Scrum is like a line that is showing you the distance to the final destination. It is a great tool that helps you to inspect how far away you are. Sometimes it can motivate you to run faster or change your previous running technique. 

Daily Scrum is the event dedicated for inspection of how far the Development Team is from achieving the Sprint Goal. It is verification if they are on the right track or they need to somehow adjust the work. 

I would like to highlight that this event is for the Development Team to inspect their work, not for anyone else. They work together to accomplish what they planned as a self-organized team.  Scrum Master should make sure that event is happening and make sure that the event is not disrupted by anyone else.  It’s important to remember that Daily Scrum is not the status meeting for Product Owner or anyone else. 

![Inspection](img/inspect.jpg)

## Mustical 3 questions?

In the Scrum Guide there is an example of 3 questions that Development Team can answer during the Daily Scrum event: 

> - What did I do yesterday that helped the Development Team meet the Sprint Goal?
> - What will I do today to help the Development Team meet the Sprint Goal?
> - Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Let’s remember that it is just the guidance. Some teams can prefer discussion - based meetings. The most important for them is to inspect progress towards the Sprint Goal and plan work for the next 24 hours. How will they do it? It’s up to them and that’s why it’s mentioned in the Scrum Guide that 3 questions are just “an example”. 

## Sprint Goal - again?
I’ve already mentioned and described why **Sprint Goal** is an important part of the Scrum in my post [Sprint Goal in Scrum - why do we need it?](https://letsscrumit.com/sprint-goal-why-do-we-need-it/)

The main purpose of the Daily Scrum event is to discuss progress towards the Sprint Goal. I will probably sound like a broken record, but I need to emphasise Sprint Goal’s value in the event.

It is important to mention it, because the Development Team has a tendency to forget about the Sprint Goal and discuss **all work** done a day before and planned for the next 24 hours, even if it wasn’t related to the goal. It can obviously impact the length of the meeting and result in forgetting **why** the team did the work that they did.  I believe that reminding yourself **why** you are doing your work and what is your goal helps you to stay motivated and focused. 

The simple but really useful for Development Team can be a visual representation of the Sprint Goal on their Scrum board or anything else that they are using for daily inspection. It will be a reminder for them to always refer to the progress towards the Sprint Goal.

![Sprint-Gaol](img/goal.jpg)

## Too long Daily Scrum

One of the most common issues related to the Daily Scrum is extending the 15 minutes length.  First of all, Scrum Master should teach the Development Team to keep the meeting within the time frame. It can be challenging, especially with a talkative team. :D 

There are simple tricks that can help in keeping the meeting within 15 minutes time-box: 
* **Focus on the Sprint Goal** - talk only about the work related to the Sprint Goal, not everything what you did or plan to do

* **No technical details** - do not explain technical details of your work or impediments

* **Detailed discussions saved for later** - if there is a need to discuss some issues or plans in detail, it should be done after Daily Scrum. It will definitely save time for people who will not be involved in the discussed subject.

* **Set up time per person** - depending on the size, the Development Team can set up the maximum time for talking per each person. They can even use a timer to count it.

* **Stand up during the meeting** - it is easier to keep the meeting short if people do not sit down. 

## Value of the Daily Scrum

As a Scrum Master, when I hear the question: "Can we skip the Daily Scrum? We have nothing to talk about.", I know that it is the time to step in and something is wrong.  It is important to teach the Development Team, what is the value of Daily Scrum and how it can be beneficial for them. 

* **Inspection and Adaptation** - it is time for the team to inspect their work and adapt if there is a need for change. They can track if they are progressing towards the Sprint Goal or not. As soon as the team forgets about the Sprint Goal, they lose track of why they are doing their work. That’s why they don’t know what to talk about during the meeting.

* **Communication** - quick discussion about progress of a team improves communication and helps the Development Team to be on the same page in regards to what needs to be done and what issues they are struggling with.  Eliminate other meetings - Team knows what is the plan for the next 24 hours and there is no need for other long, time-consuming meetings.

* **Quick fix** - Daily Scrum promotes removing impediments as soon as possible. Early recognition of issues can help in finding the quick solution. 

* **Team support** - Daily Scrum is a reminder for the Development Team that all individual’s actions impact the team, but the team can be supportive and helpful in resolving any issues. The most important is to collaboratively strive to achieve the Sprint Goal. 

![Values](img/team.jpg)

## Summary
The most important information about Daily Scrum to remember are:
* It is a 15 minutes time-boxed event that happens daily.

* It is an internal meeting for the Development Team.

* Daily Scrum is the inspection event, not a status meeting.

* During the meeting, the team should inspect the progress towards the Sprint Goal and adapt to the situation (change their actions) if needed.
Sprint Goal helps the team to realize why they are doing their work.

* The Development Team should keep the 15 minutes time frame. 

* The Scrum Master role is to make sure that the team has a meeting and they do not extend 15 minutes.

* Daily Scrum benefits are: better communication, no need for other meetings, quick fix of issues and support of the team.

I hope my explanation of the Daily Scrum helped you to understand the purpose and value of that event. Feel free to share your thoughts about it on LinkedIn or Twitter!

Are you wondering what is the purpose of the Daily Scrum? Jump in and learn why it is not a status meeting from my third post in the Scrum Events series.

Scrum Events #3 Daily Scrum

## Introduction

\*This post has been updated based on the [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html)

In my [last post](/blog/scrum-events-1-the-sprint/) I’ve started the Scrum Events series and described the first event in Scrum - **Sprint**. If you haven’t read it yet, I recommend you do it before reading this article. 

Today I would like to continue the series by describing the event which  **initiates** the [Sprint](/blog/scrum-events-1-the-sprint/) - **Sprint Planning**.

Please take into consideration that some parts of the **Sprint Planning** that I described are not explicitly explained in the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) and I used examples of the common practices or my personal opinion.

## Sprint Planning - definition and length

Each [Sprint](/blog/scrum-events-1-the-sprint/) starts from the event called - **Sprint Planning**. During this meeting, Scrum Team: [Developers](/blog/scrum-roles-1-development-team), [Product Owner](/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master) collaboratively creates a plan of the work for the upcoming iteration. 

The meeting is time-boxed (the same as all events in [Scrum](/blog/first-steps-to-learn-scrum)) to a maximum of 8 hours for a monthly [Sprint](/blog/scrum-events-1-the-sprint/). Of course in case of shorter [Sprints](/blog/scrum-events-1-the-sprint/), the time is adjusted.

To help you understand the **Sprint Planning**, I would like to continue my analogy to sport from the previous post. This event is like the moment of the **start in sprinting** (short distance running). If you start running too fast, before the signal to begin, the whole race must be restarted due to false start. On the other hand, if you miss the start, it can jeopardize your whole run and final result.

It is exactly the same in [Scrum](/blog/first-steps-to-learn-scrum). The Scrum Team needs to **work together** to start the [Sprint](/blog/scrum-events-1-the-sprint/). If someone will start before others, **transparency** will be lost and it will have a huge impact on the [Sprint](/blog/scrum-events-1-the-sprint/). Additionally, any delays in start, misunderstandings and not clear requirements can also delay the [Sprint](/blog/scrum-events-1-the-sprint/) and negatively affect the final outcome.

## Why?

The first part of the Sprint Planning should be focused on the explanation of **"Why?"** by the [Product Owner](/blog/scrum-roles-2-product-owner). In the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) it is explained shortly:

> The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

I would add to this description an explanation of the high level idea for the product:

* How will the upcoming Sprint **impact** the development of the product?
* What were the **changes** from the previous Sprint that impacted the top of the Product Backlog? What needs to be taken into consideration during the Sprint Planning?

From my experience, it is much easier to start working on something if you know the **background** and understand the **purpose** of your actions. Of course details for each part of work should be explained in the work item’s Acceptance Criteria, but it is important for the Scrum Team to understand the whole picture.

It can be helpful if the  [Product Owner](/pl/blog/scrum-roles-2-product-owner)  starts from the **Sprints Roadmap**, and explain the Product Goal. I like the roadmap analogy, because I imagine that as a Scrum Team we are starting the trip together. It is much easier to achieve the first goal if we know roughly about the **next destinations.** FYI - it’s different from the roadmap used in project management. This is just high level vision based on the velocity of the team and it is adjusted whenever changes occur. 

![Sprint-Roadmap](img/roadmap.webp "Roadmap")

The next step of the **Sprint Planning** is setting up the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) by the Scrum Team. It is the objective that they want to achieve during the upcoming iteration. [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) should be valuable and clear to everyone. It helps the team focus and understand why they are doing their work. 

## What?

After “Why” of the [Sprint](/blog/scrum-events-1-the-sprint/) it is time for a discussion about  **what** will be done during the [Sprint](/blog/scrum-events-1-the-sprint/). 
[Product Owner](/blog/scrum-roles-2-product-owner) &  [Developers](/blog/scrum-roles-1-development-team) collaborate on what  [Product Backlog](/blog/scrum-artifacts-1-product-backlog) items will be included in the current [Sprint](/blog/scrum-events-1-the-sprint/). The list of items selected for the Sprint is called **Sprint Backlog**.

If it is not the first [Sprint](/blog/scrum-events-1-the-sprint/) of this team, there are some inputs to the Sprint Planning session like:

* **Projected capacity** - total number of hours that the team will be available during the [Sprint](/blog/scrum-events-1-the-sprint/).
* **Velocity** - average amount of Product Backlog turned into [Increment](/blog/scrum-artifacts-3-the-increment) during previous [Sprints](/blog/scrum-events-1-the-sprint/).
* **Their Definition of Done** - how they will recognize that the work item is “Done”.

It is up to the [Developers](/blog/scrum-roles-1-development-team) to select how many work items can be done within the [Sprints](/blog/scrum-events-1-the-sprint/). It is one the first moments in  [Scrum](/blog/first-steps-to-learn-scrum) when [Product Owner](/blog/scrum-roles-2-product-owner) needs to trust the team members that they will select the right amount of work based on their expertise and previous experience. Nobody knows better how much work  [Developers](/blog/scrum-roles-1-development-team)  can do during the [Sprint](/blog/scrum-events-1-the-sprint/) than themselves.

## How?

Once the [Developers](/blog/scrum-roles-1-development-team) knows why they need to do the work during the Sprint and they decide what will be done, it is time to decide **how** it will happen.

Let’s check what we can read in the  [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) about it:

> For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

It is not mentioned there, because it seems to be obvious, but [Developers](/blog/scrum-roles-1-development-team) need to decide **how** they will be **checking** daily if they are going in the right direction with their work. How do they plan to **track the work, communicate** with each other? They will be meeting on a Daily Scrum, but what more?

There are some technical aspects that I believe need to be discussed:

* How will they track the **progress** of our work? Do they want to use the **Kanban** Board? If yes, will they use columns "To do", "In progress" and "Done" or others that will be more accurate for their work?
* Would they like to use **tools** like Sprint Burndown or Burnup charts to see if they are still on the right track in order to achieve the  [Sprint Goal](/blog/sprint-goal-why-do-we-need-it)?
* How about **bugs**? Do they consider having items called "bugs"? If yes, how do they plan to manage them?
* What about **communication** within the team? Do they plan to communicate only face to face or using emails, Microsoft Teams, Zoom or any other tool?

It is possible that there will be more technical aspects that the Scrum Team should discuss. I think that it is important to talk about them and have a common understanding of communication and the whole collaboration process. It doesn’t need to be a long discussion. It can be just a quick agreement to make sure everyone is on the same page.

![How?](img/how.webp "How")

Once it’s all sorted out, [Developers](/blog/scrum-roles-1-development-team) can decide about the **size** of the items selected to the Sprint. Based on my experience this can also be an element of the regular **Backlog Refinement process.** There are multiple ways of estimation eg. Planning Poker (by using Fibonacci sequence), T-shirt sizes, Dog sizes etc. 

The main purpose of this activity is to have a **discussion about items** & to use the sum of estimates to calculate the **Velocity.** It is a great tool that can be used during the planning of the next Sprint.

When all the work is discussed, understood and planned, [Developers](/blog/scrum-roles-1-development-team) can **start their work.** If they discover that they didn’t select enough items for the Sprint Backlog or they selected too many, it can be re-negotiated with the  [Product Owner](/pl/blog/scrum-roles-2-product-owner).

## Summary

The most important takeaways from this post are: 

* Scrum Team [Developers](/blog/scrum-roles-1-development-team) , [Product Owner](/pl/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master)) should attend the Sprint Planning meeting. 
* Sprint Planning is time-boxed to **8 hours** per monthly Sprint.
* The [Product Owner](/pl/blog/scrum-roles-2-product-owner) should explain **“The Why”** of the Sprint - what is the value. Based on it, the whole Scrum Team crafts the  [Sprint Goal.](/blog/sprint-goal-why-do-we-need-it)
* PO and [Developers](/blog/scrum-roles-1-development-team) discuss **items selected for the Sprint,** but the final decision about it should be done by [Developers](/blog/scrum-roles-1-development-team).
* The inputs to the Sprint Planning can be: **projected capacity, velocity and their Definition of Done**.
* [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) & **Sprint Backlog** should be the outcome of the Sprint Planning.
* It is important for  [Developers](/blog/scrum-roles-1-development-team) to discuss **how they will be working d**uring the Sprint - all technical aspects: tools, boards, communication etc.
* [Developers ](/blog/scrum-roles-1-development-team)can **estimate** during the meeting (or during **Backlog Refinement)** how much effort is required to complete Product Backlog Items selected for the Sprint.

This article describes all aspects of the Sprint Planning meeting. It will help you to understand the purpose of this event, how it looks like & what you need to remember about. 

Scrum Events #2 Sprint Planning

\*This post has been updated as per [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html#).

## Introduction

Scrum framework consists of **5 events** (listed below) that are **time-boxed** and they help to **minimize** the need for other meetings. They also create **consistency** which improves efficiency of the work.

* Sprint 
* Sprint Planning
* Daily Scrum
* Sprint Review
* Sprint Retrospective

The next 5 posts will be describing each of the 5 Scrum events in detail.
[Scrum](/blog/first-steps-to-learn-scrum/) events help to organize the structure of each iteration. That’s how we can create a **safe** work environment and trigger **creativity** in the team.

![Scrum Framework](img/scrum_framework.webp "Scrum Framework")

## The Sprint - Definition & Length

Based on the [Scrum Guide](https://scrumguides.org/scrum-guide.html#):

> Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

The best way to imagine what is the Sprint in [Scrum](/blog/first-steps-to-learn-scrum/) is using the **sprint’s sport analogy.** As we all know, a sprint is a **short distance** run, typically focused on quickly reaching the goal.

That’s exactly how the Sprint looks like in [Scrum](/blog/first-steps-to-learn-scrum/). It is quite a short time period (**maximum one month**) focused on achieving the **Sprint Goal** crafted at the beginning during the **planning** session.

It is important to keep Sprints **short** to be able to **adjust** to the changing world and avoid the **risk** of **increased** complexity. It also helps to keep **focused** on the goal.

Imagine that you are running a short distance - you can see the finishing line and it **motivates** you to run faster. Long distance running requires much more **planning**. We don’t want to use all our energy at the beginning, so it needs to be accumulated till the end. It’s easy to make that mistake - run too fast when we start and be too tired at the end. Sometimes when we plan our run, we don’t consider important factors, which can **change** our result.

**Product development** works better when we work in **short periods of time.** It helps to avoid risk related to **changes** that we didn’t consider. That’s why the Sprint in Scrum is short enough to see the **horizon/Sprint Goal,** but long enough to **create releasable product increment.**

![sprint](img/sprint.webp "sprint")

## Iteration

[Scrum](/blog/first-steps-to-learn-scrum/) promotes an **iterative approach** which means that all activities are done in **cycles.** During the **Sprint** we discover what is working, what should be changed and we adjust it. The next Sprint starts **immediately** after the previous one and we can use the knowledge that we gained in the previous Sprint.

The main benefit of **short cycles** is the opportunity to **get early feedback** from stakeholders and **adapt** to the market.

## Frame

Scrum is a **framework** and I imagine the **Sprint** as a **frame** that consists of everything else. During the **Sprint**, Scrum Team is focused on the **current iteration** and **all actions** are referring to the **current Sprint:**

* Sprint Planning - time for planning the whole **Sprint**
* Sprint Goal - what we want to achieve during **the Sprint**
* Sprint Backlog - work items planned for **the Sprint**
* Daily Scrum - plan for each day of **the Sprint**
* Sprint Review - to discuss what was done during **the Sprint**
* Sprint Retrospective - inspection of what was good and what should be improved based on **the Sprint**.

As you can see all actions are focused on the current iteration - **the Sprint**.

Of course the Product Owner needs to have some high level vision of the **whole development** of the product and **other Sprints.** That’s why he or she creates the **Product Backlog,** that includes all work items related also to the **future change** of the product. They also craft the **Product Goal** to give everyone direction. 

It is important to remember that Product Backlog is **flexible** and can be adjusted, changed, but **Sprint Backlog** is more fixed. It can be clarified, changed but that needs to be agreed between the Product Owner and Developers.

Changes that could **negatively impact** the **Sprint Goal** or **quality** are not allowed during the Sprint.

## Cancelling the Sprint

In [Scrum](/blog/first-steps-to-learn-scrum/) it is allowed to **cancel the Sprint** if **Sprint Goal** is **out-of-date** due to the technology change or different market situation. I would say that it is a really **rare** situation, but it can happen and it can be done **only by the Product Owner** - the only person who has **authority to cancel the Sprint.**

From a technical perspective when Sprint is cancelled, **"Done" work items need to be reviewed**. If they are potentially **releasable**, they can be accepted by the Product Owner. The approach related to other incomplete items is similar like at the end of a normal Sprint. They go back to the Product Backlog and Developers will need to re-estimate them.

## Summary

To sum up:

* The **Sprint** is an **event** in the [Scrum](/blog/first-steps-to-learn-scrum/) framework that can take a **maximum one month.**
* Sprint helps the Developers to **focus** on the work that needs to be done and **achieve the Sprint Goal.** It is also the **frame** for all other events, actions and definitions in the Scrum.
* **Cancellation** of the Sprint is possible, but it is uncommon and it can be done **only by the Product Owner.**

I hope that this post helped you to understand the basic idea of the **Sprint**. I will continue describing all other Scrum events in my next posts.

This is the first post in the Scrum Events series that will help you to understand what the Sprint is and what is its role in Scrum.

Scrum Events #1 The Sprint

## Introduction

\*This post has been updated based on the [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html).

When I wrote this article for the first time, I mentioned: 

> In the current fast-changing world full of new challenges, it’s easy to forget about goals.

Now I don’t agree with this sentence at all. We set up many goals - at work and in our private lives. I would say that the problem is related to having **too many goals** and forgetting what we actually wanted to achieve. We are moving forward overcoming challenge by challenge.

So, today I would replace my old sentence with:

> In the current fast-changing world full of new challenges, we need to focus & to have a clear direction of our actions.

In Scrum it is simple. We have a **Product Goal** which helps us with the **long term vision** of product development. During the Sprint Planning, we also create a **Sprint Goal** to understand what is our direction in the short term. 

Today I will explain the benefits of having the **Sprint Goal** & why it is a really important artifact in Scrum.

## Focus & Direction

I already mentioned how **Sprint Goal** gives us the **direction** of the upcoming Sprint. It should be created during the **Sprint Planning** meeting to help Developers plan their work. 

It is also a single objective. I had many discussions about it with my Scrum Teams. The main reason why it is single is helping Developers to be focused. As you may know, one of the **Scrum Values** is **FOCUS**. Without being focused, Developers cannot be creative & develop high-value products. 

## Prioritization

It’s easy to get distracted by multiple small tasks during the Sprint. That’s when it’s extremely important to remember about the **Sprint Goal** and answer the question 

> Does this task help The Scrum Team to achieve the goal?

 If the answer is yes, we can start working on it. If not, it should be **lower** on our priority list.

Without answering that question we can find ourselves busy, but not moving forward with plans that we had. In the end, the result is disappointing - the goal is not achieved and the outcome of the Sprint doesn’t satisfy us.

## Interactions between Developers

**Sprint Goal** is also helpful in **daily inspection** of the work during **Daily Scrum** meetings. In e [Scrum Guide 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf), you could find examples of the questions which can be answered by Developers during Daily Scrum. They removed them in the latest version & I think it was a good idea. Many teams used these questions incorrectly by removing “Sprint Goal” at the end. Then, Daily Scrum wasn’t just to collaborate and plan the day, but it started being just a status report meeting.

That’s why I think, it’s good to have a **visual reminder of the Sprint Goal** on the  [Scrum](/blog/first-steps-to-learn-scrum/) Board. It will help Developers to focus. When they talk about Sprint Goal, the whole discussion is different. They **start working together**, instead of working on separate initiatives. They focus on something that is related to all of them, not only on their individual tasks. 

**Sprint Goal** also helps them to decide what is **more important** and what they need to focus on during the upcoming day. I still remember how proud I was when during Daily Scrum one of the Developers stopped the other who was overloading himself with low priority work items. He asked him: “Wait, but does it help us to achieve the Sprint Goal? Maybe you could help with this issue instead?”. That was the moment I knew they were on the **right track.**

![Daily-Scrum](img/people.webp "Daily Scrum")

## Outcome of the Sprint

**Sprint Goal** is also a great tool during Sprint Review - the event focused on inspection of the **outcome of the Sprint.** It helps the Scrum Team to understand what was accomplished and what was stopping them from achieving what they planned.

By referring to the Sprint Goal, Scrum Team & stakeholders can think about the **changes** required in the upcoming Sprint. They can also **celebrate the success** achieved during the Sprint.

## Summary

In conclusion, the main benefits of using Sprint Goal are:

* Developers are **focused**
* **Clear direction** of the Sprint
* Clarity about **what is important** during the Sprint
* **Prioritization** of tasks is easier
* It’s great **inspection** tool
* It helps in **interactions** between Developers
* Tool to present the **outcome** of the Sprint

If you noticed that your team doesn’t pay attention to **Sprint Goal**, I encourage you to start using it in all activities that I mentioned and see how much it will impact your work. I can tell from my own experience, you will see the difference!

This article explains what is the purpose and benefits of Sprint Goal in Scrum. If you don’t know what it is and how to use it, check out this post. 

9 posts tagged with #sprint