# Dissection the Scrum Structure

## <mark style="background-color:yellow;">How scrum transforms ideas into values</mark>

<mark style="background-color:yellow;">We start with a set of ideas and transform them into Value by working.</mark>

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FtST4SJYpjsGnRmfREbQg%2Fscrum-ideas-values.png?alt=media&#x26;token=5998ef9b-b046-4717-8214-0fcb5bbd8e67" alt=""><figcaption></figcaption></figure>

## Artifacts

### **Product Backlog**

Is <mark style="background-color:yellow;">where all the ideias are stored</mark>.\
It is <mark style="background-color:yellow;">not intended for documentation itself</mark> but <mark style="background-color:yellow;">to bring transparency</mark> to the process and <mark style="background-color:yellow;">create alignment between business and technical people</mark>.

The feasibility of <mark style="background-color:yellow;">delivering value is highly affected by the quality of the product backlog</mark>.

It is not only refined and changed after sprint reviews, <mark style="background-color:yellow;">its refinement is an ongoing process</mark> in which the scrum team collaborates on the details of the product backlog items.

Although the <mark style="background-color:yellow;">PO is the one accountable for it</mark>, the <mark style="background-color:yellow;">developers are the ones responsible for the sizing of the products backlog items</mark>. The PO may influence them by helping them understand and select trade-offs.

### **Sprint Backlog**

It is the backlog generated from the sprint planning, that holds:

* The scrum team agrees on a <mark style="background-color:yellow;">sprint goal</mark>;
* Selects a <mark style="background-color:yellow;">set of product backlog items</mark>, to be worked on during the sprint;
* Defines an <mark style="background-color:yellow;">actionable plan for delivering the increment</mark>;

### **Increment**

Is the <mark style="background-color:yellow;">outcome of a sprint</mark>.\
The increment <mark style="background-color:yellow;">is a vertical delivery</mark>, having all the layers as part of the product.\
The increment is Scrum's way of manifesting real value. (This is where the **work is done**)\
It is <mark style="background-color:yellow;">possible to have multiple increments</mark> in a sprint.

In complex problems, asking user what they want is not enough. They will only know when IKIWISI.

#### **Horizontal delivery (Iterative)**

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FZ5OjQri60ZTz8azXYpfg%2Fhorizontal-delivery.png?alt=media&#x26;token=3e68d2af-84e8-4c67-9470-3de56ea5d8c2" alt=""><figcaption></figcaption></figure>

#### **Vertical delivery (Incremental)**

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2FgUy9uTUFoV0HV4KOLdcm%2Fvertical-delivery.png?alt=media&#x26;token=cdd9df1c-6264-4ed1-a7a7-8d5b1296980d" alt=""><figcaption></figcaption></figure>

Since Scrum is both Iterative and Incremental it looks something like this:

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2Fpv3k1Z4tgHhf1UnNbP7A%2Fscrum-delivery.png?alt=media&#x26;token=3a760a9e-91a5-4faa-bbf2-24a3bd3834ce" alt=""><figcaption></figcaption></figure>

## Accountabilities

### **Product Owner**

<mark style="background-color:yellow;">Is the single person accountable for defining what will be done and in what sequence.</mark>\
He <mark style="background-color:yellow;">needs to write a good product backlog</mark>.\
He <mark style="background-color:yellow;">needs to collaborate with the Scrum team and stakeholders.</mark>

### **Developers**

Are <mark style="background-color:yellow;">the ones that get the work done</mark>.\
They directly work to deliver the increments.

### **Scrum Master**

<mark style="background-color:yellow;">Good Scrum Masters are invisible.</mark>\
They <mark style="background-color:yellow;">do not get in the way of the other team members, but empower them</mark>.\
They <mark style="background-color:yellow;">observe and support the scrum team making scrum work effectively</mark>.

One of their jobs is to <mark style="background-color:yellow;">detect incomplete transparency</mark> by inspecting the artifacts, sensing patterns, listening closely to what is being said, and <mark style="background-color:yellow;">detecting differences between expected and real results</mark>.

## Events

### **Sprint**

<mark style="background-color:yellow;">Lasts at most one month.</mark>

### **Sprint Planning**

Is the first thing done in the beginning of a Sprint.\ <mark style="background-color:yellow;">Lasts at most 8 hours.</mark>

* The <mark style="background-color:yellow;">scrum team agrees on a sprint goal</mark>;
* <mark style="background-color:yellow;">Selects a set of product backlog items</mark>, to be worked on during the sprint;
* <mark style="background-color:yellow;">Defines an actionable plan for delivering the increment</mark>;

### **Daily Scrum**

Each day during the sprint, the developers hold this daily scrum.\ <mark style="background-color:yellow;">Lasts at most 15 minutes.</mark>

A <mark style="background-color:yellow;">quick way for the developers to discuss how to optimize its chances to reach the sprints goal</mark>.

### **Sprint Review**

A event at the end of the Sprint, <mark style="background-color:yellow;">lasting at most 4 hours</mark>.

It is <mark style="background-color:yellow;">when the scrum team gets along with stakeholders</mark> to discuss the product being developed, including <mark style="background-color:yellow;">what was developed during the sprint and future adaptations</mark>.

### **Sprint Retrospective**

A event a the end of the Sprint, <mark style="background-color:yellow;">lasting at most 3 hours</mark>.

<mark style="background-color:yellow;">It closes the Sprint by having the scrum team reflect on how to improve its ways of working.</mark>\ <mark style="background-color:yellow;">Is about inspecting and adapting the scrum team itself</mark>, focusing on <mark style="background-color:yellow;">making it more effective</mark> and increasing the resulting quality.

This includes <mark style="background-color:yellow;">increase effectiveness</mark> of:

* <mark style="background-color:yellow;">Product Owner</mark>
* <mark style="background-color:yellow;">Developers</mark>

## <mark style="background-color:red;">The Definition of Done</mark>

More info here [#the-definition-of-done-1](#the-definition-of-done-1 "mention").

<mark style="background-color:yellow;">It defines what Done means for the increment.</mark>\ <mark style="background-color:yellow;">It must brings balance between delivering fast and with quality.</mark>

At the end of every sprint the team needs to deliver ***Done*** increments, and ***'Done'*** might mean different things to different people.

So <mark style="background-color:yellow;">to ensure visibility, transparency and understanding of what mens for</mark> <mark style="background-color:yellow;"></mark>*<mark style="background-color:yellow;">'work to be done'</mark>*, the scrum team must agree on a Definition of Done.

### Flaccid Scrum

It is an <mark style="background-color:yellow;">Anti-pattern that reflects</mark> the behavior of teams that <mark style="background-color:yellow;">focus too much on delivering features as fast as possible while compromising quality</mark>.